[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
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
The Q&A session appears to have recorded poorly, unfortunately.
Main Index |
Thread Index |