<code>ac_add_options --disable-content-sandbox</code>
= Platform Specifics =
== Windows ==
=== Source Code Overview ===
The core of the Windows sandbox is Google's chromium sandbox. Relative to the root of mozilla-central, the sandbox exists at:
<code>security/sandbox</code>
The chromium sandbox is based on the chromium base libraries (Google's code) which are located at:
<code>security/sandbox/chromium/base</code>
There is also partial/shim code to get the base code compiling with our SDK build settings or to limit the base code by reducing dependencies at:
<code>security/sandbox/chromium-shim/base</code>
The chromium Windows sandbox itself (Google's code) is located at:
<code>security/sandbox/chromium/sandbox/win</code>
=== Processes Overview ===
There are 2 processes when dealing with a sandboxed application:
# The broker: The parent process that starts sandboxed children
# The target: The child process that is sandboxed
Both processes make use of the chromium sandbox library, but they make use of it indirectly through 2 libraries (Mozilla code).
This indirect use of the library is due to header conflicts with the ipc layer where it has a different, much older, non compatible, copy of the chromium base library ({{bug|925471}}):
# For the broker, ./security/sandbox/win/src/sandboxbroker
# For the target, ./security/sandbox/win/src/sandboxtarget
=== Key source code locations ===
The sandboxed target process lowers its own privileges after initialization via these calls:<br>
[https://dxr.mozilla.org/mozilla-central/rev/918df3a0bc1c/dom/ipc/ContentChild.cpp#1455 Content process]<br>
[https://dxr.mozilla.org/mozilla-central/rev/918df3a0bc1c/dom/media/gmp/GMPLoader.cpp#239 GMP process]<br>
[https://dxr.mozilla.org/mozilla-central/rev/918df3a0bc1c/dom/plugins/ipc/PluginProcessChild.cpp#122 NPAPI process]
Level descriptions header:<br>
http://mxr.mozilla.org/mozilla-central/source/security/sandbox/chromium/sandbox/win/src/security_level.h
The call that starts the sandboxed process in Firefox is:<br>
https://dxr.mozilla.org/mozilla-central/rev/918df3a0bc1c/ipc/glue/GeckoChildProcessHost.cpp#1030
All of the code that sets policies can be found here:<br>
http://dxr.mozilla.org/mozilla-central/source/security/sandbox/win/src/sandboxbroker/sandboxBroker.cpp
== OSX ==
The OSX sandbox is based on the [http://www.trustedbsd.org/mac.html TrustedBSD MAC Framework.] It is undocumented and considered private by Apple.
* [https://wiki.mozilla.org/Sandbox/OS_X_Rule_Set Mozilla OSX Sandbox Ruleset wiki page]
* [http://reverse.put.as/wp-content/uploads/2011/09/Apple-Sandbox-Guide-v1.0.pdf OSX Sandbox]
* [https://www.romab.com/ironsuite/SBPL.html OSX sandbox policy language]
== Linux ==
Linux sandboxing technologies generally fall into two categories: those that act on the semantics of operations (e.g., what happens when a filesystem path is resolved) and those that affect raw system calls (e.g., what happens when syscall #83 is invoked). There's a more
detailed explanation in [http://blog.cr0.org/2012/09/introducing-chromes-next-generation.html the blog post announcing seccomp-bpf], which is the main syscall-filtering facility.
We're primarily using seccomp-bpf because it's the only thing that's available everywhere (>99% of the Linux Firefox userbase, at last count). There are some weaknesses to using only seccomp-bpf:
* The possibility of overlooking obscure corner cases, like [https://bugzilla.mozilla.org/show_bug.cgi?id=1066750 unnamed datagram sockets], that could allow privilege escalation.
* The seccomp-bpf policy can act on argument values, but can't dereference pointer arguments, like the path to <tt>open()</tt>; in such cases it's necessary to intercept the syscall and message an unsandboxed broker to validate and perform the operation, which adds latency and attack surface.
Semantic isolation, like changing the filesystem root or creating a separate network stack with no access to the real network (unsharing the network namespace), has traditionally required superuser privileges. There are two ways to get around this: unprivileged user namespaces and a setuid-root helper executable.
We're using unprivileged user namespaces for additional security where available; they don't require any system-level setup, and 88% of Linux Firefoxes are on a kernel that supports them, according to telemetry. The reason we don't require it (as, for example, [https://github.com/servo/gaol gaol] does) is the other 12%: some distributions disable the feature because it has its own security risks. (Briefly: it makes subtle changes to authorization semantics, and it exposes kernel attack surface that's normally restricted to root; both of these have led to local privilege escalation vulnerabilities in the past.)
But shipping a setuid-root executable *also* doesn't work for everyone: we support downloading and running Firefox as a regular user, without having it installed as a system package. There are also some changes that would be needed to how we create child processes and set up IPC communication with them, and invoke the <tt>chroot</tt> helper; and it complicates testing. Chromium used this approach in 2009 because there was no other choice; [https://crbug.com/312380 they would prefer to remove it] but don't seem to have a timeline for doing so.
At the time of this writing (June 2017), namespace sandboxing is used only for media plugins (EME CDMs and OpenH264): content processes can't use any of it at least until audio is remoted.
= Bug Lists =
