Opened 18 months ago

Last modified 4 months ago

#22000 new defect

update OSX browser sandbox profile for e10s

Reported by: brade Owned by: tbb-team
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: ff52-esr, tbb-security, tbb-sandboxing, tbb-e10s, TorBrowserTeam201707
Cc: mcs, Dbryrtfbcbhgf Actual Points:
Parent ID: Points:
Reviewer: Sponsor: Sponsor4

Description

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

Child Tickets

Change History (14)

comment:1 Changed 18 months ago by gk

Keywords: tbb-e10s added

comment:2 Changed 18 months ago by 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?

comment:3 in reply to:  2 Changed 18 months ago by gk

Cc: Dbryrtfbcbhgf added

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?

Yes.

comment:4 Changed 18 months ago by mcs

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

comment:5 Changed 18 months ago by gk

Keywords: TorBrowserTeam201705 added; TorBrowserTeam201704 removed

Moving our tickets to May 2017.

comment:6 Changed 17 months ago by mcs

Keywords: tbb-7.0-must-alpha added

comment:7 Changed 17 months ago by 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?

comment:8 Changed 17 months ago by gk

Keywords: tbb-7.0-must added; tbb-7.0-must-alpha removed

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

comment:9 Changed 17 months ago by gk

Keywords: tbb-7.0-must removed

Nothing for 7.0 stable, thus removing the keyword.

comment:10 Changed 17 months ago by gk

Keywords: TorBrowserTeam201706 added; TorBrowserTeam201705 removed

Moving our tickets to June.

comment:11 Changed 16 months ago by gk

Keywords: TorBrowserTeam201707 added; TorBrowserTeam201706 removed

Moving Tickets to July 2017.

comment:12 Changed 14 months ago by gk

Resolved #23167 as duplicate.

comment:14 in reply to:  7 Changed 4 months ago by tom

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.

Note: See TracTickets for help on using tickets.