tech-kern archive

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

Re: Capsicum: practical capabilities for UNIX

On Mon, 27 Sep 2010, Jukka Ruohonen wrote:

On Sun, Sep 26, 2010 at 08:48:45PM -0400, Perry E. Metzger wrote:
They did Chrome in the paper, and it required very few lines of code (under 100). They did other tests too. It appears that they've had quite a bit of success in creating a very usable API here. I'm not entirely surprised, given the nature of what they're doing.

Just a little historical remark.

I am little puzzled why Watson et. al. did not bother to mention Linux capabilities that have existed for a long time. The Linux API is almost identical to the one proposed in the "capsicum" paper. And yet, Linux capabilities are seldom used.

We did, but it was a bit oblique:

  Capsicum capabilities should not be confused with operating system
  privileges, occasionally referred to as capabilities in the OS literature.

The only similarity between the POSIX.1e API and Capsicum capabilities is the function name prefix "cap_", making them markedly non-identical. More below.

Perhaps a general perception would be that somehow these capabilities slided to sidetracks from the very beginning. One probable cause for this was that the vendor-independent committee that started the whole thing was unable to provide something that could have become an actual standard across UNIX platforms and their derivatives. The result was only a draft POSIX document, IEEE 1003.1e, released in 1997, which is considered a failure by many.

Maybe there is something to learn from here.

POSIX.1e "capabilities" are actually coarse-grained OS privileges, an extension to the process credential granting system privileges such as exemption to discretionary access control, management privileges such as the right to reboot, etc. Linux implements a variation on that theme, as do most other UNIX systems (Solaris has a particularly mature variation integrated with their RBAC scheme). These solve (or, in some cases, don't solve) an orthogonal problem in UNIX security: how to decompose root privilege.

Capabilities in a classic security sense are unforgeable tokens of authority that can be delegated. Capsicum capabilities are a refinment of (and at times, an extension to) the UNIX file descriptor model that allow finer-grained delegation of kernel objects to sandboxed processes. Capsicum's capability mode denies access to (most) global OS namespaces: the only way to get rights into the sandbox is to delegate them using a capability-like approach. Because a strict interpretation of this model means you spend a lot of time forwarding file descriptors, Capsicum takes a slightly less severe variation on that theme: you can delegate subtrees by delegating a directory capability (although there's no requirement to do so).

You might reasonably think of Capsicum as a set of OS primitives to support privilege escalation (as found in OpenSSH) or application compartmentalization (as found in Chromium). A similarly reasonable viewpoint is that a capability model complements a mandatory access control model, since they solve different sorts of problems (a viewpoint taken by many but not all in OS security).

The paper on our web site goes into more detail:

However, the talk from USENIX presents the philosophy in a possibly more accessible way:

The Q&A session appears to have recorded poorly, unfortunately.


Home | Main Index | Thread Index | Old Index