Wandering Thoughts archives


My problem with SELinux

I think that my core problem with SELinux is that it is very fragile. By this I don't mean that it's buggy and so breaks in normal operation (because as far as I can tell it generally doesn't), but instead that a SELinux configured system is not resilient to changes. If you run the system exactly as your distribution delivered it, with everything in the same places and with the same user-ids and so on, the result generally works.

(You start running into potential problems if you run less common software, because all of its configuration is less well tested.)

However, when you start changing your system all bets are off. Do you want Apache's data to be somewhere other than the system standard? Do you want MySQL to store databases somewhere besides /var, because you have a really big /db filesystem? You generally lose. Unless you know enough to carefully modify your SELinux configuration (and keep the modifications intact when you do things), SELinux will break things; it will stop daemons from starting, it will prevent programs from reading files, and so on. Many of these failures are mysterious ones, where operations that should work fail inexplicably. Often they work if you run them by hand, which vastly complicates troubleshooting.

This is why I say that SELinux is fragile and it makes your system fragile. If you change things, you run a high risk of breaking something. If you are not familiar with SELinux and how your distribution uses it, it is hard to find what is broken and fix it again; it's generally simpler to turn off SELinux entirely.

Part of the problem is that SELinux labeling for files is often partially redundant information; for example, you specify the MySQL database directory in a configuration file, and then you 'specify' it again by putting the right SELinux label on it. SELinux would be significantly easier to work with and less fragile if you did not have this redundancy, so that some part of the SELinux system read your MySQL configuration and automatically set the labels appropriately.

(Then you could change your configuration once, in the way that you expect to, instead of twice. As a sysadmin I don't like redundancy in configuration settings because it's an opportunity for errors and inconsistencies to creep in.)

linux/SELinuxMyProblem written at 23:56:00; Add Comment

The optimistic view of SELinux's real purpose

In an entry, Zed Shaw recently wrote:

P.S. I have a long bet that SELinux is an NSA backdoor. Any takers?

I'm an optimist, so I think that there's another good explanation for SELinux and all of the effort that the NSA has poured into it. My theory goes like this:

Basically, the government has a problem. Historically and for good reasons, it is the only customer for really secure systems (ie, rainbow book level paranoid security). This has always translated to high prices, and lately it has translated to more or less vendor indifference to developing that sort of system; not only was the government getting high prices, it was getting out of date systems (if it was getting anything at all).

Given that it was in many ways the future of commercial Unix, Linux presented the government with an even bigger problem than before (Linux raised vendor indifference to government security desires to new and dizzying heights) but also a great opportunity to do what other people have been doing and hitch a ride on general Linux development to lower the costs of developing a secure Unix. All that the NSA had to do was develop a 'colour book' security addon for Linux and then get it accepted into the kernel. Hence, SELinux; while it cost the NSA a bunch of money, it also stands to reduce the government's costs of acquiring secure Unixes in the future (since they can now be built on top of Linux at relatively low cost).

(As basically the only customer for colour-book secure Unix, the government pays its development costs one way or another. Normally the government pays for it indirectly; with the NSA's work on SELinux, it was paying for it directly instead, but hopefully getting more for its money.)

I also suspect that some people inside the NSA had a beautiful dream where the availability of a free colour-book secure system caused people in the outside world to finally understand what it was good for and how much it could help them. Like many dreams of mathematic security, I don't expect this one to get very far (partly for the reasons covered in the last entry).

PS: it continues to amaze me that so many people run with SELinux turned on. All I can think is that they must be happy to run their systems with everything in the stock locations, or they have a lot more time and interest in learning how to control SELinux than I do.

(I believe I still have SELinux turned on on my Fedora laptop as an experiment. But the laptop runs a basically completely stock desktop environment, with no databases or daemons or whatnot. And even then I periodically get SELinux warnings.)

Sidebar: why secure Unixes will still cost the government money

The government doesn't give coloured-book security ratings to software, only to systems. SELinux and Linux are software, so someone still has to package and assemble them into a specific system, with specific configuration and setup and so on. That someone is going to want money for doing this (and for going through the hassle and expense of getting the result certified).

This system certification process is one of the reasons that government colour-book secure systems were always rather behind the times; they were basically specified and put together years before they can actually be used. If you are really cautious and care a lot more about non-disclosure than availability, this is an acceptable tradeoff.

linux/SELinuxOptimism written at 01:10:32; Add Comment

Page tools: See As Normal.
Login: Password:
Atom Syndication: Recent Pages, Recent Comments.

This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.