New Sandbox Framework For Chromium Released

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

Comments

Re:Chromium Browser?

[Anonymous Coward]

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

Re:Chromium Browser?

[xMilkmanDanx]

The browser. TFA states somewhat incoherently that it isolates javascript execution and if google is using javascript in their OS, their not google.

Re:Chromium Browser?

[Anonymous Coward]

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

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

Re:Kinda of misleading.

[xMilkmanDanx]

The point being sandboxed applications which deal with unknown, insecure content (i.e. the web) can keep said content from affecting anything outside the sandbox.

Re:Chromium Browser?

[Captain Splendid]

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.

Re:Chromium Browser?

[xMilkmanDanx]

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

Academic Foolishness

[Roguelazer]

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.

Re:Academic Foolishness

[Anonymous Coward]

I presume that you didn't actually read the API man pages. The interface follows squarely in the footsteps of the Unix design philosophy. No PID semantics are being changed, either. They've introduced process descriptors which, among other things, allow you to poll for process exit. They allow you to attach restrictions to descriptors, presumably so that a broker could open resources (files, sockets), restrict the allowable operations, and then pass them to sandboxed applications over a domain socket. It's all quite simple and powerful and exactly what I would love to see incorporated into POSIX.

Re:Academic Foolishness

[IamTheRealMike]

Both Android and ChromeOS are based on UNIX but neither expose POSIX as an API, so researching ways to change for the better seems like a good use of time.

Re:Chromium Browser?

[spoilsportmotors]

I'm astounded that you - or anybody else would agree with RIAA's heavy handed tactics. For shame.

Erm, what?

[SanityInAnarchy]

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?

[Tumbleweed]

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

I like pie.

Because their middle name is security

[wowbagger]

Y'know, I'm really glad Google wants to provide a new API for managing security. We need somebody to do this for us - somebody who really knows security, somebody who may as well have security as their middle name, to come out with an API framework for Mandatory Access Controls, preferably built right into th operating system kernel of a major distribution.

Yes, I'm really glad Google took the initiative on this.

Re:Because their middle name is security

[Anonymous Coward]

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.

Re:Because their middle name is security

[wowbagger]

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:for fuck's sake

[Ungrounded Lightning]

"Web browsers have evolved into operating systems"

No, they haven't, calm down.

I think he means that they have become application environments, giving access to all the fundamental services of the underlying operating systems, through their own API and security models, with their own set of bugs.

Re:Kinda of misleading.

[mewsenews]

The point being sandboxed applications which deal with unknown, insecure content (i.e. the web) can keep said content from affecting anything outside the sandbox.

Until someone comes up with a specially crafted PDF... ;)

Re:Browsers Interact Directly with Hardware?

[fluffy99]

Web browsers have evolved into operating systems unto themselves

Really? I am unaware of a (common) browser that is able to do much more than work with data...

Let's try to leave the the analogies used to educated luddites out of summaries intended for people that *KNOW* the difference between an OS and an application.

There are certainly many companies out there that want your OS to be nothing more than a web browser. That way they can sell software as a service. For things like Google Gmail, Google Calendar , Google Docs, etc. Microsoft is slowly moving in that direction as well. Its much more profitable to sell based on usage or per month, rather than selling you a perpetual license. Many businesses are moving towards the desktop being little more than a terminal with the applications actually running on a centrally manager Terminal/Application/Web server.

Re:Security innovation

[Thundersnatch]

What I'd want is a way to have more control over the program. Maybe put it in a sandbox and trick it into thinking it's got full privileges even though it's really sandboxed so it won't crash or maybe just set advanced settings for that specific application to disallow it from writing to specific registry/files/network/other process' memory.

Which is... umm... pretty much exactly what Windows Vista, Windows 7, and Windows Server 2008 can do.

Re:Security innovation

[Anonymous Coward]

He's referring to low integrity processes. 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. 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.

Re:Chromium Browser?

[SanityInAnarchy]

Microsoft's evil tends to revolve around vendor lock-in and unfairly stomping on their competitors. Google's evil revolves around Big Brother type information gathering.

Microsoft's evil also involves outright lies, and the concept of "FUD" was pretty much invented, I suspect, to describe Microsoft.

Google, by contrast... "Big Brother"? Have you read 1984? Google likes to gather information, yes -- and like Facebook and everyone else, they only gather information from people who willingly donate said information, or from information already in public spaces.

Unlike Facebook and everyone else, they have a track record of, in the very worst example I'm aware of (wireless snooping), gathering more information than people think they should -- by accident. By contrast, Facebook employees have been known to casually browse people's private information, and otherwise abuse user data.

What are you proposing? To do a binary diff between the compiled open source version and Google version? Followed by disassembling and analyzing the diff, probably without debugging symbols?

Actually, I was proposing to wait and see, or to observe the behavior of the browser itself, and then disassemble and otherwise reverse engineer the parts that look suspicious.

Firefox seems to manage.

By having, say, youtube.com/html5 not work at all. Yeah -- they "manage" by not supporting, either directly or through any sort of extension framework, the most popular video site on the planet. Surprisingly, Safari seems to be the only browser taking a sane approach -- they delegate to QuickTime, which is essentially the OS X media framework, and support any codecs they find, so there's nothing stopping users from installing theora codecs if they like.

Of course, one of the results of this is that YouTube has further incentive to continue to use Flash, because Flash works in Firefox, but HTML5 with h.264 doesn't. Which do you think is the lesser of two evils?

Perhaps Google could help by using non-patented formats on YouTube.

There are several problems with this.

First, most video is, unfortunately, shot in h.264. Since I don't particularly care about obeying software patents covering codecs and file formats, I prefer to keep media in as close to the target format as I can, and only re-encode when I have to. You can do that with YouTube -- you can upload the video that your camera encoded to h.264 (in hardware!) and it's quite possible YouTube won't re-encode it for the high quality version.

So, this not only applies to their entire library that they'd have to re-encode, it also applies to pretty much all new video.

Second, only Theora might be open. Google does have WebM, and they have (hopefully) released it, but it's too close to h.264, and still manages to be inferior in many ways. You just get worse quality for the same amount of bandwidth, and that likely means millions of dollars of bandwidth for YouTube to maintain the same quality.

I'm not saying I have a solution to this, and I certainly don't like it. But refusing to play is not a solution.

Besides, I'd prefer people actually be informed of the patent bullshit they're paying for, in one way or another.

I'd prefer people be informed, but "This doesn't work, let's go back to IE and Flash" isn't the way to inform people. Realistically, it seems like this goes only a few ways:

• HTML5 Video never takes off, partly because of Firefox.
• HTML5 Video is a hit, but Firefox users can't view it. Users switch to other browsers.
• HTML5 Video is a hit, and someone forks Firefox.

Sadly, Safari has had the way out the entire time -- delegate this stuff to the OS. Windows has DirectShow, OS X has QuickTime, Linux has GStreamer. Use those, and you get both licensing and hardware acceleration for free.

In fact, I've