Our viewpoint is ultimately pragmatic: at the moment, both SELinux and AppArmor appear to be too much work for the potential benefit they offer in our environment. We could spend a great deal of time configuring both of them in order to make things work, and they would still probably not do anything much for us in practice.
(Remember, both SELinux and AppArmor are secondary defenses, not primary defenses; they potentially limit the damage if your system is already partially compromised.)
In part this is because at least SELinux only really works easily if you put everything in what the distribution considers its standard location and run things in the standard way. The moment you deviate from this, you wind up having to research an increasingly large number of file and executable contexts and (re)label an increasingly large number of files. And I'm ignoring NFS here, which we use heavily (I doubt NFS files can easily have SELinux attributes, especially when they live on non-Linux NFS servers).
Security is always ultimately about pragmatics. You have X amount of time to spend on security in all its aspects, and you need to use this time efficiently, to gain as much security from it as possible. Our judgement is that use of our security time configuring SELinux does not have a particularly high payoff.
(For clarity: I'm the author of the entry that mwcampbell linked to.)
Hi! Thanks for your ZFS entries, they've been very useful to me in the past.
I understand the pressure of not having enough time to do things perfectly. But the kernel is a project with widespread use in many domains, and the security features it implements have to provide strong security. We can't let kernel security requirements be dictated by environments that don't believe they require them. It's possible to set up a much less restrictive SELinux environment if you don't need or want to get the full benefit.
This also comes in to my first point, which is that we really need a better abstraction for SELinux configuration. Something that would be simpler to administer for environments that don't require the utmost in security isolation. But it should build on the strong in-kernel MAC implementation that already exists.
The general SELinux issue is a complex subject. My short form take is that regardless of its potential in theory if implemented nicely, in practice SELinux as deployed has consistently prioritized mathematical perfection (and yelling at people) over practical usability in the field. The real result of this has been less security than would have been achieved with a less perfect but more usable system because in the field SELinux does not degrade gracefully and so many people turn it off entirely. Some number of systems are quite secure (assuming no leaks in SELinux itself); many other systems are not secure at all. This is a bad outcome (unless you decide that only people who are dedicated enough to use SELinux really matter and everyone else is 'unprofessional' or the like), and I don't like it. I want a better outcome, one with more security that I can actually justify deploying, one where more daemons and programs are hardened to some degree even if it's not a huge amount.
(At this point the OpenBSD pledge() work is looking attractive, although there are real organizational issues that would make it hard to do in Linux.)
Perhaps one can get to a better future with SELinux by having people build and ship systems for doing little SELinux configurations for daemons or systems that read daemon configuration files so they can automatically label directories and files for your system, or any number of other user friendly ideas. But we've had something like a decade of SELinux and its usability problems at this point and it hasn't happened yet. It's hard to avoid the obvious collection of conclusions.
SELinux came from the defensive side of NSA, pre 9/11, and was not written to make Linux more secure. It was written to force application developers to re-architect their applications so they could run under a mandatory security environment. The original idea was that, once enough applications could operate under a mandatory security model, an secure OS could be put in underneath them.
NSA had had several multi-level secure operating systems developed for them in the past, but they didn't have any applications other than ones specifically written for them. SELinux was intended to remedy that.
Unfortunately, nobody seemed to understand that, and NSA doesn't do much outreach.
(Remember, both SELinux and AppArmor are secondary defenses, not primary defenses; they potentially limit the damage if your system is already partially compromised.)
In part this is because at least SELinux only really works easily if you put everything in what the distribution considers its standard location and run things in the standard way. The moment you deviate from this, you wind up having to research an increasingly large number of file and executable contexts and (re)label an increasingly large number of files. And I'm ignoring NFS here, which we use heavily (I doubt NFS files can easily have SELinux attributes, especially when they live on non-Linux NFS servers).
Security is always ultimately about pragmatics. You have X amount of time to spend on security in all its aspects, and you need to use this time efficiently, to gain as much security from it as possible. Our judgement is that use of our security time configuring SELinux does not have a particularly high payoff.
(For clarity: I'm the author of the entry that mwcampbell linked to.)