1415159 - Firefox 57 Beta crashes on Mac OS when run under sandbox-exec

Status: RESOLVED INVALID

(Core :: Security: Process Sandboxing, defect, P5)

Description

[Gund]

Attachment: Firefox 57 Beta with Sandbox.png

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.75 Safari/537.36

Steps to reproduce:

I'm running FF 57 Beta on Sierra & High Sierra with mac os sandbox functionality. Is there a way to disable the firefox inbuilt sandbox so that I can use macos sandbox.

I'm trying to run the firefox with below command
/usr/bin/sandbox-exec  -f /<my-sandbox-path>/sandbox.sb /Applications/Firefox.app/Contents/MacOS/firefox-bin


Actual results:

Currently with sandbox enabled, whenever I try to launch FF 57 beta or make any search in new tab, I'm seeing the below error in system logs and tab crashes(screenshot attached)

"kernel[0]: Sandbox: plugin-container(92759) deny forbidden-sandbox-reinit"


Expected results:

Firefox should have launched properly honouring the macos sandbox rules.

Comment 1

[Marcia Knous [:marcia]]

Gund: Can you please type about:crashes in the URL and paste the report ID? That will help us investigate this crash. Thanks!

Comment 2

[Haik Aftandilian [:haik]]

(In reply to Gund from comment #0)
> Steps to reproduce:
> 
> I'm running FF 57 Beta on Sierra & High Sierra with mac os sandbox
> functionality. Is there a way to disable the firefox inbuilt sandbox so that
> I can use macos sandbox.
> 
> I'm trying to run the firefox with below command
> /usr/bin/sandbox-exec  -f /<my-sandbox-path>/sandbox.sb
> /Applications/Firefox.app/Contents/MacOS/firefox-bin

Running Firefox with sandbox-exec isn't supported.

You could disable the web content sandbox via a pref[1], but disabling the plugin sandbox requires a recompile.

With sandbox-exec, a single sandbox policy file (sandbox.sb in your example) will apply to the main Firefox process and all child processes (which are used for web content or plugins etc.) With Firefox, we use what is equivalent to sandbox-exec for each web and plugin child process. This means that the custom sandbox.sb policy applied to web content processes will probably be weaker than default Firefox. And for plugin processes, it will definitely be weaker than default Firefox. This is because the plugin sandbox is already very minimal. The content process sandbox is as minimal as it can be for now without breaking browser functionality. The parent process needs many more permissions than child processes so a policy that works for the parent is going to include several things that default Firefox doesn't allow for content/plugin processes. As a result, you are likely to end up with a much weaker sandbox being applied to web content.

I can understand the desire to sandbox the whole browser (see bug 1382498.)

If you wanted to disable all internal sandboxing and use sandbox-exec, you might be able to get a stronger sandbox or a sandbox that blocks something you're particularly concerned about, but you'll be breaking some browser functionality (which could be OK for your use case.)

Thanks for filing the bug and your interest. You can examine the Mac sandbox policies by looking at source code[2]. I'm going to close this bug as invalid because running with sandbox-exec is not supported.

1. Set security.sandbox.content.level=0 to disable the content sandbo, but I don't recommend it for reasons above.
2. See https://hg.mozilla.org/mozilla-central/file/tip/security/sandbox/mac/SandboxPolicies.h

Comment 3

[Gund]

According to the link https://wiki.mozilla.org/Security/Sandbox#Local_Build_Options, We can disable the sandbox using "--disable-content-sandbox" & "--disable-sandbox", but these are build time options. Can we have these parameters as runtime options so that we can disable/enable sandbox during the browser launch like chrome(https://www.chromium.org/developers/design-documents/sandbox/osx-sandboxing-design).

Comment 4

[Gund]

Also, I'm able to use Firefox 56 & below versions using sandbox-exec command. I want to prevent some file locations from being accessible. Is there a way where I can specify these file locations?

Comment 5

[Gund]

(In reply to Marcia Knous [:marcia - use ni] from comment #1)
> Gund: Can you please type about:crashes in the URL and paste the report ID?
> That will help us investigate this crash. Thanks!

https://crash-stats.mozilla.com/report/index/bc4e61a7-9665-4657-b612-b84690171108#tab-details

Comment 6

[Haik Aftandilian [:haik]]

(In reply to Gund from comment #3)
> According to the link
> https://wiki.mozilla.org/Security/Sandbox#Local_Build_Options, We can
> disable the sandbox using "--disable-content-sandbox" & "--disable-sandbox",
> but these are build time options. Can we have these parameters as runtime
> options so that we can disable/enable sandbox during the browser launch like
> chrome(https://www.chromium.org/developers/design-documents/sandbox/osx-
> sandboxing-design).

It's something we would consider. (Maybe after we retire the security.sandbox.content.level pref). Please file another bug requesting that if it's something you need. If you want to run Firefox this way, for now, I recommend trying setting security.sandbox.content.level=0 and then running under sandbox-exec. I tried this with a "(allow default)" policy and it worked on 58. If your policy is overly restrictive, that can cause crashes.

(In reply to Gund from comment #4)
> Also, I'm able to use Firefox 56 & below versions using sandbox-exec
> command.

Earlier versions would have worked because Firefox didn't enable the sandbox itself. Starting with build 52, on Mac, users with e10s enabled also got content process sandboxing enabled by Firefox itself. When Firefox enables the sandbox itself, it's not compatible with sandbox-exec.

> I want to prevent some file locations from being accessible.
> Is there a way where I can specify these file locations?

No, but the default Firefox sandbox in build 56+ prevents most of the home directory, /Volumes, and other locations from being accessed by content processes. Are these locations in your home directory?

Comment 7

[Gund]

> It's something we would consider. (Maybe after we retire the
> security.sandbox.content.level pref). Please file another bug requesting
> that if it's something you need. If you want to run Firefox this way, for
> now, I recommend trying setting security.sandbox.content.level=0 and then
> running under sandbox-exec. I tried this with a "(allow default)" policy and
> it worked on 58. If your policy is overly restrictive, that can cause
> crashes.
> 

Will file the bug for getting the command line params added in future versions. 

I downloaded 57, 58 nightly dmg (http://ftp.mozilla.org/pub/firefox/nightly/latest-date/) and tried with same sandbox settings. It started working when I set the sandbox pref flag to 0. Previously, I was trying on 57.0b4, 57.0b14 (http://ftp.mozilla.org/pub/firefox/releases/) and it doesn't work even after setting sandbox preference flag. Was any particular change done from 57.0a1 to 57.0b4/57.0b14 related to sandbox? Does it mean, issue will occur in 57 stable build too once it is released?

> No, but the default Firefox sandbox in build 56+ prevents most of the home
> directory, /Volumes, and other locations from being accessed by content
> processes. Are these locations in your home directory?

My current sandbox settings contains locations like "/var/log" & "/usr/local" with "(deny file-read)" rule

Comment 8

[Gund]

Have filed a new feature request(Disabling sandbox via command line parameter) - https://bugzilla.mozilla.org/show_bug.cgi?id=1417005

Comment 9

[Haik Aftandilian [:haik]]

Closing this bug as invalid due to this not being supported.

Leaving needinfo to myself to debug how this worked on build 56.

Comment 10

[Haik Aftandilian [:haik]]

@Gund, could you post your sandbox profile file? I'm curious how this worked on build 56 because I expected calls to sandbox_init to always fail when the parent process is already running under sandbox-exec.

Comment 11

[Haik Aftandilian [:haik]]

I checked running build 56 with sandbox-exec and also hit the crash there due to sandbox_init() failing. That should be the case starting with build 52 which is when we first started sandboxing _webcontent_ in _Release_. The plugin process was sandboxed in earlier versions, but the plugin process is launched on demand and might not be run if the user doesn't visit sites with plugin content. Another possibility is that somehow e10s (multi-process) was disabled which disables content sandboxing.