Hacker News new | past | comments | ask | show | jobs | submit login

I'm a big SELinux fan and user.

Enabling it won't in itself secure your company's applications, as the default policies in Fedora only apply to installed services (e.g ssh) that have a policy written for them.

This is probably right on the boundary of the shared-security-model, but I think it would be great if they also offered easier ways for application developers to leverage the advertised feature.




FWIW, Docker, podman, LXC, and Kubernetes will apply SELinux policies to containers automatically if you have that support enabled at build time (many distributions do have it enabled, esp Fedora family) and SELinux enabled at runtime. Likewise for AppArmor.


Yes,agreed.

& AWS are active in this area moreso with bottlerocket-os https://aws.amazon.com/blogs/opensource/security-features-of...

The recent release even incorporating the use of a feature I had previously dismissed as useless (MCS) is really quite neat https://github.com/bottlerocket-os/bottlerocket/discussions/...


most servers use debian or ubuntu, i think this will be greate and maybe even a killer feuture to change a little the landscape, but i don't think is as much impact as we wish in at least the next 5 years


You're not wrong, but writing selinux policy isn't that complicated. You can easily look at ausearch output to understand why a constrained process failed and brute force a policy using audit2allow. Although as the policy writer becomes more familiar with selinux and their app, they can write better policy.


I do know this, I'm currently putting together a training course on authoring SELinux policy.

Surely the fact that 'disabling SELinux' is the top result on the subject in Google or StackOverflow will tell you that you would be in the minority of developers that like working with it and find it easy to do so.

I think there's more to it than just simply running an app without receiving an AVC complaint in auditd, you need to be able to test that the controls you put in place actually protect the application in some way, this does not come for free with audit2allow and other such generative tools.


The problem I found (on Centos 8) is that audit sometimes denies but nothing is logged. I found this is the case when an apache script tries to kill another process. It required 2 separate policies: one of which audit2allow came up with, and another I had to figure out myself after a whole bunch of time scouring stackoverflow. After that I just gave up on selinux and turned it off, as I just couldn't trust it.

If it actually did what it was supposed to do in a reasonable manner, people would use it.


> The problem I found (on Centos 8) is that audit sometimes denies but nothing is logged

I doubt that. journalctl has always given me something when there was an actual denial. You might just not have looked right


I did. It is trivial to recreate.


For some applications, certainly.

But for applications with a large feature set - e.g. a web browser - if the policy author didn't use a particular feature - e.g. U2F security key support - you might be introducing a new source of problems that only advanced users can easily solve.

Not that I imagine Amazon Linux is used for web browsing very often....




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: