Stephen Smalley has a mission: he would like to get the NSA's
Security-Enhanced Linux (SELinux) patches merged into the 2.5 kernel. In
theory this task should not be all that hard: the whole point of the Linux
Security Module patches is to make it possible to plug in new security
regimes at will. At the moment, however, things don't actually work that
well. Thus a couple of new patches which have been sent out for comments.
The first patch is relatively
straightforward. Files in SELinux have "security labels" which provide
fine-grained control over which processes can access them. SELinux needs a
mechanism to set and read those labels. So the extended attributes patch
just provides an easy mechanism for the manipulation of security labels on
files in an ext3 filesystem. Eventually, says Stephen, it will be
necessary to add this interface to most filesystems - including the virtual
ones. For example, a suitably patch version of OpenSSH can set labels on
pseudo terminals if /dev/pts supports them..
The second patch is a little trickier.
SELinux also attaches attributes to processes, and it needs an interface by
which those attributes can be manipulated from user space. At one point,
this interface was provided by the general-purpose sys_security()
system call that was part of the LSM patch. sys_security() did not sit well with a number of kernel
developers, however, and it was removed in 2.5.50. General-purpose
"multiplexor" system call interfaces are very much out of favor; they make
it almost impossible to understand the actual interface exported by the
So SELinux has to figure out a way to manage process attributes without
sys_security(). Their options would be (1) to add a new,
special-purpose system call, or (2) find some other, trickier way of
doing it. They opted for the latter.
With the process attributes patch, each /proc entry corresponding
to a process
would have a new attr subdirectory, containing three files.
attr/current could be read to obtain the current security
attributes for a process, but (in SELinux, at least), could not be
written. A process can write its own attr/exec file, which
is a place to store process attributes for the future. The next time that
the process performs an exec() call to run a new image, the
attributes stored in attr/exec will be applied. Needless to say,
the currently loaded security module gets veto power over which attributes
can be written to that file. Finally, attr/fscreate contains
attributes which will be applied to the next file created by the process.
Storing file attributes there avoids race conditions where a program
wearing a black hat attempts to access a file in the time between its
creation and when security attributes are applied.
Kernel developers do not like multiplexor interfaces, but it is probably
worth discussing whether system interfaces based on magic /proc
files are better. One could say that, with /proc, at least the
interface is visible. For now, at least, that discussion is not happening;
there have been, as of this writing, no public comments posted in the day
since the patches went out.
to post comments)