1332703 - replace browser.tabs.remote.separateFileUriProcess with a new sandobox security level

Status: RESOLVED WONTFIX

(Core :: Security: Process Sandboxing, defect)

Description

[Jim Mathies [:jimm]]

Looking over how this works, it seems odd to me that we have a pref under browser.tabs.remote that controls security of a content process. It's also hard to test and document the differences. I'm wondering if we should remove browser.tabs.remote.separateFileUriProcess, and instead tie this to the level pref over in security.sandbox.content.level, or possibly add a new level pref for this process that's independent.

For example, we could set things up so that each level value is tied to a static set of security settings. We might have:

level 1:
 content process security settings rev 1
level 2:
 content process security settings rev 2
level 3:
 local content process security settings rev 1
level 4:
 remote content process security settings rev 2
level 5:
 local content process security settings rev 2
level 6:
 remote content process security settings rev 3
..

Then have two prefs, one for each content process.

Alternatively we could store a single level value, and expand the list of levels to include changes we make to either process. 

level 1:
 content process security settings rev 1
level 2:
 content process security settings rev 2
level 3:
 local + remote combo settings rev 1
level 4:
 local + remote combo settings rev 2
..

Generally though I think separateFileUriProcess needs to go away. TBD.

Comment 1

[Jim Mathies [:jimm]]

The first proposal would allow a user to change the local file content process to match that of the remote content process, or maybe even turn security off there, or downgrade it. Providing the same option that the boolean separateFileUriProcess provides.

Comment 2

[Bob Owen (:bobowen)]

I don't understand the issue here.

The browser.tabs.remote.separateFileUriProcess pref controls whether we have a separate process at all.
It's not a security setting as such.

We then modify the normal content process policy to allow file read access for this process. (At least that's how it currently works on Windows.)

So essentially apart from the read access the policy is tied to the normal content one, so as we can make improvements there we get them for the file content process as well.

I think having two separate prefs, unnecessarily complicates things.

Comment 3

[Haik Aftandilian [:haik]]

On Mac, the only difference between the web and file sandboxes will be the file read permissions. If that's true for other platforms, and we don't foresee it changing, then having another "level" pref won't be needed.