Introducing Chrome's Next Generation Sandbox

http://blog.cr0.org/2012/09/introducing-chromes-next-generation.html

A nice writeup about the seccomp based sandboxes.

Just as an FYI you can use both sandboxes as once. This isn't necessarily the smart move though.

 

When I saw the title I thought it was a new sandbox to "compete" with IE10's new Enhanced Protected Mode, but in reality it's "Chrome's New Linux Sandbox", not "Chrome's Next Generation Sandbox". But I guess it's great for those that use Chrome on Linux.

 

Has there been any comparison between the Chrome sandbox and IE10 sandbox? A whitepaper or anything like that? I'd be interested. The IE9 sandbox was clearly lacking by comparison.

I would call this a 'next generation' or 'new' sandbox, whichever. It's not the typical sandbox that restricts file access like Windows MIAC or Apparmor. It's meant to compliment that.

It definitely is great though.

 

I have both the legacy and the BPF sandbox enabled, but I have the feeling that the legacy sandbox is really not needed.
What would be the drawbacks or advantages in having them both enabled ? (In laymans terms please Hungry, if you have some spare time).

 

yes there is thread how to enable it

https://www.wilderssecurity.com/showthread.php?t=333447

i also put a second layer of apparmor

the only problem i am facing no chrome running under second user

 

I don't think the "legacy" sandbox is needed if you have the BPF sandbox enabled. They both do the same thing, the only difference is the BPF sandbox is sort of the newer generation (using BPF filtering).

 

They're pretty different actually. The legacy sandbox only whitelists 4 system calls and uses a trusted thread to make other calls.

The BPF sandbox (based on seccomp mode 2 filters) whitelists numerous calls and removes the need for the trusted thread (sort of, there are third party library issues potentially and in the future we may see that model back).

Regardless the legacy sandbox is removed from Chrome 24.

 

Thanks for that info. I am only running BPF now, sounds like it is more efficient with less 'overhead'.

 

Exactly.

The way it worked before included splitting the renderer process threads into trusted and untrusted. The untrusted threads were only able to use read(), write(), exit(), and sigreturn(). Anything else led to the process being killed. All other calls were offloaded to the trusted threat.

There's some overhead here because they have to communicate multiple times. There's more to it because to remain trusted it has to store values on registers and constantly pop them off.

The two actually work fine together, they're completely compatible. But there's no need for the first if you've got the BPF filters.

If you combine the two you end up with (for simplicity's sake) two threads for the renderer process, one trusted and one untrusted. The untrusted can only make 4 syscalls and the trusted shouldn't be able to make mroe than what's whitelisted.

At least conceptually taht's hwo it should work. The issue is, as you said, overhead.