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
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
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
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
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
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
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
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
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.
to post comments)