[capsicum] Capability Mode (fwd)
- From: Robert Watson <rwatson@xxxxxxxxxxx>
- Date: Fri, 17 Dec 2010 15:04:39 +0000 (GMT)
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@xxxxxxxxxxxx>
To: cl-capsicum-discuss@xxxxxxxxxxxxxxx
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
_______________________________________________
freebsd-security@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscribe@xxxxxxxxxxx"
- Prev by Date: Re: Allegations regarding OpenBSD IPSEC
- Next by Date: Re: packet capture and if_bridge ignore bpf rules
- Previous by thread: Claims of FBI backdoors in OpenBSD cryptographic code
- Next by thread: Intermediate doc hacker project: Document security releases on the web site
- Index(es):
Relevant Pages
|