Google Ports Capsicum To Linux, and Other End-of-Year Capsicum News

An anonymous reader writes "Security researcher Robert Watson at the University of Cambridge has posted a blog article describing recent progress on the Capsicum security model, which will shortly appear in FreeBSD 10.0 enabled by default, and has now been ported to Linux by Google, who have posted patches with the intent to upstream to the Linux kernel." Capability systems are pretty interesting.

Comments

Who came up with the name Capsicum?

[Anonymous Coward]

Its a real mouthful!

OMG!

[MouseTheLuckyDog]

An actual tech article on slashdot. Will my heart recover? Can someone explain what exactly Capsicum is?

Re:OMG!

[Anonymous Coward]

Its got a really hip name so probably not. With a name like that its probably more of a "concept", "architectural attitude" or something similar.

Re:OMG!

[Desler]

API for sandboxing processes.

Re:OMG!

[allanjude8027]

The video explains it, but it allows programs to 'drop' capabilities they no longer need. For example, tcpdump needs root access to open the network interface, but after that it can give up those capabilities, so if there is a bug in tcpdump and it gets compromised by a maliciously crafted packet, the attacker does not have an excess privileges to exploit.

Re:OMG!

[Anonymous Coward]

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

More at the link...

Re:OMG!

[fahrbot-bot]

Can someone explain what exactly Capsicum is?

Capsicum:

Capsicum is a genus of flowering plants in the nightshade family Solanaceae. Its species are native to the Americas, where they have been cultivated for thousands of years. In modern times, it is cultivated worldwide, and has become a key element in many regional cuisines. In addition to use as spices and food vegetables, capsicum has also found use in medicines. ...

The piquant (spicy) variety are commonly called chili peppers, or simply "chilies".

Use milk to calm the burn, not water or beer.

Re:OMG!

[TheRaven64]

There are a few big differences. The first is that SELinux is really an extension of the ACL approach: you have a big matrix with things that can do stuff, and things that can have stuff done to them, and a bit in each position indicating whether that combination is allowed. SELinux (and most ACL implementations) compress this, because a matrix with one row for every process-user pair and one column for every filesystem or kernel object would be huge. The goal of things like SELinux is for system administrators to be able to restrict the rights of certain things.

The goal of Capsicum is different. It's not intended to protect against malicious code, it's intended to protect against exploitable code. This is why, for example, Chromium splits itself into separate processes and tries to isolate them from the rest of the system: if one renderer hits something that triggers an exploit, the attacker shouldn't be able to take control of anything other than that page. Unfortunately, with SELinux, there's no way of isolating two processes that are instances of the same program and running as the same user from each other. This is because SELinux was never designed for application compartmentalisation.

When a program that's been compartmentalised using Capsicum starts, it enters capability mode with the cap_enter() system call. At this point, it can't create any new file descriptors and can only issue a whitelisted set of system calls that don't touch the global namespace. File descriptors become capabilities, in the classical sense: they're unforgeable tokens of authority, and the only way that the sandboxed process can communicate with the world outside. If you compromise a process that's sandboxed in this way, you can only access the file descriptors that it can access, and for something that's expecting to deal with untrusted data, this is likely to only be a socket for talking to the more privileged process, maybe a network socket to the server, and possibly a directory handle to a cache directory.

Of course, it's not a panacea. Capsicum sandboxed processes can still be susceptible to the confused deputy problem. They can receive new file descriptors (capabilities) via UNIX domain sockets from a more privileged process, and if they can persuade such a process to open something on their behalf that they shouldn't have then they can still elevate privilege. As with other mitigation techniques, it's all about making life harder for the attacker.

In FreeBSD 10, we're shipping a number of base system utilities that run in sandboxed mode by default, and a few more are currently being tested and should appear in 10.1. We're also including a friendly daemon called Casper that will provide services (e.g. DNS lookups) to sandboxed processes, without giving them the rights to create sockets.

Capsi . . . what?

[Idou]

Looks like it is the name of a type of flowering plant and appears to be the name of a capabilities-based security framework.

Apparently, it has nothing to do with the issue some geeks have with their caps lock key after surfing the web one handed . . .

Re:Capsi . . . what?

[xaxa]

In some countries (Australia, NZ and maybe more) bell peppers are called capsicum.

You do know some plant genera: Cannabis, Nicotiana, Thymus, Narcissus, Olea, Rosa, Tulipa, Prunus, Pinus, Crocus, Iris, Brassica, Coffea, Eucalyptus.

And there's always Amorphophallus titanum.

Looks interesting - I have a few questions

[Sits]

• How does this compare to existing (coarse grained) Linux capabilities?
• How does this compare to SELinux?
• Does this complement things like Linux's seccomp?
• What's the overhead compared to the above?
• Will FreeBSD ship a policy for a ssh/sshd?

Re:Looks interesting - I have a few questions

[TheRaven64]

Hi Sits,

How does this compare to existing (coarse grained) Linux capabilities?

Linux capabilities are not capabilities in the classical sense of unforgeable tokens of authority. They are just permissions. Linux capabilities allow a non-root process to do some things as if they were root. Capsicum implements a traditional capability model, where there is no ambient authority and a sandboxed process can not do anything unless it holds the relevant capability.

How does this compare to SELinux?

They address different goals and do so in different ways. The goal of SELinux (and the FreeBSD MAC framework's type enforcement mode) is to allow a system administrator to restrict access of a particular program or user (or program-user pair) to some subset of system resources. It is very bad for application compartmentalisation, because you can't fork() a process and have different permissions for the different children and it's difficult to update the permissions on the fly (although Apple does this with their port of the FreeBSD MAC framework, to implement sandboxing on OS X and iOS, allowing powerboxes to grant permission to specific files or directories).

Capsicum is intended for application sandboxing. It is assumed that the user trusts the binary to be non-malicious, but the program author does not trust his code to be free of exploitable bugs. A sandboxed process should call cap_enter() early on, at which point it can't create any new file descriptors. In some simple cases, that's enough. For example, a sandboxed version of man opens the file containing the mdoc sources and then calls cap_enter(). Even if it's run as root, and is reading a malicious source file that exploits the troff parser and allows arbitrary code execution, it can't do anything other than write text to the terminal. More complex applications will keep open a UNIX domain socket to a (more) privileged process that can pass in new file descriptors as they're needed, after doing some application-specific policy checking.

Does this complement things like Linux's seccomp?

Seccomp is far more restrictive than Capscium and prevents even harmless system calls (e.g. getpid(), gettimeofday() - although not on platforms where these use VDSO, I believe, but others of equal utility and harmlessness are blocked). Capsicum allows a whitelisted set of calls. Additionally, Capsicum adds finer-grained permissions on file handles (for example, you can be able to read, but not mmap, or append but not seek) and a set of at-suffixed system calls that work on directory descriptors, such as openat that allows a sandboxed process to open files in a directory that it holds the relevant capability for. This means that, for example, you can give a sandboxed browser tab process a directory descriptor to a cache directory and it can write cache data there without needing any interposition from a more privileged process. It talks directly to the kernel.

Seccomp-bpf extends seccomp by allowing system calls to be blocked or allowed based on the execution of a BPF filter. This is more expressive than Capsicum (Google's first port of Capsicum implemented it in terms of seccomp-bpf, although it was slow and not complete), but it doesn't allow the policies to easily associate permissions data with file descriptors and requires you to implement a complex BPF policy.

What's the overhead compared to the above?

There is basically no overhead for capsicum. It's one extra bitmask check on each system call that interacts with a file descriptor, which is in the noise for most workloads[1].

In terms of programmer overhead, there's a summary table for the number of lines of code changed to implement sandboxing with various mechanisms in Chrome in the original Capsicum paper. Here's the short version:

• Windows ACLs: 22,350
• Chroot: 605
• OS X Seatbelt (built atop the FreeBSD MAC frame

Re:Great approach for mitigating web-borne threats

[VortexCortex]

This sure beats my method of running browsers as another user

No, not really. It's just that modern OSs weren't designed for the damn security that hardware gives them, and they're too general purpose to utilize these hardware features properly. For instance: Instead of memory barriers and capability based security I've experimented with hypervisory mode sandboxing in some of my toy OSs. Every application thinks it in its own OS so instead of constantly verifying capabilities I can pre-allocate permitted resources and be fucking done.

I could also mention that x86 has four execution privilege ring levels, not just two for user / kernel... but pearls, swine and all that.

Re:Great approach for mitigating web-borne threats

[RightSaidFred99]

Should be great ammunition for advocating *Nix over Windows 8.

Yes, because windows doesn't have the concept of User Privileges.

They aren't as fine grained or powerful, I'll grant you, but they could easily be made to be so if Microsoft (or customers) cared enough. The problem is _they don't_ because the real-world security improvements you'll see from something like capsicum are minimal.

Re:What problem does capsicum fix?

[MouseTheLuckyDog]

My guess is that Android will be next. There are several exploits there. Also I think Linux systems are more desirable because they can be used as C&C for botnets.