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 <[email protected]>
To: [email protected]
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
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "[email protected]"
