update OSX browser sandbox profile for e10s

For compatibility with e10s, the TB.sb file needs to be updated to allow creation of content processes.

added TorBrowserTeam201707 component::applications/tor browser ff52-esr owner::tbb-team priority::medium severity::normal sponsor::4 status::new tbb-e10s tbb-sandboxing tbb-security type::defect labels

Trac:
Keywords: N/A deleted, tbb-e10s added

So to be clear, this would cause people on OS X using Tor Browser 7a3 who try to run the sandbox thing to fail? Like the person in #22027 (moved)?

Replying to arma:

So to be clear, this would cause people on OS X using Tor Browser 7a3 who try to run the sandbox thing to fail? Like the person in #22027 (moved)?

Yes.

Trac:
Cc: mcs to mcs, Dbryrtfbcbhgf

A workaround is to disable Firefox's multiprocess mode by setting MOZ_FORCE_DISABLE_E10S before starting the browser, e.g., MOZ_FORCE_DISABLE_E10S=1 ./start-browser-with-sandbox

Moving our tickets to May 2017.

Trac:
Keywords: TorBrowserTeam201704 deleted, TorBrowserTeam201705 added

Trac:
Keywords: N/A deleted, tbb-7.0-must-alpha added

Kathy and I were hoping to come up with a quick fix for this ticket, but it turns out that nesting of sandbox configs is not supported on OSX. That means that we either need to disable Mozilla's content process sandbox or we need to disable our sandbox. Since it seems like there may be a way in our sandbox profile to say "allow exec of this specific executable and start it without a sandbox" and since (hopefully) Mozilla enables their sandbox as early as possible, the second approach is probably the one to use. In other words, our tb.sb profile would apply to the chrome process and Mozilla's built in content process sandbox rules would apply to the content/tab process. But we should look and see what we are giving up if we do that, e.g., what does Mozilla allow that we don't want to allow?

We are beyond the alpha testing. Moving tickets for tbb-7.0-must.

Trac:
Keywords: tbb-7.0-must-alpha deleted, tbb-7.0-must added

Nothing for 7.0 stable, thus removing the keyword.

Trac:
Keywords: tbb-7.0-must deleted, N/A added

Moving our tickets to June.

Trac:
Keywords: TorBrowserTeam201705 deleted, TorBrowserTeam201706 added

Moving Tickets to July 2017.

Trac:
Keywords: TorBrowserTeam201706 deleted, TorBrowserTeam201707 added

Resolved #23167 (moved) as duplicate.

Here is what the Google folks are doing. Might be helpful:

https://chromium.googlesource.com/chromium/src.git/+/master/sandbox/mac/seatbelt_sandbox_design.md

Replying to mcs:

Kathy and I were hoping to come up with a quick fix for this ticket, but it turns out that nesting of sandbox configs is not supported on OSX. That means that we either need to disable Mozilla's content process sandbox or we need to disable our sandbox. Since it seems like there may be a way in our sandbox profile to say "allow exec of this specific executable and start it without a sandbox" and since (hopefully) Mozilla enables their sandbox as early as possible, the second approach is probably the one to use. In other words, our tb.sb profile would apply to the chrome process and Mozilla's built in content process sandbox rules would apply to the content/tab process. But we should look and see what we are giving up if we do that, e.g., what does Mozilla allow that we don't want to allow?

We had discussed this at the All Hands last week; and if there is a sandbox applied to the parent process, we cannot apply the content process sandbox policy.

It's worth double checking just to be certain (especially on the latest/preview OSX); but I believe this is the case.

We could try reporting this up to Apple and maybe they'll improve the implementation though.

mentioned in issue #22027 (moved)

mentioned in issue #23167 (moved)

mentioned in issue #26438 (moved)

moved to tpo/applications/tor-browser#22000 (closed)

mentioned in issue tpo/applications/tor-browser#26438 (closed)