

FreeBSD Foundation Announces Capsicum Framework Project - dallagi
http://lists.freebsd.org/pipermail/freebsd-announce/2013-April/001466.html

======
emaste
Some background on Capsicum, from
<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>

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>

~~~
qompiler
Hm yes, I know some of these words

------
tptacek
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.

~~~
cperciva
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.

~~~
tptacek
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.

~~~
cperciva
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".

~~~
merlincorey
There's always the great ivory tower known as Provable Programming.

~~~
derleth
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.

~~~
ibotty
why has this been downvoted? if this is wrong, a simple "no, this is wrong.
see e.g. blah" would have been nice.

~~~
daivd
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?

------
trotsky
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
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>

~~~
trotsky
thanks!

