Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?
Unix Google Security Technology

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."
This discussion has been archived. No new comments can be posted.

New Sandbox Framework For Chromium Released

Comments Filter:
  • Re:Chromium Browser? (Score:3, Informative)

    by Anonymous Coward on Friday August 13, 2010 @03:11PM (#33245152)

    Chromium is the community project from which Google Chrome is derived.

  • Re:Chromium Browser? (Score:3, Informative)

    by Anonymous Coward on Friday August 13, 2010 @03:15PM (#33245218)

    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)

    by Anonymous Coward on Friday August 13, 2010 @03:20PM (#33245278)

    "Web browsers have evolved into operating systems"

    No, they haven't, calm down.

  • I'm relatively new here. Is this how most people are on this site?

    Yes, it's considered SOP not to read TFA around here. The real hardcore don't even bother reading TFS either.
  • by Anonymous Coward on Friday August 13, 2010 @03:24PM (#33245344)

    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)

    by xMilkmanDanx ( 866344 ) on Friday August 13, 2010 @03:26PM (#33245372) Homepage
    The REALLY really hardcore don't even bother reading the comment they're responding to
  • Academic Foolishness (Score:4, Informative)

    by Roguelazer ( 606927 ) <Roguelazer&gmail,com> on Friday August 13, 2010 @03:29PM (#33245406) Homepage Journal
    These are major and invasive changes to POSIX. No reasonable person would expect to be able to do things like change PID semantics or shared memory. Yes, it might solve the problem that they sought to solve. But I would be very surprised to see this meet with any large-scale deployment. It's better to work with the system than to just arbitrarily decide Unix is wrong and rewrite it.
  • Erm, what? (Score:5, Informative)

    by SanityInAnarchy ( 655584 ) <ninja@slaphack.com> on Friday August 13, 2010 @03:44PM (#33245614) Journal

    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)

    by Tumbleweed ( 3706 ) * on Friday August 13, 2010 @03:50PM (#33245682)

    The REALLY really hardcore don't even bother reading the comment they're responding to

    I like pie.

  • by Anonymous Coward on Friday August 13, 2010 @05:20PM (#33246682)
    I know it's /. and all, but a little effort to read the paper would be nice. Or even, a stop at pretending SELinux is the solution to everything, because that was never its aim (or achievement).

    5 Comparison of sandboxing technologies

    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 /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.

    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.

  • by wowbagger ( 69688 ) on Friday August 13, 2010 @05:57PM (#33246928) Homepage Journal

    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.

  • by Anonymous Coward on Friday August 13, 2010 @06:19PM (#33247072)
    He's referring to low integrity processes [microsoft.com]. It's only really exposed in the Windows API. But you can start a low-integrity process two ways AFAIK:

    1. Modify the image header. [microsoft.com] icacls notepad.exe /setintegritylevel low It will always start with the new privileges set from now on.

    2. Do runas /trustlevel:0x10000 notepad.exe to start it at whim with low privileges.

    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].
  • by Anonymous Coward on Saturday August 14, 2010 @11:50AM (#33251344)

    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.

"The geeks shall inherit the earth." -- Karl Lehenbauer