Slashdot Mirror
Cambridge's Capsicum Framework Promises Efficient Security For UNIX/ChromeOS
An anonymous reader writes "Communications of the ACM is carrying two articles promoting the Capsicum security model developed by Robert Watson (FreeBSD — Cambridge) and Ben Laurie (Apache/OpenSSL, ChromeOS — Google) for thin-client operating systems such as ChromeOS. They demonstrate how Chrome web browser sandboxing using Capsicum is not only stronger, but also requires only 100 lines of code, vs 22,000 lines of code on Windows! FreeBSD 9.0 shipped with experimental Capsicum support, OpenBSD has patches, and Google has developed a Linux prototype." While the ACM's stories are both paywalled, the Capsicum project itself has quite a bit of information online in the form of various papers and a video, as well as links to (BSD-licensed) code and to various subprojects.
So, we have our first solid metric: it's 220 times as hard to make Windows secure as it is for BSD or Linux.
(Xtifr runs and hides before the angry crowd of humorless astroturfers with mod points arrives.) :)
Did you know that you're incorrect? Capsicum is the genus of the plants, capsaicin is the chemical.
make imaginary.friends COUNT=100 VISIBLE=false
And he also doesn't know chilly != chili and papers != peppers.
What one fool can do, another can. (Ancient Simian Proverb)
The paper goes to great length to point out that applications can only be as secure as the operating system lets them. In section 5 of the A Taste of Capsicum: Practical Capabilities for UNIX paper the authors talk about how Chrome has been secured in all the major operating systems. They succulently sum up the great lengths Google has gone to, to make Chrome secure. Then promptly shoot holes in each of the approach's. Windows gets the worst treatment (lack of capabilities), followed by Linux (complicated approach's.) The authors give the best marks to FreeBSD and then to the Mac OS X MAC implementation.
The point I took away from the paper was, who ever has the most complete and easiest to implement sandbox (MAC, DAC) implementation to take advantage of can have the most secure applications. But at the end of the day its still up to the developer to take advantage of those capabilities.
It may sound that way, but it doesn't read that way. Perhaps if you stopped listening to articles and read the written words you'd know what they were about.
Specifically, Capsicum is a Unix (and therefore heavily C- and process-based) framework for sandboxing applications. Android applications, on the other hand, are written in Java and executed on the Dalvik VM. The "process" model is completely different from that of Unix. C applications and modules in Android can only use and link against the NDK, which doesn't expose any operating system interfaces at all. So, again, Capsicum is useless.
Capsicum also debuted, like, years ago. I doubt it will pick up steam because the necessary underpinnings will never be adopted in the Linux kernel. For one thing, anything which comes from FreeBSD always has to be re-engineered, and usually poorly. It hardly matters that the Capsicum researchers chose FreeBSD as their test bed for probably arbitrary reasons. What matters is that FreeBSD has now infected it.
Second, there are two interest groups in the Linux community that dictate security frameworks: the SELinux people and the anti-SELinux people. The anti-SELinux folk are already wedded to a host of alternatives. Capsicum will have a cold reception.
Here you go:
The Benets of Capability-based Protection
http://i.minus.com/1330308329/L4NpiCEFGVpDC5cIaD-oaA/dIgD7OB2SWXbD.pdf
A Taste of Capsicum: Practical Capabilities for UNIX
http://i.minus.com/1330308331/bOoWdETijD2_Eye5VsAKPQ/dvW7Ri9ZpoDDi.pdf
-- Not Aaron Swartz
Capsicum also debuted, like, years ago.
And appears to be stale:
The website hasn't been updated since 2010.
The latest GitHub code is from 2010.
The "Documentation and Publications" are from 2009 and 2010
What one fool can do, another can. (Ancient Simian Proverb)
Finally? Multics and others had such features before the birth on Unix.
Ecclesiastes 1:10 Is there anything of which one can say, "Look! This is something new"? It was here already, long ago; it was here before our time.
I prefer the original Hebrew
For one thing, anything which comes from FreeBSD always has to be re-engineered, and usually poorly. It hardly matters that the Capsicum researchers chose FreeBSD as their test bed for probably arbitrary reasons. What matters is that FreeBSD has now infected it.
God forbid they release and modify truly free code that can be taken and be further modified, then sold without risk of litigation from the original author* If anything, unless I missed the sarcasm, I think it was wise to not infect the project with GPL or taint it early by trying to make it compatible with everything maintained seperately rather then a single released package that is FreeBSD. The poor re-engineering is what makes L \edd\eiWere you trying to be flamebait there?!
120 characters ought to be enough for anyone
On windows, notepad can save a file as foo.exe, and you have an executable.
That's a rather bad example. Go ahead, open some executable file in notepad and save it, then try to run it, what do you get? Yes, that's right, it's totally corrupt. I do actually get your point, but notepad cannot do what you claim.
Very few programs actually need the capability to generate executables (the compiler, and the application installer, for instance). Allowing any and all programs to make executables along with regular file access means that any executable can be compromised into dropping malware onto your system.
How would the system know what the application is writing to a file unless it first allows the application to write to said file? Executables are not some sort of magic thingies, they're just binary data, and if you allow an application to write binary data then you are also allowing that application to write out executable code. There is no way for the operating system to know every possible type of binary file and that's that, what you suggest isn't possible. If you only mean that applications shouldn't be allowed to name their files "*.exe" then yes, that would certainly be possible, but that wouldn't solve the problem. Especially on non-Windows platforms where filename doesn't determine whether or not a file is executable.
This means, for example, that a program run by an administrator can write files virtually anywhere.
Well, indeed, that is the whole reason why administrator accounts exist: they're there so that administrators can do whatever they want!
To install an application means that you must trust the installation program because it can put anything anywhere.
A capability model could restrict a program to its install directory (c:\Program files\) and forbid access to system directories. This would prevent malware from being installed alongside good programs, and removing malware would be much easier (just delete the application install directory).
The real issue isn't where malware can install itself in, the real issue is what files it can read; OS can always be reinstalled should things go totally haywire, but user's personal files cannot. And yes, granular access control -- both reads and writes, like e.g. applications shouldn't just be able to even get a directory listing on the user's files unless the user specifically allows for that -- should be an integral part of any modern OS, too bad it isn't. It isn't a new idea, though, I've seen such mentioned already a decade ago and I'm sure such an idea has existed even longer, I just haven't been aware of it.
It sounds like we've finally come up with modern security models. This should make everyone safer, and perhaps completely eliminate malware.
Not even by a long shot.
Capsicum is a lightweight framework which extends a POSIX UNIX kernel to support new security capabilities and adds a userland sandbox API. It was originally developed as a collaboration between the University of Cambridge Computer Laboratory and Google, sponsored by a grant from Google, with FreeBSD as the prototype platform and Chromium as the prototype application. FreeBSD 9.0 provides kernel support as an experimental feature for researchers and early adopters. Application support will follow in a later FreeBSD release and there are plans to provide some initial Capsicum-protected applications in FreeBSD 9.1.
Traditional access control frameworks are designed to protect users from each other through the use of permissions and mandatory access control policies. However, they cannot protect the user when an application, such as a web browser, processes many potentially malicious inputs, such as HTML, scripting languages, and untrusted images. Capsicum provides application developers fine-grained control over files and network sockets to provide privilege separation within an application, with minimal code changes. In other words, it provides application compartmentalisation, allowing the application itself to provide many different sandboxes to contain its various elements. As an example, each tab in the Chromium browser has its own sandbox; it is also possible to contain each image in its own sandbox. Creating sandboxes under Capsicum does not require privilege, a key problem with current UNIX sandbox approaches.
As an example, the insecure tcpdump application can be sandboxed with Capsicum in about 10 lines of code and the Chromium web browser can be sandboxed in about 100 lines of code. capsicum(4) provides an overview of the available system calls. More information, including links to technical publications, projects, and a mailing list, can be found at the Capsicum website.
The Java equivalent of Capsicum is Joe-E: http://code.google.com/p/joe-e/
How does something like this get modded up? OP know exactly two things here, jack and shit.
First, any trivial amount of searching would reveal that Robert Watson, author of Capsicum, is pretty much the FreeBSD project lead, and has been for a very long time. His reasons weren't arbitrary, this is a technology deliberately designed for FreeBSD. This is also not the same as SELinux. Robert Watson already wrote that 10 years ago when he worked on TrustedBSD. This is application level sandboxing, not system level MAC.
And yes, Capsicum was started "years ago." From concept to delivery, stuff like this takes time. It's finally seeing light officially for-the-rest-of-us in FreeBSD 9 which was released last month.
Finally, how will Linux people adopt it? FreeBSD people don't care. That's the beauty of being not-Linux.
Disclaimer: I am a FreeBSD developer, and was visiting cl.cam.uk last week.
Capsicum is very much under active development. It's being used in Cambridge in several projects, funded by DARPA and Google. It is no longer developed on github because it is now merged upstream into FreeBSD. As TFS said, it is part of FreeBSD 9, and the core FreeBSD utilities are slowly being modified to use it (it's easy to incrementally deploy capsicum). If you want up to date documentation, check the man pages.
I am TheRaven on Soylent News
In UNIX, everything that interacts with anything outside of the process goes via file descriptors. Capsicum provides special file descriptors with capabilities. When you enter capability mode, the kernel no longer allows you to create new arbitrary file descriptors. This means you can't create new sockets, you can't touch the filesystem, and you can't touch any devices. You are completely isolated unless some other process passes you a file descriptor or you create one via a set of special rights. For example, if you have the correct permission, you can use open_at() to create a new file in a directory for which you have a descriptor. This allows you to, for example, set up a sandbox where an application can store files in a per-application location and can use a temporary directory. If it wants to open a socket, it has to ask another process. If it wants to open other files, it has to ask another process. The typical way of handling the second is to have a file-chooser application that allows the user to select files and then passes the rights to access them into the sandbox.
I am TheRaven on Soylent News
The point is that if you are programming in java, you can offer arbitrary security models to applications running inside the VM, without the need for any special operating system support
This is true if and only if your JVM is 100% bug free. Do a CVE search for JVM, Flash, or JavaScript to see how likely that is. With Capsicum, the JVM can restrict itself to the capabilities that the Java code should have, so even if the VM itself is compromised, the Java code can't escape from the sandbox.
I am TheRaven on Soylent News