To read all comments associated with this story, please click here.
It is disturbing that SELinux is being presented essential and a panacea. To read the popular propaganda, you'd think that it was impossible achieve anything better than a security sieve without it. SELinux is an effective, if somewhat complex, tool which provides very fine-grained security. It comes at a cost of some (perhaps unnecessary[1]) complexity, and a bit of performance. There are other solutions which hit a different balance of fine-grainedness vs complexity, including the traditional unix permissions which have served us pretty well over the last few decades before SELinux showed up. I am far from a RedHat basher (I have huge respect for them), but RedHat has been pushing SELinux very hard for their own business reasons, and this has created a vortex which has sucked in many bystanders. Distros and savvy individuals should make their own choices, which make the most sense for their situation.
[1] "The more they over-think the plumbing, the easier it is to stop up the drain."
- Montgomery Scott, Star Trek III: The Search for Spock
Edited 2008-05-12 13:22 UTC
Redhat mainly uses SELinux for confining system daemons. They have done a pretty good job of making the default configuration work out of the box. One big problem area are services like Apache where users need to label files and there aren't good simple docs on how to do this. The other problem is with third-party software, like VMware, that doesn't know about SELinux.
There has been some work done on confining Firefox. My guess is that it will be an option for people who want the extra security and are willing to put up with limitations on downloading files and loading plugins.






Member since:
2007-07-25
In my opinion SELinux is irrelevant for most users, and for the rest it is waaaay too hard to use. I am more interested in that new access control feature in the linux kernel (Smack or something?) as this seems to be similar to only the easiest part of SELinux.
Personally I think MAC is the way to go for long-lived background services that the user will not interfere with, but for foreground applications should not be such restrictions yet before they have found a proper way to implement it that does not interfere with the users workflow...(I am talking about enduser systems ofc).