One of the nice things about conferences is the ability to catch up on where a particular project is headed, generally from one of the lead developers. Ottawa Linux Symposium did not disappoint in this area, with several "State of ..." talks. On day two of the four-day conference, James Morris looked at SELinux from its academic roots to its plans for the future.

SELinux got its start from university research in the 80s and 90s that recognized that Discretionary Access Control (DAC) did not protect very well against the kinds of attacks that were becoming prevalent. This spawned the idea of Mandatory Access Control (MAC), in which the system makes all of the policy decisions regarding access, so users cannot change the permissions on files or other objects at their discretion. SELinux is a MAC system.

Originally developed by US National Security Agency (NSA) in the 90s, SELinux was released under the GPL in December 2000. At the Kernel Summit in 2001, SELinux was proposed for inclusion in the 2.5 development-series kernels (remember those?), but was rejected by Linus Torvalds because there was no consensus amongst the various competing security models. This is what led to the creation of the Linux Security Model (LSM) interface.

It was the LSM interface that got Morris involved in SELinux. It took until the 2.6 release in December 2003 before SELinux was available in the mainline, which is about three years after its release. This is "not atypical for a significant change to the kernel," Morris said.

The next phase was to get it enabled and working in distributions. Because he works for Red Hat, Fedora (Core in those days) was an obvious choice. FC2 was the first release with SELinux, but it was disabled by default because the policy was too strict. "Every time we switched it on, we would find bugs in the applications". Security bugs that is.

So, Fedora came up with the idea of a "targeted" policy that only affected network-facing services. This was released as part of FC3—which formed the basis for Red Hat Enterprise Linux (RHEL) 4. It was an attempt to get SELinux "switched on and doing something useful". It worked well enough that it inspired confidence in the technology by proving it was viable. SELinux developers realized that "if we run into problems, we can fix them".

Since 2005, SELinux has emerged from a research orientation to a tool that is usable—with a very active development community. "Even being part of the project, it's hard to follow all that goes on" in the SELinux community. Morris then outlined some of the more significant developments over the last few years.

The development of the reference policy by Tresys was a tremendous addition to SELinux. It was a "step forward in policy thinking" because it provides a framework around which to design policy. By getting rid of the original "spaghetti code" policy, it "made policy much more understandable to policy developers".

Loadable policy modules broke up the monolithic policy that was originally part of SELinux into separate pieces. Each can then be loaded individually based on "policy booleans". The two of these together allow policy to be built and administered in sensible chunks, as well as allowing sites to "customize policy to support local conditions". Because of library and toolchain improvements, you no longer have to dig through files to edit, compile, and load policy either. Many of the reputation problems that SELinux has stem from the early days when it was well nigh impossible to track down policy problems and fix them.

It is this frustrating user experience that SELinux is trying to tackle these days. The targeted policy is being merged with the "strict" policy and hundreds of modules covering different applications have been added. Policy failure—where the policy is written incorrectly causing a user to be unable to do something they should be able to—is "something you don't want the user to know about", but unfortunately that is unworkable. Because the system is under development, bugs will occur; there is nothing more frustrating for a user than to be denied access but to be unable to figure out why.

That is where setroubleshoot can help. Inspired by GNOME's bug buddy, it alerts the user to policy violations and tries help find the cause of the problem—to the point of suggesting possible fixes. It is somewhat dangerous, in that users may blindly follow the fixes without understanding what they are doing, but it helps psychologically. "Instead of a black box stopping your system from doing what you wanted, now you have a transparent box."

System administrators have a much nicer set of tools to manage policies as well as filesystem labels. audit2why can analyze SELinux output to provide reasons, once again with possible fixes, for policy violations. It is "not the optimum way to develop policy", but it can help. In addition, semanage is the "go to tool" for managing SELinux that is becoming quite powerful.

Policy development has several GUI tools that have become available. SLIDE is an Eclipse plugin that assists in policy development. It also includes support for testing and deploying policies. Hitachi has developed SEEdit, which is a tool that provides a simplified policy language specifically targeted at embedded devices. It is a higher-level language that removes much of the complexity from SELinux policy while still compiling into compatible policy files.

Performance and scalability have been two areas that have seen much work over the past few years. Many performance and memory reduction patches have come from Japan from the work on embedded SELinux. On the performance critical path, RCU has been used to eliminate some locking, while caching values rather than recalculating them has also provided better performance.

One of the areas that the SELinux hackers are most excited about is threat mitigation. "We have seen evidence that SELinux has provided protection for normal desktop users." Tresys tracks these kinds of threats in their SELinux Mitigation News. In the final analysis, this is what SELinux is meant to do, so it is gratifying to see concrete results.

SELinux has been adopted widely in Fedora and RHEL, but plans for the future include making it available on other distributions. Ubuntu is shipping SELinux in addition to AppArmor, while Debian and Gentoo are targeted for better SELinux support. SELinux techniques are being pushed beyond the kernel, into virtualization (XSM), the desktop (XACE), storage (Labeled NFS), and applications like databases (SEPostgreSQL). There is also a push into other operating systems, like the OpenSolaris Flexible MAC project.

The challenges facing SELinux in the future are in areas like usability, which is a "fundamental problem in security", and documentation, which is "not very good, in some ways really bad". Morris also wants to keep the community of users and developers growing.

While SELinux has had a difficult path—first in getting into the kernel at all, then to becoming usable, and finally to actually preventing the kinds of attacks it was designed to stop—the developers seem to overcome each hurdle. It is a complex beast, that in some ways defies analysis, but it can help to protect systems. Like it or hate it, it seems likely to be with us for a long time.