Re: Capsicum: practical capabilities for UNIX

[Robert Watson <robert.watson%cl.cam.ac.uk@localhost>]

On Tue, 28 Sep 2010, Bakul Shah wrote:

> On Tue, 28 Sep 2010 09:33:33 BST Robert Watson <robert.watson%cl.cam.ac.uk@localhost> 
> wrote:
> > About ten years ago, I experimented with delegating UNIX privileges using 
> > file descriptors ("tokens"), but wasn't satisfied with the composition 
> > properties, so didn't reuse the idea in Capsicum.  In particular, the 
> > existing file descriptor behaviour of UNIX seems to align well with 
> > capability concepts in a way likely to work well with current applications 
> > (not a coincidence, of course, but hence using that as the starting point 
> > in Capsicum), whereas many existing UNIX programs have strong notions of 
> > manipulating privilege using UIDs rather than as file rights.  While it 
> > seemed that correct usage was likely possible, the potential for something 
> > catastrophic was worrying.
>
> To me the notions of file descriptors and capabilities align so well that I 
> would've considered mapping UIDs into this scheme somehow.  Did you consider 
> something like that? Mapping UIDs to a userfs or even a special kind of 
> pre-opened "file" descriptors?

Yes, the tokens code allowed UIDs to be delegated by attaching them to tokens 
and sending them via UNIX domain sockets.  Holding a UID token would authorize 
an exception to the normal restrictions on UID exchanges using setuid(), etc, 
although not affect other access control (which would be based only on the 
active version of the credential).

An example of what's possible with an approach like that: with the kerberos 
integration, a daemon would allow the exchange of a token holding a kerberos 
authenticator for a token authorizing use of the matching local user's UID, 
which has some nice properties -- not least, the ability to take an authorized 
upgrade approach to user login, rather than a trickle-down privilege approach. 
You could run login sessions with minimal privileges until they'd 
authenticated, then upgrade them, whereas today we run login sessions with 
maximal privileges until we downgrade them.

This isn't dissimilar to another idea we've played with, credential 
descriptors, which allow caching and restoring a full credential with a single 
system call, rather than having to frob many semantically different bits 
(UIDs, GIDs, MAC labels, resource limits, ...).

I'm not satisfied that we understand the impact on applications well enough to 
really push that much further.  The main situation in which it appeared useful 
was for network daemons that serviced multiple users from a process or thread 
pool (in which case per-thread creds are required -- implemented in Mac OS X 
and a few others).  However, it comes with its own set of risks that aren't 
well understood, and hence probably best avoided for the time being.

There was also a userfs talk at USENIX Security, which used a synthetic file 
system to allocate and perform book-keeping on ephemeral UIDs.  I have mixed 
feelings about this approach, since it was really designed to allow the 
creation of UID-based sandboxes, something that Capsicum may be better suited 
for.  I'm not sure they explored using it to do things along the lines of the 
Kerberos ticket exchange for UID acess model I described above.

Robert