[capsicum] Capability Mode (fwd)

[Robert Watson]

Dear all:

Some of you will have spotted Cambridge's "Capsicum" paper in the USENIX 
Security proceedings this summer, and presented previously at the Cambridge 
and Ottawa FreeBSD developer summits.  We are in the throes of preparing basic 
kernel support for Capsicum to merge to the FreeBSD tree.  This work will 
enter the tree in a number of phases -- some will require more architectural 
discussion in the FreeBSD community (such as process descriptors), but other 
bits (such as capability mode) we'll assume people have been following along 
and plan to merge unless anyone screams.

If you're interested in the topic, and in particular, interested in helping us 
review and test Capsicum patches as they head in the direction of 9-CURRENT, 
please join us on the cl-capsicum-discss mailing list.  You can learn more 
about Capsicum, including finding papers and talks to date, and a pointer to a 
recording of the USENIX Security talk on the topic, here:

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

You can subscribe to our mailing list here:

   https://lists.cam.ac.uk/mailman/listinfo/cl-capsicum-discuss

Over the next few months we plan to kick off a larger project to explore 
applications of Capsicum in other parts of FreeBSD than the ones explored to 
date.

A hand-wave at a general schedule for merging various new TrustedBSD-related 
features to FreeBSD can be found here:

   http://wiki.freebsd.org/TrustedBSDSchedule

It is very much a hand-wave, however!  (It seems clear already that capability 
mode support might well slip to January)

Robert N M Watson
Computer Laboratory
University of Cambridge

---------- Forwarded message ----------
Date: Tue, 14 Dec 2010 21:55:22 -0330
From: Jonathan Anderson <jonathan.anderson at cl.cam.ac.uk>
To: cl-capsicum-discuss at lists.cam.ac.uk
Subject: [capsicum] Capability Mode

Here's a patch against -CURRENT (r216376) that is the first step in a multi-phase programme:

1. Capability mode with a restrictive syscall mask (no openat(2) functions, etc.)
2. Capabilities
3. Deep semantic constraints which allow openat(2), etc. - once we've convinced ourselves that our changes to namei() and friends don't introduce race conditions w.r.t. rename
4. Process descriptors - once we've convinced ourselves that we haven't broken e.g. the garbage collection of UNIX domain sockets

Anyway, please find the proposed first patch attached.

Comments?


Jon