A subtle change in 2.6.25 recently left Andrew Morton with a less than
completely functioning system, but it also demonstrated a user-space
interface that may sometimes be overlooked: SELinux. The problem stemmed
from a change to facilitate containers by making /proc/net into a
symbolic link, which tripped up SELinux policies that had been
written for earlier kernels. Putting policy into user space is a guiding
principle of kernel development, but that can sometimes lead to an unexpected
synchronization required between those policies and the kernel.
The change itself was fairly minor, making /proc/net be a symbolic
link to /proc/self/net so that containers would only see their
network devices, rather than those of the enclosing system. But when
Morton ran a recent kernel on his Fedora Core 5 and 6 systems, he got:
sony:/home/akpm> ifconfig -a
Warning: cannot open /proc/net/dev (Permission denied). Limited output.
Further investigation found that even ls
got permission errors
when looking at /proc/net
. As is usual with mysterious
"permission denied" errors, SELinux was the underlying cause.
When the change was made, back in March, it was reviewed by the SELinux
developers, but no one noticed that it would cause an additional permission
check—on the symbolic link itself. So, when resolving things like
/proc/net/dev or other entries in that directory, the "labels" on
the symbolic link were checked. Of course, /proc is a synthetic
filesystem, so the labels are generated from SELinux code rather than
retrieved from extended attributes (xattrs).
Distributions have updated their policies to allow access to the symbolic
link—probably by noticing the SELinux denial in log messages—so
never saw the problem. As Morton found out, though, existing distribution
(those shipped with FC5 and FC6 for
example) would still disallow the access. Morton regularly runs newer
kernels with older distributions to try to catch exactly this kind of
error; he is probably one of very few, perhaps the only one, doing that.
Because the distribution-supplied kernel was being changed, some argued
that requiring users to update their SELinux policies is not an onerous
Paul Moore puts it this
I'm in the minority here, but in my mind once you step away from the
distro supplied kernel (also applies to other packages, although those
are arguably less critical) you should also bear the responsibility to
make sure you upgrade/tweak/install whatever other bits need to be
Morton did not buy that argument saying:
Nope. Releasing a non-backward-compatible kernel.org kernel is a big
We'll do it sometimes, with long notice, much care and much deliberation.
We did it this time by sheer accident. That's known in the trade as a
But SELinux developer Stephen Smalley points out that permissions checks
are not normally considered part of the kernel to user space interface. It
is something of a gray area, though. Clearly the standard UNIX permission
checks are part of that interface, at least partially because the
kernel does handle the policy for those checks. Since the policies that
govern the decisions about SELinux
access denial come from user space, it is a bit hard to argue that
changes to the kernel will not ripple out. Smalley describes the problem:
I should note here that for changes to SELinux, we have gone out of our
way to avoid such breakage to date through the introduction of
compatibility switches, policy flags to enable any new checks, etc
(albeit at a cost in complexity and ever creeping compatibility code).
But changes to the rest of the kernel can just as easily alter the set
of permission checks that get applied on a given operation, and I don't
think we are always going to be able to guarantee that new kernel + old
policy will Just Work.
One possible solution to the immediate problem was floated by Smalley:
SELinux could change the
label that it returns for symbolic links under /proc. It is not
clear that anyone really wants that change, and there has been no movement
to add it. As Morton says, "people who are shipping 2.6.25-
and 2.6.26-based distros probably
wouldn't want such a patch in their kernels anyway."
Longer term, Eric Biederman asks about
supporting xattrs for /proc. That would allow user space to label
the proc filesystem appropriately, removing one of the special cases.
Unfortunately, doing so would create yet another incompatibility between
newer kernels and older user spaces.
In the end, because the bug was only seen
by Morton, many months after it was introduced, it may just be ignored.
The larger issue of how permissions checks fit into the kernel to user
space interface, though, may rear its head again.
to post comments)