Seriously, stop disabling SELinux(stopdisablingselinux.com)
stopdisablingselinux.com
Seriously, stop disabling SELinux
http://stopdisablingselinux.com/
4 comments
I can't recall how many times i've installed vetted packages from a mainline distro, and the software does not work as expected due to some obscure selinux formality I have to wade through.
When you want users to use your software by default, users should not need to touch it by default.
Sorry about your luck selinux, probably not your fault.
When you want users to use your software by default, users should not need to touch it by default.
Sorry about your luck selinux, probably not your fault.
Not certain about your point... but if you meant SELinux should be turned off, then you got it wrong, I think. SELinux is more like your Firewall. You don't turn your firewall off because some software you are trying to use does not work!
I agree with you. SELinux should be on by default much like a firewall, but I guess I was referring to packages not shipping selinux policies leaving the user in limbo about why the software which is documented to work out of the box does not.
For as long as you've got official articles like this[0], it's a harder sell than it should be.
[0] http://www.asteriskdocs.org/en/3rd_Edition/asterisk-book-htm...
[0] http://www.asteriskdocs.org/en/3rd_Edition/asterisk-book-htm...
There's a very big trust problem with SELinux, since it mostly comes from the NSA. Without a very deep audit, how can we be sure it's not full of backdoors? I'm not saying it's not, I'm just saying it comes from the NSA, and the NSA doesn't work for the good of most Linux users.
I once spent several days trying to troubleshoot why the public_html module on my web server was working for all except one user's home directory.
It turned out at some point in the past that particular user's home directory had been evacuated off /home in order to free up some space and then was copied back. That process stripped out all the SELinux context information and there was an SELinux policy in place that basically prevented the public_html module from accessing a directory that did not contain whatever the hell SELinux was looking for.
This is not the only example of my problems with SELinux in the past but it was the straw that broke the camel's back. SELinux has been persona non grata on my systems for years now and I still get angry thinking about the time I spent troubling SELinux issues in the past. :-/
It turned out at some point in the past that particular user's home directory had been evacuated off /home in order to free up some space and then was copied back. That process stripped out all the SELinux context information and there was an SELinux policy in place that basically prevented the public_html module from accessing a directory that did not contain whatever the hell SELinux was looking for.
This is not the only example of my problems with SELinux in the past but it was the straw that broke the camel's back. SELinux has been persona non grata on my systems for years now and I still get angry thinking about the time I spent troubling SELinux issues in the past. :-/
The reason people disable SELinux is that it leads to obscure hard to diagnose problems with equally obscure hard to research solutions. It has a reputation as a poorly documented, overly complex time sink.
Its benefits are also a bit unclear. I know it "improves security" but some specifics are needed -- how, why, and what exactly does it do? What's an example of an attack that would succeed without SELinux and fail with it? Benefits should also be stated -- and with concrete examples and concrete use cases. There is way too much hand-wavey cargo cult "because security!" BS in infosec/netsec.
By contrast, consider a security improvement like ASLR. Its benefits are easy to understand (if you know how stuff works under the hood), and it's very easy to enable and generally causes no problems. ASLR is a good example of a transparent, easy to use, and clearly beneficial security feature.