New Sandbox Framework For Chromium Released 109
Trailrunner7 writes "As applications have become more and more complex in recent years and Web browsers have evolved into operating systems unto themselves, the task of securing desktop environments has become increasingly difficult. And while there's been quite a bit of innovation on Windows security, advances in Unix security have been less common of late. But now, a group of researchers from Google and the University of Cambridge in England have developed a new sandboxing framework called Capsicum, designed specifically to provide better security capabilities on Unix and Unix-derived systems (PDF). Capsicum is the work of four researchers at Cambridge and the framework extends the POSIX API and introduces a number of new Unix primitives that are meant to isolate applications and users and handle rights delegation in a better way. The research, done by Robert N.M. Watson, Ben Laurie, Kris Kennaway and Jonathan Anderson, was supported by Google, and the researchers have added some of the new Capsicum features to a version of Google's Chromium browser in order to demonstrate the functionality."
Re:Chromium Browser? (Score:3, Informative)
Chromium is the community project from which Google Chrome is derived.
Re:Chromium Browser? (Score:3, Informative)
Is this supposed to be the Google Chrome browser? Or do they mean literally a browser in their upcoming OS Chromium?
Last line of the summarized article:
he researchers have added some of the new Capsicum features to a version of Google's Chromium browser in order to demonstrate the functionality."
Third link from Google, third party description.
Chromium Web Browser [wikipedia.org]
I'm relatively new here. Is this how most people are on this site?
for fuck's sake (Score:1, Informative)
"Web browsers have evolved into operating systems"
No, they haven't, calm down.
Re:Chromium Browser? (Score:5, Informative)
Yes, it's considered SOP not to read TFA around here. The real hardcore don't even bother reading TFS either.
Re:Similarities with FreeBSD's jail... (Score:1, Informative)
At least two of the researchers are active in the FreeBSD project (Kris + Robert). Also Robert Watson's pet project has been TrustedBSD MAC extensions to FreeBSD since 5.something.
Re:Chromium Browser? (Score:4, Informative)
Academic Foolishness (Score:4, Informative)
Erm, what? (Score:5, Informative)
Chromium is the open source version that Chrome, the proprietary browser, is built on. (Basically, they take Chromium, add codecs they can't legally include in Chromium, maybe a little branding, and release it as Chrome.)
The same is true of the OS -- the only reason it's "Chromium OS" is that the actual "Chrome OS" hasn't been released yet, because the community version isn't done yet.
Re:Chromium Browser? (Score:5, Informative)
The REALLY really hardcore don't even bother reading the comment they're responding to
I like pie.
Re:Because their middle name is security (Score:3, Informative)
5 Comparison of sandboxing technologies
...
/etc and access to the terminal device. These broad policies are easier to craft than fine-grained ones, reducing the impact of the dual-coding problem, but are much less effective, allowing leakage between sandboxes and broad access to resources outside of the sandbox.
We now compare Capsicum to existing sandbox mechanisms. Chromium provides an ideal context for this comparison, as it employs six sandboxing technologies (see Figure 12). Of these, the two are DAC-based, two MAC-based and two capability-based.
5.4 SELinux
Chromium’s MAC approach on Linux uses an SELinux Type Enforcement policy [12]. SELinux can be used for very fine-grained rights assignment, but in practice, broad rights are conferred because fine-grained Type Enforcement policies are difficult to write and maintain.The requirement that an administrator be involved indefining new policy and applying new types to the filesystem is a significant inflexibility: application policies cannot adapt dynamically, as system privilege is required to reformulate policy and relabel objects.
The Fedora reference policy for Chromium creates a single SELinux dynamic domain, chrome sandbox t, which is shared by all sandboxes, risking potential interference between sandboxes. This domain is assigned broad rights, such as the ability to read all files in
In contrast, Capsicum eliminates dual-coding by combining security policy with code in the application. This approach has benefits and drawbacks: while bugs can’t arise due to potential inconsistency between policy and code, there is no longer an easily accessible specification of policy to which static analysis can be applied. This reinforces our belief that systems such as Type Enforcement and Capsicum are potentially complementary, serving differing niches in system security.
Re:Because their middle name is security (Score:4, Informative)
Normally I don't even bother to read ACs, let alone respond to them, but in your case I'll make an exception since you are actually trying to make a cogent point.
Security IS complex - that is why it is better to get it right in ONE place than getting it WRONG many places. Had the researchers put the effort into defining a meaningful set of security contexts within SELinux - contexts that could be used for the WHOLE SYSTEM - they could have not only secured the browser, but everything else. Instead, they took a Barbie-Doll "Security is HARD" approach, and only secured ONE application.
The faults raised in the paper were not with SELinux itself, but rather with a specific implementation of a security policy, created by one vendor, which USES the SELinux framework.
Personally, I'd rather see a set of security contexts and attributes:
internet_tainted_file: this object (file) was created by a program which has accessed the Internet (more precisely, any network address not marked as trusted).
sensitive-file: an object (file) that may NEVER be accessed by an internet-tainted-program (see below)
non-internet-program - a program has no need to open ports outside the local network or access internet_tainted files.
internet-program: a program which MAY access the internet, but has not yet done so.
sensitive-tainted-program: a program which has accessed a sensitive-file, and thus may NEVER access the Internet. An internet-program may transition to the sensitive-tainted-program state by accessing a sensitive-file object.
internet-tainted-program: a program which has accessed the Internet, or accessed an internet_tainted_file.
That way, programs that have no need of frobbing the Internet (e.g. gedit) CANNOT access it. Programs that have touched sensitive files (e.g. /etc/shadow) likewise can NEVER touch the 'Net. Programs that have touched the 'Net can NEVER access sensitive files.
That's just the tip of the iceberg - but getting a proper set of security contexts can not only protect the browser, but EVERY program on the system.
And that is why I raised this point: all Google is securing is their own stuff (and only to the extent a malicious exploit cannot work around their solution, which is code in the application), rather than contributing to the greater security of the whole system.
Re:Security innovation (Score:3, Informative)
1. Modify the image header. [microsoft.com] icacls notepad.exe
2. Do runas
Here's a screen capture of what happens to the latter when you try to access the user's desktop: http://i38.tinypic.com/wbs1vo.png [tinypic.com].
Re:Because their middle name is security (Score:1, Informative)
At the USENIX talk, the authors explained that one of the flaws in SELinux, not just Chromium's use of it, was the need to enumerate all sandbox domains statically in a policy file. The approach used in Chromium, and that you describe, allows different web sites to attack each other when rendered in the same browser, since they're not protected from each other. Capsicum allows applications such as Chromium to create as many sandboxes as they need dynamically. They also repeatedly said during the talk that capabilities complement, rather than replace, SELinux.