I read a post this afternoon that surprised me a little, which is tough to do because I work on the Internet and I’ve basically seen everything humanity has to offer. Believe me, it’s not much.
What surprised me today is that the old axiom “SELinux is so difficult to use that most IT managers just switch it off” has bubbled to the surface again over at Kerneltrap.org.
The post at Kerneltrap is actually a snippet from a larger rant on the OpenBSD mailing list, which compares the security of SELinux to OpenBSD’s default security.
A thread on the OpenBSD-misc mailing list compared the security of SELinux in the 2.6 Linux kernel to what’s available in OpenBSD. The general opinion was that SELinux and its policy language are too complex, leading Damien Miller to note, “every medium to large Linux deployment that I am aware off has switched SELinux off. Once you stray from the default configurations that the system distributors ship with, the default policies no longer work and things start to break.” Ted Unangst summarized, “the problem with security by policy is that the policy is always wrong.”
I’ve written a few articles about SELinux over the past year and a half for this sole reason: complexity. I’m certainly no expert on the subject, but in 2006 and ‘07 I did get to hear from people at various Linux conferences and from interviews for other security stories that SELinux was a great piece of software — perhaps “too great.” As was argued above in the OpenBSD list, people were shutting it off because its NSA-powered muscles were breaking their systems. When that happens, you’ll find 9 times out of 10 an administrator will opt to shut the thing off and find another fix rather than invest the extra time and money, regardless of the features being promised him/her. So I started asking, “what’s being done? Who’s doing what?” and so on.
The folks at Red Hat were the most helpful, for obvious reasons (SELinux is baked into Red Hat Enterprise Linux), but I also interviewed a few SELinux experts for my research, including Karl MacMillan and Frank Mayer, co-authors of SELinux By Example. Mayer even wrote us a nice article on SELinux, called Five Ways SELinux may surprise you, that still does well traffic-wise on SearchEnterpriseLinux.com today. I also interviewed the guys in the trenches who had decided to shut the thing off and deal with it later.
What I discovered is that part of SELinux’s current dilemma is more easily fixable than the other, because it has nothing to do with technological chops and everything to do with public perception. Jim Klein, the director of information services and technology at the California-based Saugus Union School District, put it best: “The biggest problem for SELinux is mindshare,” Klein told me. “It developed a stigma early on due to the lack of tools for configuration and troubleshooting, which led people to simply turn it off.” Currently, Klein is one of the many IT guys who has the SELinux switch in the “off” position.
But Red Hat was ready for that, or so it seemed. At the Red Hat Summit in May their SELinux guru Dan Walsh was beating the setroubleshoot tool drum as proof that his developers were listening and SELinux was turning a corner towards simplicity. Also known as SELinux Troubleshooter, setroubleshoot is a tool that watches the audit log files for access vector cache (AVC) messages and send reports to the IT manager when things go wrong, right or whatever. Walsh said SELinux has a new GUI in RHEL 5 to assist in management, as well as a set of configurable Booleans (read: if, then statements) that allow IT managers to modify network ports, file labeling and event user mappings. That particular session was one of the more packed ones I attended in San Diego that week. Does that mean anything in particular? Not really, as security is always popular topic, but it was interesting given what’s still being debated today.
As Red Hat talks GUIs and tools and setroubleshoot (oh my!) those crafty OpenBSD guys are ready with a pithy retort (or is that snark?):
If the policy language was halfway sane then this wouldn’t be so bad - a skilled administrator could adjust the policy. Unfortunately:
1) skilled administrators are hard to come by, and their time is usually better spent *not* tweaking brittle mandatory access control policies
2) the SELinux policy language is nowhere near sane.
OpenBSD’s systrace suffers from #1 - it is a generic problem with these sorts of access control mechanisms, and it is one reason why it has never been enabled by default. The brittleness is a real problem - I use systrace for a few things and often need to update my policies because of software upgrades or libc changes. Oh, and “skilled administrator” means someone deeply familiar with the Unix system interface - not a just a graduate of certification course de jour.
The Linux solution to #2 seems to be to add various wizards and other abstraction between the administrator and the policy, rather than tossing the horrid mess and replacing it with something more comprehensible.
What this all means to me is if we can find similar thoughts being shared outside of an OpenBSD mailing list (where Linux or SELinux surely don’t have the home field advantage they’re used to in, say, Linus Torvalds’ backyard), we might be onto to something. That something? That SELinux should in fact be turned off indefinitely until this complexity issue is resolved.
Until then, however, I think we all should probably look into some advice I found in the Kerneltrap comment section:
If I wanted a fair comparison of OpenBSD and SELinux, the last place I would ask would be the openbsd-misc mailing list.
Could be good advice.
Related info: Our site expert James Turnbull has a brief comparison of SELinux and AppArmor (the latter being what Novell SUSE has to offer).
