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!

Re:Who came up with the name Capsicum?

[Anonymous Coward]

http://en.wikipedia.org/wiki/Capsicum

Re:Who came up with the name Capsicum?

[Anonymous Coward]

The word reminds me of an oddly-named, (in my mind), quiet little village on the coast of Holland.

https://en.wikipedia.org/wiki/Castricum

Re:Who came up with the name Capsicum?

[Mister Liberty]

Dirty minds want to know?

Re:Who came up with the name Capsicum?

[Anonymous Coward]

Castricum? Is that when you can't cum because you've been castrated?

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!

[Anonymous Coward]

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.

Actually it's different than "needs root access" and "it can give up". Tcpdump needs to open a raw socket, which is a particular capability (which can be granted without root access). The capabilities are quite fine grained.

If you give tcpdump the "-w" option to save the capture to a file, it will keep the "file-write" capability (but not "file-read" or "file-seek"), but otherwise drop "file-write". If you say not to do hostname looks up ("-n"), then the "dns-lookup" capabiltiy is dropped.

When gzip was ported, most capbilities were dropped. However, if gzip found that it was being used as a pipe, then it dropped the various "file-*" caps; if it was compressing a tarball, then it needed to keep the the file-* ones afterall. This was right in the source code, so option processing could AND/&& together which caps were needed for a particular invocation.

As more programs are updated in the FreeBSD tree, more individual capabilities are added, so developers can lock down their code to only what's absolutely needed.

Re:OMG!

[MtHuurne]

Dropping privileges means that the application (or one of its sub-processes) gives up the ability to perform a certain class of operations, such as switching user ID, binding to ports below 1024 etc. This is already done in a lot of networking applications. If I understood it correctly, using capabilities means that you cannot perform an operation unless you have some kind of token (such as a file descriptor) that represents the resource and the type of access you're allowed on that resource.

So instead of dropping the privilege to write files at all, which would not be feasible in many applications, you would have a file descriptor to a directory that allows writing files under that directory. Creating new file descriptors from path strings would be blocked; the only way to get new file descriptors is from existing ones and the new descriptors will have the same or less rights than the ones they were derived from.

Re: OMG!

[Anonymous Coward]

Wrong. Use buttered bread followed by milk. Milk does very little to cure the burn.

Re:OMG!

[bzipitidoo]

Much of this sounds familiar. Fine grained rights on file handles sounds awfully like SELinux, which is itself merely an implementation of access control. Though it sounds like Capiscum has left it up to the app to decide what rights it needs, whereas SELinux maintains a big file of extended rights, basically a big extension to the old UNIX security model of "rwx" for owner, group, and world. Last time I tried SELinux, many years ago, I found I was always having to expand privileges so that utilities and apps could do their jobs. The extra system administration work that required was far too burdensome, and so SELinux went largely unused. We finally said the heck with it, and gave pretty much every permission to every program.

Maybe Capiscum is better, but it doesn't sound too secure, leaving it up to the app to police itself. We've seen how well that didn't work in places like Wall Street. Is Capiscum's real security the sandboxing?

Re:OMG!

[Anonymous Coward]

If you're not going to bother read the "tech" articles, what fucking difference does it make?

Re:OMG!

[Anonymous Coward]

Root access is more like a "privilege" than a "capability". It lets you do whatever you want in a global namespace.

There's potential for confusion here, because there are things that Linux has called "capabilities" for a long time, but they are not "capabilities" in the (even older) sense that Capsicum uses. Linux process "capabilities" like CAP_CHOWN or CAP_NET_RAW are not "capabilities" in the sense Capsicum sense. They're just basically limited subsets of root privilege.

Capsicum's use of the word originally derives from systems of the 1970s and 1980s like KeyKos.

A "capability" in the KeyKos or Capsicum sense is basically a handle that lets you talk to another part of the system, whether to read, write, or make some kind of request. If you don't have the capability for something, you can't talk to it at all, and you can't create a capability to just anything you want. In fact, you can't even ask for a capability to just anything you want; to ask, you have to have a preexisting capability to something else that can grant you what you want, and you often won't have one.

In Capsicum, capabilities are built on top of file descriptors. An open UNIX file descriptor is already basically a capability to a file. The difference is that in a regular UNIX system, every process also has an implicit "capability" to ask the file system to open more files. In a pure capability system, you only get the capabilities that something else passes to you, and only a few processes have capabilities to the global file system name space.

So tcpdump might be given an already open capability connected to a promiscuously listening raw socket. Or it might be given a capability to talk to some system service that would hand it raw sockets on demand. Yes, it could drop either of those capabilities, but that's not the main point. The main point is that it gets, say, the raw socket, without also getting the ability to modify arbitrary files, even for a moment. ... and capabilities are more than a sandboxing mechanism in the way most people would think of sandboxing. They're a whole different way of organizing the security in a system, so that every process is in a custom-built "sandbox" that only lets it do what it needs to do.

Re: OMG!

[Anonymous Coward]

Wrong. Eat ice cream. It not only cools and soothes the burn, but later when the capsicum is exiting the digestive system you'll have a light at the end of the tunnel to wish for: "I scream, you scream, Come on Ice Cream!"

Re:OMG!

[Anonymous Coward]

Capiscum is not a way for the OS to enforce security, but a way for the application to also enforce it. It's just an extra layer, meant to keep application flaws from breaking out. If you don't trust the app, then it doesn't matter.

An example of this is a web server. Say you need to load config files once when the web server is starting up. You give the web server file system access at the OS level, but then the web server loads the files then promptly drops permissions. This means the app willfully gives up permissions to better security. When an app first starts, it begins with all the permissions that the OS grants it, then the app gives up permissions as it goes along. It can also keep permissions logically separated such at code in one part of the program will not have permission to create descriptors, but it can request descriptors from another part of the code. This helps keep the more complex and less secure part of the code from directly interacting with the simpler and more secure parts.

Re:OMG!

[Darinbob]

No, you'll need to visit an actual tech oriented site in order to learn something.

Re:OMG!

[Anonymous Coward]

I've read into this before, so I assume it's still the same on Linux. Essentially, it's an API that forces a parent process to open files and resources for a restricted child to use. For example, when you type `nefarious /home/myname/mydir/myfile`, right now `nefarious` executes whatever code it pleases and could just delete your entire home directory. With Capiscum (and a shell designed to use it), `nefarious` would be given read/write control to myfile. It could delete myfile instead of indenting my lines properly, but the damage stops there.

Re:OMG!

[Anonymous Coward]

I considered programming a shell and utilities to use Capiscum, and now that it's on Linux I'm really interested. The utilities wouldn't actually work by opening a filename given on the command line like they do currently, the files would be opened by the shell and passed to the child process, who is unable to affect anything else in the system, but doesn't need to be explicitly given rights by a central ACL.

Re:OMG!

[Anonymous Coward]

Also a note about "policing itself"; when you want to run a program in a POSIX system, you fork(3) your process, set up the process with YOUR OWN CODE (right now, often redirecting the standard streams), and then replace the executable image with exec(3), which leaves the same kernelspace information that you so carefully set up to the new process. Policing itself happens in the time between fork(3) and exec(3).

Re:OMG!

[Anonymous Coward]

Politics of the DoD: 259 comments

Actual tech article: 42 comments

Re:OMG!

[EvanED]

Well, it's still dropping features in Capsicum, at least AFAIK. (I have a friend who's doing his PhD dissertation on something related to Capsicum-like systems.)

Capsicum just allows you to drop the ability to drop operations at a finer granularity than would otherwise be possible.

Re:OMG!

[EvanED]

That's actually a really neat idea.

Re:OMG!

[MtHuurne]

What I understood from the presentation is that in Capsicum your process starts to run with traditional access control. You acquire the capabilities you'll need and then you switch into a different mode in which resources can only be accessed using capabilities. In other words, you drop all possible operations at once, not a selected subset. Except when using capabilities you acquired in advance or were given by a different (sub-)process, you can do nothing at all with resources.

The word "capability" is a bit counter-intuitive here. As the AC below says, think of it as a handle, not a privilege.

Re:OMG!

[EvanED]

I still say that it has to do with what level you want to think of it. If you look at the mechanism by which a policy is achieved, yes, a capability-based system is quite different from the typical Unix model.

But in both cases, you have a program that's saying "if I get told to do something I shouldn't (e.g. by being compromised), I want to make sure I can't do something -- I know, I'll stop my future self from doing it by removing the ability." In the traditional Unix model you do that by changing users, in a more modern *nix you do it by telling the OS to remove not-really-capability privileges, and a Capsicum program would do it by telling the OS to release the actual capabilities it has*. All three are trying to accomplish the same goal, just via different means (and with different amounts of success).

(And since others have mentioned SELinux, SELinux is like someone else saying "hey buster, I'm not going to let you do this thing that you're not supposed to be able to do." Dropping privileges is self-policing your behavior because you trust yourself to try to be good but don't trust yourself to be perfect. SELinux is policing others because you don't trust one or the other. This analogy isn't perfect, but they are pretty different.)

I think both explanations add to the discussion.

* Under Capsicum you can also "drop privileges" by switching into Capsicum mode, as you mention.

Re:OMG!

[Anonymous Coward]

It is the essence of the heat from a red pepper.

Re:OMG!

[Anonymous Coward]

Its a capability system. Its a security system that is based on roles and permissions go with roles rather than with people. So you have a roll (say mail administrator), and the roll 'mail administrator' has permissions 'administration of email programs and data'. The roll 'mail administrator' can accept a user as mail administrator, and only that person inherits the permissions to the programs and files to administer mail. A capability based system is quite different than the traditional posix user/group/all permissions (rwxrwxrwx), and the ACL (access control list) based security systems.

Re:OMG!

[MtHuurne]

One difference is that if you drop privileges, you cannot regain them, while capabilities can be passed from one process to another. For example, if a web site asks for access to your web cam, it would be good if the user can allow or deny that on a case-by-case basis. With capabilities, the capability to access the web cam can be transferred to the tab sandbox that asked for it. With privilege separation, you'd either have to give all sandboxes the ability to access the web cam, thus risking exploited tabs accessing it, or deny all sandboxes access and build some kind of inter-process mechanism for web cam access, which is a lot of work and (if it contains bugs) could provide a way for code to escape from the sandbox.

But even if you only look at scenarios with static policies, I think enumerating allowed actions is different from setting rules. If you'd model "things your process can do" as integers, you'd have a set of integers describing what your process is allowed to do. Dropping privileges is like saying "remove all even numbers from the set" followed by "remove all prime numbers from the set", while using capabilities is like saying "the new set is { 5, 42, 83 }".

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.

Re:OMG!

[Warbothong]

So instead of dropping the privilege to write files at all, which would not be feasible in many applications, you would have a file descriptor to a directory that allows writing files under that directory.

That's an interesting choice of example, since I've often seen the *opposite* used to demonstrate capability systems; specifically that we can keep a filesystem capability in our shell and do everything else with stdio and pipes. For example, rather than giving a filesystem capability to "cp", we can get rid of "cp" altogether and use "cat file2". Since "cat" is only operating on stdio, we don't need to give it any filesystem capability.

Re: OMG!

[Anonymous Coward]

Capability access control systems are not role based access control systems.

They work by passing unforgeable tokens that represent a resource or action. If you don't have a token you can't do anything.

This has no direct relationship with user identity or roles, although conceivably you could manage an initial assignment of tokens like this.

Re: OMG!

[Anonymous Coward]

Capability access control systems are not role based access control systems.

They work by passing unforgeable tokens that represent an action of some sort. If you don't have a token you can't do anything.

This has no direct relationship with user identity or roles, although conceivably you could manage an initial assignment of tokens to a process like this.

An application could pass the tokens on to other processes or discard them entirely. It's the difference between being given keys to a door vs. A bouncer checking if your name is on the list.

Re:OMG!

[Anonymous Coward]

You've got the idea wrong. It's not the application that polices itself, it's the application's parent. The idea of a capability system is that you turn the ACL system upside down. Instead of a huge map of rightsapplications that you set and hope that all instances of the application have the same purpose you instead assign rights to an instance of a process. Usually these are very fine grained like SELinux but the interface for assigning them is different. Think of the iOS prompts "Do you want to allow this application access to your contacts/location/messages". You assign the process permission to do these things and, optionally record them as the default capabilities for that application. Thus the usual behaviour for a capability system is to learn what privileges are appropriate for each application by user interaction. One special feature a capability system offers is total protection of files from rogue processes. A process can only see those few files it has been given permission to access (The open file dialog does not belong to the process but is instead a separate trusted process that simply passes a user chosen file handle to the requesting process.

In common situations an application will delegate to another process which, in the default POSIX security model would inherit the parent's permissions. In SELinux this fork is unconstrained but execve will get a new set of permissions deemed appropriate to the new process, possibly derived from the original. In a capability system the parent typically follows the model of fork-retains-permissions but before calling exec or simply starting a new piece of work it drops permissions so the new process can't access any resources except those assigned to it.

Basically a capability system attempt to closely follow the principle of least privilege at all times. A process can only drop permissions by itself and can only gain them by explicit user action. Permissions are fine grained, a process will be granted access to a single file not a user's whole home directory. Permissions like network access can be granted by a user but an ACL system may prevent the user from doing so.

Re: OMG!

[Anonymous Coward]

And there are already kernel capability flags for processes which can be manipulated with libcap and can be dropped. For example, there is a cap to allow binding to low ports. Applications can have the exe marked under Linux with this cap, and after startup and binding to the low port, the cap can be removed.

I'm not sure what's so new here. It looks like reinvention from the outset.

That said, libcap is poorly documented and not that easy to use, so maybe it should be replaced.

This sounds so...

[Anonymous Coward]

SPICY!!!@!

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?

[Anonymous Coward]

Ever heard of a "bell pepper"?

Yeesh, Americans are as ignorant as a pile of bricks.

Re:Capsi . . . what?

[Anonymous Coward]

Uh, its the genus name of most peppers? You must have heard of chili or jalapeno peppers, right? They're all capsicum. Also, the chemical that makes all peppers hot is called capsaicin.

Re:Capsi . . . what?

[Anonymous Coward]

I'm American and knew the word, but seriously, why would you expect any layman, regardless of nationality, to recognize the name of a plant genus?
How many fruit and vegetable scientific names should a non-scientist know?

Re:Capsi . . . what?

[Anonymous Coward]

Or you could have visited the site for the project and their icon would have clarified the meaning of the word.

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.

Re:Capsi . . . what?

[Anonymous Coward]

I think Americans call them Bell Peppers. Hollow fleshy fruit filled with seeds, related to the Chili.

Great approach for mitigating web-borne threats

[Khopesh]

Google is funding this (both the direct research on FreeBSD and the port to the Linux kernel) because it addresses an aspect one level above the browser. Google Chrome would then be quite tightly sandboxed. This sure beats my method of running browsers as another user (I symlink ~/Downloads to my web user's version of that area and move things out of it quickly), especially since my method wouldn't do anything against actual privilege escalation (to root).

This should also help fight web server exploits (among other malware), especially w.r.t. installing rootkits. Should be great ammunition for advocating *Nix over Windows 8.

I'm excited, but I can wait for it to hit Linux (probably; FreeBSD will release with it by default in few weeks).

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

[Anonymous Coward]

Hardware security is very coarse grained and can't understand OS level API security.

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:Great approach for mitigating web-borne threats

[MouseTheLuckyDog]

Does Google control the patents for this? If so then MS and Apple will shit themselves silly.

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

[Anonymous Coward]

It sounds similar to SecComp, but Capsicum allows different parts of the application to have different capabilities, instead of doing it application wide. It's more flexible.

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

policy updates have fixed SELinux

[raymorris]

> Last time I tried SELinux, many years ago, I found I was always having to expand privileges so that utilities and apps could do their jobs.
> We finally said the heck with it, and gave pretty much every permission to every program.

Other people had the same problem and reported exactly what the log said, so the distro default policies have been updated. That pretty much solved the problem, so SELinux is ready for you to give it another try.

Also, there exist "targeted" policies which restrict only the most likely vectors, such as PHP. With targeted policy, it's like PHP is running under SELinux but Gimp is not.

ps Capsicum prevents the app from being exploited

[raymorris]

> but it doesn't sound too secure, leaving it up to the app to police itself.
> We've seen how well that didn't work in places like Wall Street. Is Capiscum's real security the sandboxing?

As a simple example, many web server exploits write files to /var/tmp and then to /sbin. It's not that Apache or Nginx is malicious, Apache is being tricked into writing those files. With Capsicum, Apache would, on start-up, declare to the OS "don't let me write any files outside of cgi-data/."

Re:ps Capsicum prevents the app from being exploit

[angst_ridden_hipster]

cgi-data?

Is this a time-traveling web server from the 90s?

Snark aside, it's also advantageous to prevent Apache/nginx/whatever from being able to run/interpret/process PHP/Perl/Python code outside of a carefully restricted set.

What problem does capsicum fix?

[manu0601]

Improved security models like SE Linux or now capsicum are intellectually interesting, but do they solve a real problem?

After all there are really few working exploits in the wild against up to date Linux systems, and a non up- to date system will be hacked anyway, with or without fancy security models.

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.

Re:What problem does capsicum fix?

[aiht]

Improved security models like SE Linux or now capsicum are intellectually interesting, but do they solve a real problem?

After all there are really few working exploits in the wild against up to date Linux systems, and a non up- to date system will be hacked anyway, with or without fancy security models.

Isn't the whole point of dropping privileges (whether using something fancy like Capsicum, or simply switching to a non-root user after initialisation) to mitigate what happens after a process gets successfully attacked?
Whether a zero-day vuln or an old vuln that hasn't been patched, if the attacker can't do anything important once they get in, doesn't that help?

Re:What problem does capsicum fix?

[Anonymous Coward]

Basically, yes. The point is that, even though most programs have bugs and some bugs can be exploited, if you can't do so much as read a file then you can't do any damage. The Chrome example basically prevents a browser tab from reading any file outside of the cache and if the renderer is fully separated then no files at all. If the renderer is a separate process from the rest of the browser it can have all meaningful privileges stripped from it so all it can do is write pixels to a window. That way the worst that can happen is the renderer crashes and gets respawned. The point is that while it's nearly impossible to write perfect software so you interpose a system that prevents bugs from doing significant harm.

Think of a user with an empty home directory in a chroot jail with a nothing more than a single Unix socket to communicate with the rest of the system. Now disable 80% of the common syscalls. There's no way this user can root your system or take your files hostage unless there's a bug in the cut-down kernel API provided that lets them.

Re:What problem does capsicum fix?

[wagnerrp]

No software programmer is perfect. There will always be exploits, and those exploits often show up in use in the wild before they are patched out by the responsible party. The difference with Capsicum is that it shifts the load from the system administrator to the programmer. The administrator trusts that the programmer knows the limited set of privileges that their application needs, and drops all else. It's mitigating the harm that can be caused by an unpatched exploit, and doing it in a fashion that requires no effort on the part of the administrator, thus making it far more likely to happen in the case where the administrator is a common user.

Wrong Approach

[Anonymous Coward]

To tackle the Cyber Warfare thing, we should go for Memory Safe Languages:

http://en.wikipedia.org/wiki/Memory_safety

http://en.wikipedia.org/wiki/Type_safety

Some processes are gatekeepers of data, e.g. the X11 server. An attacker capable of subverting the X11 server can access essentially all data of the user, as all data is displayed via the X11 screen. That means process-level security is not really that much useful.

Re:Wrong Approach

[Anonymous Coward]

Many programs need the speed of C. The real question is how to bring a lot of these "Memory Safety" style ideas to C. Most applications only have a few hot paths. I could be happy with an extension to C that allows both "Memory Safe" and "raw" programming. Then I could switch back and forth as needed.

Re: Answered Capsicum questions

[Sits]

Hey TR, thanks for the comprehensive replies (to be honest I thought I'd asked so late no one would see them) - you elaborated on things that I did not glean from the presentation. Well done for splitting secomp and secomp-bpf up too. I have a few more questions:

• Does Capsicum only work at the process level? I can't have a more privileged thread that is still uncontained (i.e. still able to perform a blocked syscall) while other threads are contained?
• How do you envision codebases supporting Capsicum in a way that they leaves them still portable to platforms where Capsicum is not available? Is it going to be a case of #ifdefs all the way down?
• Would it be possible to make a sandbox program that uses Capsicum to in turn sandbox another (Capsicum-unaware) program that it goes on to run or is it likely going to be too restrictive for the second program?

Re: Answered Capsicum questions

[TheRaven64]

Does Capsicum only work at the process level? I can't have a more privileged thread that is still uncontained (i.e. still able to perform a blocked syscall) while other threads are contained?

Yes. There's no point sandboxing a thread, because if you compromise one thread you can write over every other thread's memory, and trivially do ROP tricks to make another thread make the system calls on your behalf.

How do you envision codebases supporting Capsicum in a way that they leaves them still portable to platforms where Capsicum is not available? Is it going to be a case of #ifdefs all the way down?

The Capsicum APIs can mostly be #ifdef'd away. The things that restrict rights on a file descriptor and the cap_enter() syscall can just be turned into no-ops.

Would it be possible to make a sandbox program that uses Capsicum to in turn sandbox another (Capsicum-unaware) program that it goes on to run or is it likely going to be too restrictive for the second program?

I don't think I understand this question.

Re: Answered Capsicum questions

[Sits]

The last question was basically "Can I use Capsicum to create a program that in turn isolates other arbitrary programs in a meaningful way (e.g. in the style of sandboxie)"?

Re: Answered Capsicum questions

[TheRaven64]

You can't easily use it to isolate other unmodified programs. However, it is possible to use LD_PRELOAD to insert a shim libc that will trap any attempts to open files and will instead ask the parent process to pass it a file descriptor. That becomes a bit tricky because rtld also wants to open files (although it's now been modified to allow you to pass in some directory descriptors for search paths) and it must (obviously) run before any shared library code can run.

It's probably more interesting to integrate this kind of sandboxing directly with rtld, so that it can drop privileges and inject the shims itself.