730956 - Sandbox both content and chrome

Status: RESOLVED WONTFIX

(Core :: Security: Process Sandboxing, defect)

Description

[Brian Hackett [Laid off!]]

From my understanding, the security argument for process isolation between chrome and content is that the content processes can run with lower privileges and marshal all their disk access and other I/O through the chrome process, which runs at full privileges and can watch for bad behavior.

After working on bug 718121 some it seems like it would be a gigantic PITA to cleanly separate chrome from content, especially given that our chrome JS and any addon can freely manipulate structures stored either in chrome or content.  More importantly, making this separation doesn't seem necessary in order to actually sandbox content activity.  Instead, we could sandbox content *and* chrome, by running two processes:

1) A shim process which has full privileges, manages I/O and does nothing else.
2) A main process which runs all chrome and content, is locked down and does all its I/O via the shim process.

"I/O" here is vague, but would include all disk access for sure, probably all or most device accesses and possibly some network access, depending on host architecture.

The shim proxy can implement whatever security policy it wants, to provide fine grained control over what exactly the browser is allowed to do --- e.g. it is OK to access profile and temp directories, but not OK to screw with random registry settings or install startup exes in random places.  With a suitable security policy, an attacker who infects only the main process should not be able to infect the host machine.  Since the shim process does little work and has a small code footprint, it should be very difficult itself to infect.

Comment 1

[Alon Zakai (:azakai)]

Maybe we can take advantage of existing OS features to do this for us, Linux for example has SELinux and AppArmor, which in order to use all we need is to define a policy file (assuming the SELinux/AppArmor service is enabled in the OS), we wouldn't need to modify the browser at all, nor need to write a shim process.

If we do need a shim process, it seems like it might need similar techniques as are used in virtualization, apparently they can take advantage of specific CPU features for that and run will little or no overhead. I think there is at least one open source cross-platform virtualization project, might be worth checking out.

Comment 2

[Brian Hackett [Laid off!]]

Do you know if a comparable solution exists for Windows?  That is really the platform of concern here.  I don't know why virtualization techniques would be necessary, we're free to modify the sandboxed process to just talk to the shim via IPC.  And that should only happen when the browser is doing file I/O.

I've poked around a bit more since posting this bug, and near as I can tell the design in comment 0 is very similar to that used by the chrome sandbox (http://www.chromium.org/developers/design-documents/sandbox).  In that case I'd rather just use that sandbox (which I believe is BSD licensed) rather than reinvent anything.  My concern is whether I'm missing something here, because it seems like this is something that should have been done years ago.

Comment 3

[Luke Wagner [:luke]]

Wow, I had never dug into Chrome's sandbox measures; very impressive.

Comment 4

[Alon Zakai (:azakai)]

(In reply to Brian Hackett (:bhackett) from comment #2)
> Do you know if a comparable solution exists for Windows?  That is really the
> platform of concern here.

Windows Vista+ has something similar, that IE and Chrome use to sandbox. The page you linked to mentions it, "integrity levels" - I think I heard another term for it before though).

>  I don't know why virtualization techniques would
> be necessary, we're free to modify the sandboxed process to just talk to the
> shim via IPC.  And that should only happen when the browser is doing file
> I/O.
>

Virtualization is strictly more powerful than MAC approaches like SELinux and Windows Vista's approach, the virtualized code has literally no way to access the outside (assuming the virualization is correct). This might be overkill, however, given that modern CPUs support it in hardware, I'm not sure that is the case.

A downside though is that to virtualize you need to run non-userspace code. If you want people to easily download and run your browser, that might be a problem?

Comment 5

[Jesse Ruderman]

Related:
* https://wiki.mozilla.org/Features/Security/Low_rights_Firefox
* Bug 387248

Comment 6

[Lucas Adamski [:ladamski]]

I've been running Firefox in low integrity mode on Windows for a few weeks now.  Had to hack a few directory permissions and a few things are still broken, but its been surprisingly low pain.  Just dropping to low integrity is not a panacea however, it still allows a compromised process to read pretty much anyway so we'd need to carefully consider the threat model.  A shim for example can't blindly proxy all I/O requests otherwise you end up with no security benefits, so you need to implement it in such as way that it can be called by a compromised process.

Comment 7

[Ian Melven :imelven]

This should maybe be in Core>Security or Core>General :) 

As Alon mentioned in comment 4, it looks like integrity levels are only supported on Vista and later. The Chromium sandbox is supported on XP as well (although with somewhat reduced security since some objects are not securable until Vista or later) and also uses integrity levels when they're available. Also, as Lucas said, low integrity processes can read medium integrity objects, the Chromium sandbox also doesn't make this assumption. I'm going to investigate the sandbox API some more and experiment with it a bit.

Comment 8

[Jim Mathies [:jimm]]

One comment - for windows the proxy shim shouldn't have any native ui (windows) to prevent messaging deadlocks between the two processes.

Comment 9

[Robert O'Callahan (:roc) (email my personal email if necessary)]

This is probably obvious to everyone on this bug, but I'll mention it anyway:

Sandboxing chrome+content could be good but doesn't capture all the security benefits of content-process sandboxing. For example, we have a lot of security-related browser UI which can be protected by content-process sandboxing but not with chrome+content sandboxing. (Unless we move that UI out of the sandbox into the broker, but that seems really hard to do without breaking everything.) Also, multiple sandboxed content processes can provide some amount of cross-origin protection.

For example, if we implemented a single chrome+content sandbox in the obvious way, then a compromised process could do arbitrary URL bar spoofing, access content across origins in arbitrary ways (including stored passwords etc), access users' geolocation, microphone and camera without warning, etc.

Comment 10

[Ian Melven :imelven]

I updated https://wiki.mozilla.org/Features/Security/Low_rights_Firefox which talks about some of the issues we are working through and ours ideas around a low rights Firefox using the Chromium sandbox.

Comment 11

[tommazzo]

Is there any rough ETA for a Firefox version with a sandbox? I think that sandboxing the browser process/processes is a really important issue nowadays.

Comment 12

[Ian Melven :imelven]

(In reply to tommazzo from comment #11)
> Is there any rough ETA for a Firefox version with a sandbox? I think that
> sandboxing the browser process/processes is a really important issue
> nowadays.

I'm going to begin looking at sandboxing our Windows 8 Metro browser in Q4 (next month), Guillaume Destuynder (:kang) is looking at sandboxing Firefox OS currently, and Patrick Walton has experimented with sandboxing Servo on OSX. There isn't really a rough ETA at the moment but many folks agree that sandboxing is a very important issue.

Comment 13

[tommazzo]

(In reply to Ian Melven :imelven from comment #12)
Thanks for the info. Even without an ETA, it's good to see that there is something going in this direction and that it is being treated as important. Keep up the good work ;)

Comment 14

[[:mmc] Monica Chew (no longer reading bugmail)]

Seems like we should close this now that e10s is alive and ongoing sandboxing work is focusing on content processes.

Comment 15

[Chris]

why is the metro app been given higher priority than the desktop browser?, the desktop browser has more users and is what needs the protection more. Is it because you going for low hanging fruit first?

Comment 16

[Chris Peterson [:cpeterson]]

(In reply to Chris from comment #15)
> why is the metro app been given higher priority than the desktop browser?,
> the desktop browser has more users and is what needs the protection more. Is
> it because you going for low hanging fruit first?

Mozilla is no longer actively developing Firefox for Windows Metro, but work continues on content sandboxing for Windows desktop, Mac OS X, Linux, and Firefox OS.

https://wiki.mozilla.org/Firefox/Metro

Comment 17

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

Move process sandboxing bugs to their new, separate component.

(Sorry for the bugspam; filter on 3c21328c-8cfb-4819-9d88-f6e965067350.)

Comment 18

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

(In reply to [:mmc] Monica Chew (please use needinfo) from comment #14)
> Seems like we should close this now that e10s is alive and ongoing
> sandboxing work is focusing on content processes.

I agree.