The return of authoritative hooks

The original version of the patch, posted by Pavel Emelyanov, set up a control group for the management of device accessibility within containers. The actual rules - and their enforcement - were stored deep within the device model subsystem. This drew an objection from Greg Kroah-Hartman, who suggested that, instead, this kind of access control should done either with udev or with the Linux security module (LSM) subsystem. Udev does not give the desired degree of control and, apparently, can be problematic for those wanting to run older distributions within containers, so it was not seriously considered. The LSM suggestion was, after some resistance, taken to heart, though.

The result was the device whitelist LSM patch, posted by Serge Hallyn. It was a stacking security module which made changes to a number of hooks. This is where James Morris came in and suggested that, instead, the whitelist should just be added to the existing capabilities security module. Then there would be no need for a separate module and things could be generally simplified.

So Serge duly rolled out version 3 of the patch which moved the whitelist into the capabilities module. But this one ran into resistance as well. Quoting James Morris again:

Casey Schaufler also didn't like this idea:

At this point, the complaint was clearly not with just the device whitelist, but with the capabilities module as well. It seems that capabilities are a bit of a poor fit with the LSM idea as a whole. The fact that they exist at all is a bit of a historical artifact; some developers wanted to see them implemented that way to show the flexibility of the LSM interface and to let capabilities be omitted from embedded setups. As it happens, it's still not possible to remove capabilities, and they impose a bit of a cost on all other security modules.

The core problem is this: LSM, fundamentally, is a restrictive mechanism. An LSM hook can deny an action, but it can never empower a process to do something it would not have been allowed to do in the absence of the security module. The decision to disallow "authoritative hooks" was made explicitly back in 2001 as a way of restricting the scope of LSM modules and, hopefully, ensuring that those modules would not themselves become security problems.

But capabilities are an inherently authoritative mechanism - a capability check verifies the existence of a special permission which would otherwise not be there. The device whitelist is the same sort of thing: it grants access which would otherwise be denied. So it fits poorly with the LSM model.

Serge came back with yet another patch which takes the whitelist code out of the LSM framework and, instead, inserts a separate set of hooks into the relevant places in the code. Those hooks sit right next to the LSM hooks, but operate in a permissive manner. So far, this approach seems to be passing muster, with no developers (yet) talking about booting it out into yet another subsystem.

Things may yet change, though. Casey Schaufler is now talking about the creation of a "Linux privilege module" framework for the management of all permissions checks. The normal discretionary access control checks could be moved there, as could all capability and "are they root?" logic. And, of course, the device whitelist code. Nobody has really spoken out against this idea - but, then, nobody has seen any code yet either. But, if things continue in this direction, authoritative hooks may have finally found a home, many years after having been rejected from the LSM mechanism.

>An LSM hook can deny an action, but it can never empower a process to do something it would
not have been allowed to do in the absence of the security module.

The MultiAdm LSM [ http://lwn.net/Articles/255650/ ] can give regular users extra
capabilities, empowering them to do something they would not have been allowed otherwise.

From the article, it seems LSM is seen as a way to restrict a user's rights from an original
set, where I think it should be a way to say who can do what.

Each user could then have a tick-box kind of configuration, which is in fact similar to making
a user part of a group to give them access to a category of devices.

But I suppose the all idea now would be to say like: user A cannot access /dev/sda* (the hard
disk), but can access /dev/sdb* (a USB key that is known to belong to them).

Correct?

I would hope so too. I've always liked the concept of systrace - and it's simplicity is IMHO
good for security.

Hm.  Systrace site says this on security:
"Just keep in mind that ptrace has not been designed as a security 
primitive and while the ptrace backend can restrict the behavior of 
programs in non-adversarial settings, there are many ways to circumvent 
it."

Maybe ltrace (new kernel implementation for ptrace that is supposed to 
solve many of its problems) could help also on this?

You mean Roland McGrath's utrace?

While incredibly nifty and a long-overdue revamp of the awful ptrace() 
interface, utrace hasn't been designed as a security enforcement mechanism 
either :)

(however, things like UML are in effect using it as such in any case, so 
security-hole-inducing bugs in ptrace() *are* likely to get fixed.)

> You mean Roland McGrath's utrace?

Sorry, yes.  I noticed that first/early patch(es) of it have gone to 
2.6.25. 


> (however, things like UML are in effect using it as such in any case, so 
security-hole-inducing bugs in ptrace() *are* likely to get fixed.)

Sounds promising. :-)

Could someone explain to me why granting someone something you don't have by default
(authorative) is different from not granting something you have by default to everyone else
(restrictive)?