by Andy Oram
Related link: http://fedora.redhat.com/projects/selinux/
SElinux is an impressively designed but notoriously hard-to-configure
set of kernel hooks that enforce Orange Book-style security on Linux.
Full support for SELinux takes effort, but when I first heard about
Fedora's new targeted policies for SELinux, I was willing to
tell the Red Hat folks "thanks, but no thanks." A conversation with
their Dan Walsh changed my mind.
The orginal SELinux approach was that anything not expressly permitted
was forbidden. Technically, this meant that every program anybody
would ever run had to be configured with a policy that
indicated what files it could touch, who could run it, and every other
aspect of the program that might present a risk. Practically, this
meant that you'd start your system and find that some obscure daemon
wasn't running--and the only diagnostic aid you had was a few lines
listing process IDs and inodes. It didn't help that all the resources
(files and so forth) had to be tagged accurately, along with programs
(This is the point where I feel it justified to mention that O'Reilly
about basic SELinux use.)
Fedora users were getting frustrated and turning SELinux off, so Red
Hat figured they had to take a new tack before making SELinux the
default in Red Hat Enterprise Linux (which they did last week,
announcing RHEL 4 at LinuxWorld).
The concept of targeted policies is a compromise. Certain well-known
targets such as Apache get the full SELinux treatment. Other services
and programs are left with the old Unix security. Over time, more and
more programs will move into the targeted area.
It's easy to see why I wasn't impressed by targeted policies. The
program you don't protect is precisely the one that intruders
attack. I figured that if you care enough about your house to station
someone with a shotgun at the front door, you should also have
somebody peering out the side window.
Dan deepened my thinking about this. We have to look at the solution
as an evolution. SELinux is still hard to configure, and while the
field learns more about how to develop high-level policy languages and
easy-to-use tools, we should take it slow. Some SELinux is better than
Dan pointed out that firewalls went through growing pains too, and at
the beginning many people just turned them off because they were too
restrictive. With SELinux as with firewalls, providers have to refine
the concept over time.
The older SELinux approach was subtractive: install it, see what
breaks over time, and fix the bugs one by one. Targeted policies are
additive: build up security as you go along.
SELinux is based on well-established principles, and it ought to be a
step forward. But to get there, a lot of us have to be patient and try
it out, to give researchers a base for further improvements.
Will you use SELinux?
Poor SE Linux is worse than none
Just like firewalls, though, a poorly configured SE Linux would be worse than none, because it gives the appearance of being secure, when it may not be.