Re: Capsicum: practical capabilities for UNIX

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

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:

  http://www.cl.cam.ac.uk/research/security/capsicum/

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

  http://www.youtube.com/watch?v=raNx9L4VH2k

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

Robert