|
|
| Line 389: |
Line 389: |
|
| |
|
| <code>ac_add_options --disable-content-sandbox</code> | | <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 = | | = Bug Lists = |