tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Capsicum: practical capabilities for UNIX

On Tue, 28 Sep 2010, Bakul Shah wrote:

On Tue, 28 Sep 2010 09:33:33 BST Robert Watson <> 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.


Home | Main Index | Thread Index | Old Index