In December 2010 a paper was published by Robert N.M. Watson and Jonathan Anderson from the Cambridge University and Ben Laurie and Kris Kennaway of Google about the Capsicum capabilities system [1]. It seems that the aim of the project is to allow systems that need privileges briefly when they start (such as tcpdump) a safe method of dropping privs. The main project page is here [2].
The focus of the paper is on the Chromium web browser and six different ways of constraining the Chromium sandbox are compared. For the SE Linux comparison they claim 200 lines of code changes as of Fedora 15, in Fedora 16 I couldn’t find a Chromium package, so I presume that they mean 200 lines of SE Linux policy (I am not aware of anyone modifying the Chromium source for SE Linux). They note that SE Linux doesn’t support separating different sandboxes, while it would be possible to have each sandbox be assigned a different MCS sensitivity label to separate them that option would be unwieldy enough that they are essentially correct in this regard. For SE Linux systems running the MLS policy the correct thing to do would be to run multiple copies of Chromium at different levels to access different sensitivity levels of data, this would normally be done by polyinstantiating the home directory.
One thing to note however is that there is no requirement that only one security method be implemented. I can’t think of any technical reason why it would be impossible to run SE Linux and Capsicum on the same system. SE Linux could constrain daemons and restrict the access to Capsicum services while Capsicum could be used to give minimum privileges to parts of Chromium. I’m not sure that such a combination would offer anything that the MLS users would desire, but it seems that everyone else (the vast majority of computer users) would be served well by a combination of SE Linux and Capsicum.
It’s disappointing that the paper didn’t mention Posix 1003.1e capabilities, but given the lack of use that Posix capabilities get that’s understandable.
It’s also disappointing when someone develops something new and different nowadays and doesn’t provide a virtual machine image for it. Installing and configuring something that requires application and kernel changes is a lot of work and most people who are idly curious about the technology won’t go to the effort. By today’s standards it’s not that difficult to share a 1GB filesystem image via Bittorrent.
Capability based security does not have much to do with POSIX capabilities, the former should be thought to be closer to file descriptors, which can be passed over to other processes. And while there certainly shouldn’t be any technical reason making the combination impossible (of SE Linux and a capability based system), depending on the implementation of the capability based system it might just not make much sense. On a capability based system the “policy” should already be part of the code, so applying external policy would be like trying to externally impose that a file descriptor should be read-only (because there’s no need for it to write anything to it), when if something needs fixing that’d be just the open(2) call.
Capability systems allow programs to voluntarily drop privs. A process can drop privs after it has finished it’s startup phase or before it forks a child process. The end of the startup phase can’t be known to SE Linux and SE Linux doesn’t attach any special significance to a fork(). Just from these two situations the benefits of a combination of SE Linux and capabilities seems obvious to me.
As for forcing a file descriptor to be read-only, SE Linux does support policy that specifies that a file handle can be read-only or write-only.
There can also be benefits in preventing a program from dropping privs. It’s easy to imagine a situation where restricting a SUID/SGID program could trigger a security flaw.