1007971 - Enable `SandboxBroker` to use different security policies for different types of processes

Status: RESOLVED DUPLICATE of bug 985252

(Core :: Security, defect)

Description

[Tim Abraldes [:TimAbraldes] [:tabraldes]]

Attachment: Patch v1

`SandboxBroker` can manipulate the security level of a sandboxed process with fine granularity by adjusting the `sandbox::TargetPolicy` before launching the process. 

Consumers of `SandboxBroker` should be able to tell the `SandboxBroker` what type of process is being created so that `SandboxBroker` can initialize its security policy appropriately.

It is important to note that consumers of `SandboxBroker` cannot instantiate `sandbox::TargetPolicy`s themselves because we can't include the necessary chromium headers in code outside of "security/sandbox/win".

Comment 1

[Tim Abraldes [:TimAbraldes] [:tabraldes]]

If we can set the policy for plugin processes to be unrestrictive enough, we may be able to sandbox our regular plugins from the get-go and not special-case plugins to avoid the sandbox (bug 934476)

Try run:
  https://tbpl.mozilla.org/?tree=Try&rev=3aacfd5773d8

Comment 2

[Tim Abraldes [:TimAbraldes] [:tabraldes]]

(In reply to Tim Abraldes [:TimAbraldes] [:tabraldes] from comment #1)
[...]
> Try run:
>   https://tbpl.mozilla.org/?tree=Try&rev=3aacfd5773d8

Oops! That try run doesn't force-enable `MOZ_CONTENT_SANDBOX`

Updated try run:
  https://tbpl.mozilla.org/?tree=Try&rev=5d08483ccdd5

Comment 3

[Tim Abraldes [:TimAbraldes] [:tabraldes]]

And this time correctly enabling sandboxing:
  https://tbpl.mozilla.org/?tree=Try&rev=727a3bbdb501

Comment 4

[Bob Owen (:bobowen)]

(In reply to Tim Abraldes [:TimAbraldes] [:tabraldes] from comment #3)
> And this time correctly enabling sandboxing:
>   https://tbpl.mozilla.org/?tree=Try&rev=727a3bbdb501

Hi Tim,

I'm not sure how relevant this is for you as you're not looking at the content process side of things at the moment, but it might help.

So, this is compiling with the sandbox enabled, but not running with the required e10s prefs, so it's still running in a single process.

I've been looking at running the tests with the sandbox on tinderbox and the easiest way I've found can be seen in the patch for this try push here:
https://tbpl.mozilla.org/?tree=Try&rev=1aa4f21a3159

This enables the sandbox for the build and adds the --e10s option for the test runs to give us a plugin-container process.
It also restricts the tests to some that I know pass locally.

Unfortunately, as you can see it's not working at the moment.
It looks like the child process isn't starting as there is no logging from it.
I've tried running the tests locally with this build and they work OK.
In this patch I've also tried removing the restrictions, but I'm not sure it's even getting that far.

So, I've just arranged to get a loan of one of the test slaves to try and see why they're not working on tinderbox.

I'll copy you in on the bug, when I've raised it.
Might be in the morning.

Comment 5

[Tim Abraldes [:TimAbraldes] [:tabraldes]]

> I'm not sure how relevant this is for you as you're not looking at the
> content process side of things at the moment, but it might help.
> 
> So, this is compiling with the sandbox enabled, but not running with the
> required e10s prefs, so it's still running in a single process.

Thanks for the heads up! I'm using the Tryserver runs as a check to make sure that the changes in this bug aren't breaking the single-process case. The patch in this bug sandboxes regular plugin processes (but with super-unrestrictive settings) and also the "IPDL Unit Test" process type. I knew from bug 934476 comment 0 that that might cause problems, hence the try runs.

Comment 6

[Maire Reavy [:mreavy]]

Per irc conversation with Tim, the work here will be landed as part of the patch in bug 985252.