SELinux and Fedora

LWN.net needs you! Without subscribers, LWN would simply not exist. Please consider signing up for a subscription and helping to keep LWN publishing

Red Hat has undoubtedly done more to make SELinux usable than any other organization, but has it actually reached the point where it can be enabled by default for all desktops? The Fedora project clearly thinks so. Not only is SELinux enabled, but the installer no longer has an option to disable it or to put it into "permissive" mode. Most of the posts in a thread on the fedora-devel mailing list see that as the right choice, but some are not so sure.

Jon Masters started things off by making a request to restore the installation option, giving several reasons summing up with:

But there are numerous other justifications I could give, including my personal belief that it's absolutely nuts to thrust SE Linux upon unsuspecting Desktop users (who don't know what it is anyway) without giving them the choice to turn it off.

His reasons were unconvincing to many as he was not considered to be a "normal" desktop user; the things he was doing were much more technical than the users that are being targeted by the SELinux policies distributed with Fedora 9. The problems he reported were resolved quickly, but the fact remains that there are paths through Fedora—even just using desktop applications—that will result in SELinux-caused failures. The Red Hat SELinux team is very responsive, but users will get frustrated quickly if things they are trying to do fail in mysterious (to them) ways.

Alan Cox argues against providing an installation choice because he doesn't think users have enough context to make a sensible choice. He likens it to a car with multiple choices for safety features:

"This car has brakes, enable them ?"

"Would you like the seatbelts to work ?"

"Shall I enable the airbag ?"

When push comes to shove, Masters and a few others see the default of SELinux installed in "enforcing" mode as being too restrictive. It is likely to cause users to become annoyed with Fedora as a whole because one or more paths through the applications have not yet been tested. That, unfortunately, is the crux of the issue: SELinux policies are being developed in a reactive manner based on testing applications and adding exceptions for actions they perform.

As a security tool, SELinux is a good choice, because it essentially denies everything by default. Policies are added that will allow certain actions for users and applications. Its complexity is legendary, however, which is why Red Hat (and others) have made a substantial effort to make it work semi-invisibly. They started by generating policies for network-facing services and have now moved into securing desktop applications, particularly programs like web browsers which are increasingly the target of attacks.

SELinux has three modes, disabled, which turns off SELinux, permissive, which just logs attempts to do things that violate the policies, and enforcing, which disallows any access that is denied by the policies. When getting applications to work with SELinux, permissive mode is typically used. The log messages are analyzed to determine what changes should be made to the policies or to the application so that they work together. If there are features that were not tested in the application that require additional privileges, the first user that tries that feature in enforcing mode will run into trouble.

When that happens, SELinux can be put into permissive mode with a simple GUI or configuration file change, followed by a reboot. One of the problems is that users may very well not know that SELinux is the source of their problem. There are tools, like SETroubleShoot, that can help alert users, but it is still a frustrating, hard to comprehend problem at times. Once the user has "fixed" the problem by disabling SELinux, they are unlikely to turn it back on.

It is a difficult choice, but Fedora is firmly on the side of forcing non-technical users into using SELinux, at least until it breaks. More technical users will know about SELinux and, perhaps, be able to make more informed choices. One of Red Hat's SELinux developers, James Morris, neatly sums up the reasons it is important to continue pushing SELinux:

The only way to really make progress in improving security is to make it a standard part of the computing landscape; for it to be ubiquitous and generalized, which is the aim of the SELinux project. [...] Punting the decision to the end user during installation is possibly the worst option. It's our responsibility as the developers of the OS to both get security right and make it usable. It's difficult, indeed, but not impossible.

There are efforts underway to add easier ways for users to report SELinux log messages, perhaps even in an automated way, so that policy or application problems get identified and fixed more quickly. While it may not be easy for long-time Linux users to adjust to an SELinux-enabled system, it is getting to the point where average users, who never use the command line, rarely run into problems. And those are just the kind of users who need the level of security that SELinux can provide.