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.
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.
If this site wants to be effective, it should link to more than just a video. Don't make me sit and watch a video to get the most important ideas. Summarize them at least!
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.
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. :-/
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.
7 comments
[ 3.1 ms ] story [ 26.7 ms ] threadWhen 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.
[0] http://www.asteriskdocs.org/en/3rd_Edition/asterisk-book-htm...
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.
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. :-/