6 ms·

FreeBSD Foundation Announces Capsicum Framework Project

95 points by dallagi 13y ago

emaste 13y ago
Some background on Capsicum, from http://www.cl.cam.ac.uk/research/security/capsicum/ http://www.cl.cam.ac.uk/research/security/capsicum/ Capsicum is a lightweight OS capability and sandbox framework developed at the University of Cambridge Computer Laboratory, supported by a grant from Google. Capsicum extends the POSIX API, providing several new OS primitives to support object-capability security on UNIX-like operating systems: * capabilities - refined file descriptors with fine-grained rights * capability mode - process sandboxes that deny access to global namespaces * process descriptors - capability-centric process ID replacement * anonymous shared memory objects - an extension to the POSIX shared memory API to support anonymous swap objects associated with file descriptors (capabilities) * rtld-elf-cap - modified ELF run-time linker to construct sandboxed applications * libcapsicum - library to create and use capabilities and sandboxed components * libuserangel - library allowing sandboxed applications or components to interact with user angels, such as Power Boxes. * chromium-capsicum - a version of Google's Chromium web browser that uses capability mode and capabilities to provide effective sandboxing of high-risk web page rendering. There's also a video of Robert Watson's 2010 Capsicum talk at http://www.youtube.com/watch?v=raNx9L4VH2k http://www.youtube.com/watch?v=raNx9L4VH2k Edited to add: The FreeBSD Foundation plans to significantly increase spending on projects (such as this one) as well as full-time staff members in 2013: https://news.ycombinator.com/item?id=5564478 https://news.ycombinator.com/item?id=5564478
- qompiler 13y ago
  Hm yes, I know some of these words
tptacek 13y ago
Interesting to note Daniel Bernstein's take on least-privilege design, which Capsicum is an example of. Bernstein wrote qmail, which can safely claim to be the first modern least-privilege mail server design, and one of the first modern least-privilege designs of any sort. qmail tries to derive some additional security from splitting up its activities into multiple components running with different credentials. Despite qmail's extremely impressive security record (it is one of the most impressive bits of secure code ever written), Bernstein considers his privilege-separation experiment a failure. http://cr.yp.to/qmail/qmailsec-20071101.pdf http://cr.yp.to/qmail/qmailsec-20071101.pdf The problem is that minimizing the capabilities of a computer program often just moves the goalposts for an attacker. Too many times, unexpectedly conceding to an attacker some privileges on a target results in a compromise of all meaningful privileges, because attackers can use those new privileges to launch further attacks. The problem is even harder in modern web applications, because breaking the operating system almost doesn't matter; all the attacker really needs is a working handle on the database.
- jfb 13y ago
  Really interesting read, thanks. djb is entertaining as always.
  - danielweber 13y ago
    Reading his paper about his students bug-finding contest, I think I remember them on the bugtraq mailing list for his course. "This is so a remote exploit, my professor said so, and said I shouldn't listen to you guys." Fun times. We've all grown up since then, I think, self included. I think.
- cperciva 13y ago
  I disagree with djb here: Although it's true that privilege separation rarely eliminates vulnerabilities, I maintain that it can make vulnerabilities far less dangerous. To take an example the Capsicum people are fond of: Decompression. zlib has a long history of vulnerabilities in decompression of corrupt data, so it's a natural thing to run inside a sandbox. djb's argument is "but a vulnerability in zlib is still bad because it can return incorrect output", which is true as far as it goes, but it completely misses the important point that it prevents the attacker from accessing anything not inside zlib's sandbox -- say, connections to a database.
  - stock_toaster 13y ago
    > "but a vulnerability in zlib is still bad because it can return incorrect output" which is true as far as it goes, but it completely misses the important point that it prevents the attacker from accessing anything not inside zlib's sandbox -- say, connections to a database. Wouldn't being able to impact the output of zlib decompression also impact whatever is subsequently working on that output next though (just 'moving the goalpost')?
  - tptacek 13y ago
    I think Dan Bernstein is an absolutist, in the sense that he believes error-free ("invulnerable") programs are commercially achievable. I don't agree, but I think his perspective sheds some pretty valuable light.
trotsky 13y ago
Anyone familiar enough with such things to compare its theoretical or practical abilities compared with the seccomp/namespaces/syscall filters/selinux world? I mean besides their horribly disjoint nature.
- mhandley 13y ago
  One of the problems with security mechanisms based around system-call interposition (such as systrace) is that it's very hard to avoid concurrency vulnerabilities. To avoid this, you need to push the security mechanisms down into the kernel, as with SELinux. The downside is that configurable policy becomes harder that way. Capsicum is all about configurable and extensible security policy using capabilities. There's a nice explanation of concurrency vulnerabilities in chapter 2 of Robert Watson's thesis, and a comparison of Capsicum vs other security mechanisms in chapter 5. It's worth looking at, if you're interested in these issues: http://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-818.html http://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-818.html
  - trotsky 13y ago
    thanks!

95 points by dallagi 13y ago

Some background on Capsicum, from http://www.cl.cam.ac.uk/research/security/capsicum/ http://www.cl.cam.ac.uk/research/security/capsicum/ Capsicum is a lightweight OS capability and sandbox framework developed at the University of Cambridge Computer Laboratory, supported by a grant from Google. Capsicum extends the POSIX API, providing several new OS primitives to support object-capability security on UNIX-like operating systems: * capabilities - refined file descriptors with fine-grained rights * capability mode - process sandboxes that deny access to global namespaces * process descriptors - capability-centric process ID replacement * anonymous shared memory objects - an extension to the POSIX shared memory API to support anonymous swap objects associated with file descriptors (capabilities) * rtld-elf-cap - modified ELF run-time linker to construct sandboxed applications * libcapsicum - library to create and use capabilities and sandboxed components * libuserangel - library allowing sandboxed applications or components to interact with user angels, such as Power Boxes. * chromium-capsicum - a version of Google's Chromium web browser that uses capability mode and capabilities to provide effective sandboxing of high-risk web page rendering. There's also a video of Robert Watson's 2010 Capsicum talk at http://www.youtube.com/watch?v=raNx9L4VH2k http://www.youtube.com/watch?v=raNx9L4VH2k Edited to add: The FreeBSD Foundation plans to significantly increase spending on projects (such as this one) as well as full-time staff members in 2013: https://news.ycombinator.com/item?id=5564478 https://news.ycombinator.com/item?id=5564478

qompiler 13y ago
Hm yes, I know some of these words

tptacek 13y ago

Interesting to note Daniel Bernstein's take on least-privilege design, which Capsicum is an example of. Bernstein wrote qmail, which can safely claim to be the first modern least-privilege mail server design, and one of the first modern least-privilege designs of any sort. qmail tries to derive some additional security from splitting up its activities into multiple components running with different credentials. Despite qmail's extremely impressive security record (it is one of the most impressive bits of secure code ever written), Bernstein considers his privilege-separation experiment a failure. http://cr.yp.to/qmail/qmailsec-20071101.pdf http://cr.yp.to/qmail/qmailsec-20071101.pdf The problem is that minimizing the capabilities of a computer program often just moves the goalposts for an attacker. Too many times, unexpectedly conceding to an attacker some privileges on a target results in a compromise of all meaningful privileges, because attackers can use those new privileges to launch further attacks. The problem is even harder in modern web applications, because breaking the operating system almost doesn't matter; all the attacker really needs is a working handle on the database.

jfb 13y ago
Really interesting read, thanks. djb is entertaining as always.
- danielweber 13y ago
  Reading his paper about his students bug-finding contest, I think I remember them on the bugtraq mailing list for his course. "This is so a remote exploit, my professor said so, and said I shouldn't listen to you guys." Fun times. We've all grown up since then, I think, self included. I think.
cperciva 13y ago
I disagree with djb here: Although it's true that privilege separation rarely eliminates vulnerabilities, I maintain that it can make vulnerabilities far less dangerous. To take an example the Capsicum people are fond of: Decompression. zlib has a long history of vulnerabilities in decompression of corrupt data, so it's a natural thing to run inside a sandbox. djb's argument is "but a vulnerability in zlib is still bad because it can return incorrect output", which is true as far as it goes, but it completely misses the important point that it prevents the attacker from accessing anything not inside zlib's sandbox -- say, connections to a database.
- stock_toaster 13y ago
  > "but a vulnerability in zlib is still bad because it can return incorrect output" which is true as far as it goes, but it completely misses the important point that it prevents the attacker from accessing anything not inside zlib's sandbox -- say, connections to a database. Wouldn't being able to impact the output of zlib decompression also impact whatever is subsequently working on that output next though (just 'moving the goalpost')?
- tptacek 13y ago
  I think Dan Bernstein is an absolutist, in the sense that he believes error-free ("invulnerable") programs are commercially achievable. I don't agree, but I think his perspective sheds some pretty valuable light.

trotsky 13y ago

Anyone familiar enough with such things to compare its theoretical or practical abilities compared with the seccomp/namespaces/syscall filters/selinux world? I mean besides their horribly disjoint nature.

mhandley 13y ago
One of the problems with security mechanisms based around system-call interposition (such as systrace) is that it's very hard to avoid concurrency vulnerabilities. To avoid this, you need to push the security mechanisms down into the kernel, as with SELinux. The downside is that configurable policy becomes harder that way. Capsicum is all about configurable and extensible security policy using capabilities. There's a nice explanation of concurrency vulnerabilities in chapter 2 of Robert Watson's thesis, and a comparison of Capsicum vs other security mechanisms in chapter 5. It's worth looking at, if you're interested in these issues: http://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-818.html http://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-818.html
- trotsky 13y ago
  thanks!