FreeBSD Foundation Announces Capsicum Framework Project(lists.freebsd.org)
lists.freebsd.org
FreeBSD Foundation Announces Capsicum Framework Project
http://lists.freebsd.org/pipermail/freebsd-announce/2013-April/001466.html
3 comments
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
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.
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
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.
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.
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.
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.
I'm somewhere between the two of you: I think error-free programs are achievable, but I realize it's a huge amount of work and it's impossible to ever know for certain if you've succeeded. I see capsicum as something to help bridge the gap between "I don't think there are any bugs in here" and "this program is safe to run".
Classical example of "you never know for certain if you've succeeded": http://en.wikipedia.org/wiki/IEFBR14#History_from_the_RISKS_... (see also the takk page and the refernced http://www.miketaylor.org.uk/tech/oreilly/iefbr14.html for some comments on the veracity of these statements)
There's always the great ivory tower known as Provable Programming.
Provable Programming provably requires non-Turing-complete languages.
Which isn't an insuperable barrier, to be sure, but it's a big piece of evidence against its practicality in actual commercial environments.
Which isn't an insuperable barrier, to be sure, but it's a big piece of evidence against its practicality in actual commercial environments.
why has this been downvoted? if this is wrong, a simple "no, this is wrong. see e.g. blah" would have been nice.
Diagonal proofs like the Halting Problem say that in general you can not prove properties about all programs in a Turing complete language. Thus, there is a class of troublesome programs.
Likewise there is obviously a great number of programs in Turing complete languages that you can prove properties about. Thus, there is a class of pleasant programs (or [program, property] pairs).
We do not know for certain how many of the programs that we want to write that is in each class. I would venture a guess that >99% of all programs ever written are in the "nice" class. If it is really impossible to reason about some property of a program, why would you think it works?
Likewise there is obviously a great number of programs in Turing complete languages that you can prove properties about. Thus, there is a class of pleasant programs (or [program, property] pairs).
We do not know for certain how many of the programs that we want to write that is in each class. I would venture a guess that >99% of all programs ever written are in the "nice" class. If it is really impossible to reason about some property of a program, why would you think it works?
[deleted]
Another important point is that the attacker already has the ability to affect the decompressed output, since they are presumably responsible for the compressed input.
Depending on how you set things up you might use one sandbox to perform multiple decompression calls, so the attacker might be able to mangle someone else's data. But yes, if you set up a new sandbox for each inflate you're safe.
Hash the decompressed data and check the result returned by zlib.
> "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.
This post also drove me to go re-read some of djb's IM2000 stuff, which is interesting and valuable, and of which, I think a healthy chunk would be fun to implement, but man alive is dude ever obsessive over mailing lists. Mailing lists!
When he was doing that work, mailing lists were much more important than they are today, and the industry standard way to implement them was with Majordomo, a horrible collection of buggy Perl scripts that required you to allocate a whole server to handling mailing list traffic and would promptly drive that server to its knees.
Bernstein's mailing list software recovered multiple Unix servers for us at EnterAct; we ended up delegating them to a 486SX.
Bernstein's mailing list software recovered multiple Unix servers for us at EnterAct; we ended up delegating them to a 486SX.
Oh, no doubt. I have a patch [1] in Sendmail from the early '90s w/r/t mailing lists, and I remember what an almighty hairball they were. But that's water under the bridge now, and the focus reads as quaint (even as the IM2000 architecture itself is fairly interesting).
[1] Not much of a distinction for someone running mail services in the early '90s, sad to say.
[1] Not much of a distinction for someone running mail services in the early '90s, sad to say.
I recall patching majordomo to sort the huge subscriber list (wanting to know a court's actions as they happened) by reverse string, to bring like domains together, before splitting it into chunks of N subscribers and handing those individually to sendmail. Before that, sendmail would be given one email with a huge subscriber list and plod through the recipients, without sorting them so it contacted the same SMTP server many times, and one unresponsive peer would stall delivery for all that followed.
Note that there's nearly a decade of experience, research, and development between the "UNIX security holes" course djb mentions in that paper, and today; Capsicum is not just an implementation of mid-2000s privilege separation. I believe the examples he presents (xine-lib buffer overflow obtaining access to a user's files, or one web page in browser stealing from and corrupting other pages) are capable of being generally addressed by Capsicum.
djb's stance seems to require "avoiding bugs," a laudable bug extremely difficult goal for most programmers. Capsicum aims to make it easy to minimize the damage possible if a bug is exploited. Capsicum-enabled gzip is a good example: an exploit in the decompression code is limited to modifying the content of the output stream.
djb's stance seems to require "avoiding bugs," a laudable bug extremely difficult goal for most programmers. Capsicum aims to make it easy to minimize the damage possible if a bug is exploited. Capsicum-enabled gzip is a good example: an exploit in the decompression code is limited to modifying the content of the output stream.
I don't think I disagree, but for the sake of argument, if the cost of addressing flaws with progressively pickier authorization controls exceeds the cost of eradicating bugs, that's not a success for least-privilege.
My bigger bone to pick here is that the security frontier has shifted; we're no longer as interested in the border between applications and the operating system as we are in the border between different pieces of application code, and the border between the application and the database.
My bigger bone to pick here is that the security frontier has shifted; we're no longer as interested in the border between applications and the operating system as we are in the border between different pieces of application code, and the border between the application and the database.
There was a recent XKCD cartoon that touched on this; the focus on separation of privilege has historically been couched in terms of protecting one user from another. But the overwhelming majority of computing devices being sold are no longer multiuser, even as they maintain the outdated modalities.
I'm not happy that my single-user machine even has the concept of multiple users; that is way, way, way too coarse a level of granularity for privilege separation.
I'm not happy that my single-user machine even has the concept of multiple users; that is way, way, way too coarse a level of granularity for privilege separation.
Indeed, this is one of the things Capsicum is intended to address.
Quoting from Robert Watson's PhD thesis, "A purely system-centric view, however, fails to address the observation that the security interactions of "users" are decreasingly central: desktop and notebook computers, tablet PCs, and smart phones typically have exactly one user."
...
"Capsicum addresses these problems by introducing new (and complementary) security primitives to support compartmentalisation: capability mode and capabilities. Capsicum capabilities should not be confused with operating system privileges, occasionally referred to as capabilities in the OS literature. Capsicum capabilities are an extension of UNIX file descriptors, and reflect rights on specific objects, such as files or sockets. Capabilities may be delegated from process to process in a granular way in the same manner as other file descriptor types: via inheritance or message-passing."
http://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-818.html
Quoting from Robert Watson's PhD thesis, "A purely system-centric view, however, fails to address the observation that the security interactions of "users" are decreasingly central: desktop and notebook computers, tablet PCs, and smart phones typically have exactly one user."
...
"Capsicum addresses these problems by introducing new (and complementary) security primitives to support compartmentalisation: capability mode and capabilities. Capsicum capabilities should not be confused with operating system privileges, occasionally referred to as capabilities in the OS literature. Capsicum capabilities are an extension of UNIX file descriptors, and reflect rights on specific objects, such as files or sockets. Capabilities may be delegated from process to process in a granular way in the same manner as other file descriptor types: via inheritance or message-passing."
http://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-818.html
And my point is that capsicum is a way to impose boundaries between different parts of a single application.
Neat. Can you say a little more about that?
Not really -- I'm not involved with capsicum, either as a developer or as a user (yet... I'm waiting for this project to make it easier for me to integrate capsicum into my code). What I know is just based on talking to the people behind capsicum.
The best information is on the Capsicum website: http://www.cl.cam.ac.uk/research/security/capsicum/
Particularly interesting bits:
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.
Library self-compartmentalization - we are adapting a number of commonly-used libraries, such as compression and image processing libraries, to automatically execute risky portions of their code in capability mode sandboxes. This will allow largely or entirely unmodified applications, such as web browers, to benefit from lightweight and easy-to-deploy sandboxing.
The best information is on the Capsicum website: http://www.cl.cam.ac.uk/research/security/capsicum/
Particularly interesting bits:
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.
Library self-compartmentalization - we are adapting a number of commonly-used libraries, such as compression and image processing libraries, to automatically execute risky portions of their code in capability mode sandboxes. This will allow largely or entirely unmodified applications, such as web browers, to benefit from lightweight and easy-to-deploy sandboxing.
If you're not primarily spending time doing audits on n-tier web and enterprise, I'm not sure how inclusive that is. At least for user devices os and interprocess defense along with chains of trust and mitigation via painless refresh is all pretty os centric. It's just not as rbac centric.
Really interesting read, thanks. djb is entertaining as always.
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.
Fun times. We've all grown up since then, I think, self included. I think.
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.
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
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
thanks!
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
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