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@cl.cam.ac.uk> To: cl-capsicum-discuss@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