[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 <robert.watson%cl.cam.ac.uk@localhost>
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.
Main Index |
Thread Index |