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.) :)
This sounds like something that could be useful for Android apps.
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.
What is this like some kind of AA for nerds? Alcoholics Anonymous Cowards? The first step is admitting you have a problem... on Slashdot!
...in Scoville Units ? http://en.wikipedia.org/wiki/Scoville_scale
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
No it's not a bullshit metric. Minimizing the amount of work the applications has to do in order to use the feature means less code that those applications coders can fuck up while the larger number of lines of code that is "under the hood" is shared so more work can be put into it in order to make it secure.
As far as I know, Capsicum has mostly run its course and been superseded by other umbrellas, particularly CTSRD. The page for the latter even refers to the former as a 'success project'.
It seems to me that a capability model is the right solution.
Current OS access methods are woefully primitive and difficult to manage. To take two examples:
1) If you can write a file, you can make an executable
On windows, notepad can save a file as foo.exe, and you have an executable. On linux it's different but just as simple.
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.
Consider, for example, malware being sent around in pdf files or possibly image (ie - jpg) files.
A better model grants "can write executables" as a capability that is granted only to the programs that actually need it.
2) If an application can write a file, it can write a file anywhere any *other* application can write a file.
On windows and linux, file access is inherited from the user. This means, for example, that a program run by an administrator can write files virtually anywhere. 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).
It sounds like we've finally come up with modern security models. This should make everyone safer, and perhaps completely eliminate malware.
i think it's supposed to be ironic. the reader's relief that it's not about anal rape and/or eating feces, like most copy-paste jobs, plays into the light-heartedness of the self-destruction.
"They were pure niggers." – Noam Chomsky
I wouldn't call ChromeOS as Thinclient OS as the same Linux operating system there is running as all popular Linux distributions and what is available for everyone from kernel.org.
Even that ChromeOS only offers to user a web browser (simplifying), it does not mean the operating system is for thinclients.
And even that web browser loads all "web apps" from network, it does not mean system is thinclient. Or otherwise I am typing this on thinclient what is really thin, as it is just 3.5cm thin and weights under 1Kg.
Android applications get almost no shielding from the OS and filesystem. security separation is based on UID and file system permissions. Since most apps are seriously lacking in file system permissions (app developers just turn on permissions for everyone, so their app works) and things like immutable files and ACLs aren't used, in practice Android is about as safe as an unpatched Windows ME machine directly connected to the Internet (slightly exaggerated for theatrical purposes). I wouldn't trust my company or private data to Android without some serious frameworks in place, that aren't there now.
I was promised a flying car. Where is my flying car?
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.
Did you know its kind of pointless as ChromeOS is a giant fail?
Did you know that ChromeOS (a Linux-based OS) is completely irrelevant in an article about a FreeBSD feature that is now used in Chromium (a web browser)? The only vague relevance is that one of the people mentioned in TFS works on both the Chrome / Chromium and ChromeOS projects. But don't let that get in the way of a good anti-Google rant.
I am TheRaven on Soylent News
Actually I was originally FOR ChromeOS as i thought it was a brilliant idea for clueless home users. An OS that will protect them by basically running everything on the server and thus get rid of local exploits. As for Chrome, why should we care exactly? Unless you are running XP (or Linux) you have low rights mode which by default has lower permissions than users which makes it pretty damned hard to infect a machine anyway. i know as i tried to infect a machine that I planeed to wipe anyway and went to every topsite and crapsite i could find and...nothing, zip nada squat.
So its a thing for software that doesn't need it except for old OSes or niche OSes...wow, great, thanks.
ACs don't waste your time replying, your posts are never seen by me.
Success Kid EPIC FAIL !
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
did you know, considering i defined the meme / phrasing for the entire thread, I deserve to be modded up!
Finally sadly security can't be solved by tech, well not unless you can cook up something that shocks the shit out of the user and says "WTF are you doing? Stop that!"
I'm responding not to give you personally a hard time but because you've expressed a common misperception that seems peculiar to the personal computer generation.
Certainly security can be solved by tech, for many important classes of security and with many types of technology. What's a bank vault, for example?
In terms of information security, there are again many important classes of security that have been effectively realized. Those of us who grew up with mainframe architectures understand this from firsthand experience. If your only access to a system is through a particular application, your attack surface is limited to the functionality and privileges of that application. The choice of technology can indeed make this system secure. Electric shocks are not required.
Now consider distributed applications. For example, there is a server somewhere waiting for network connections from clients. With respect to the server, your attack surface is again limited to the functionality and privileges of the application, in this case the network service. With reasonable effort, technology can secure this server. The network protocol presents a different target and likewise a different attack surface. If we want to secure the protocol then we have to be concerned with how to reliably identify clients, mitigate denial of service attacks, preserve confidentiality of data in transit, and so on. This is harder than the mainframe problem but, given reasonable criteria, can also be solved technologically.
When we turn to something like a personal computer, a completely different situation prevails. It's easy, almost trivial, to build a fully-functioning personal computer from off-the-shelf components. There is nothing to stop you from building an arbitrarily insecure system. Without exception, all credible DRM schemes are based on functionality baked into one or more of these components, such that you can't build a working system without them. (I'm not an advocate of DRM, just saying that this is the only indefeasible way to implement it.)
See, it all depends on who owns the system. You can't generalize the particular circumstances of personal computer ownership to computing in general, let alone to technology as a whole.
Parity: What to do when the weekend comes.