Security/Sandbox: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
m (updating notes on level system)
(removal of)
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 =

Revision as of 22:56, 25 July 2017

Overview

550px-Sandboxing basic architecture.png

Security Sandboxing makes use of child processes as a security boundary. The process model, i.e. how Firefox is split into various processes and how these processes interact between each other is common to all platforms. For more information see the Electrolysis wiki page. The security aspects of a sandboxed child process are implemented on a per-platform basis. See the Platform Specifics section below for more information.

Current Status

Sandbox Trunk Beta Release
Level Level Version Level Version
Windows (content) Level 3 Level 1 Fx50 Level 1 Fx50
Windows (compositor) Level 0 [1]
Windows (GMP) enabled enabled enabled
Windows 64bit (NPAPI Plugin) enabled enabled enabled
OSX (content) Level 3 Level 1 Fx52 Level 1 Fx52
OSX (GMP) enabled enabled enabled
Linux (content) Level 2 Level 2 Fx54 Level 2 Fx54
Linux (GMP) enabled enabled enabled

A 'level' value reflects unique sandbox security settings for each platform and process. Most processes only have two "active" levels, the current setting and a lower (previous released) setting. Level settings other than these two values carry no guarantee of altering security behavior, level settings are primarily a release rollout debugging feature.

DEPRECATION WARNING - The current level system will be replaced by a configuration system that allows for more fine grain control over sandbox settings. Current target for this change is Firefox 57.

[1] Level 1 available but disabled due to various regressions, see bug 1347710

Windows

Content

Sandbox security related setting are grouped together and associated with a security level. Lower level values indicate a less restrictive sandbox.

Sandbox Feature Level 0 Level 1 Level 2
Job Level JOB_NONE JOB_NONE JOB_INTERACTIVE
Access Token Level USER_NON_ADMIN USER_NON_ADMIN USER_INTERACTIVE
Alternate Desktop no no no
Alternate Windows Station no no no
Initial Integrity Level INTEGRITY_LEVEL_MEDIUM INTEGRITY_LEVEL_LOW INTEGRITY_LEVEL_LOW
Delayed Integrity Level INTEGRITY_LEVEL_MEDIUM INTEGRITY_LEVEL_LOW INTEGRITY_LEVEL_LOW
Mitigations None

MITIGATION_BOTTOM_UP_ASLR
MITIGATION_HEAP_TERMINATE
MITIGATION_SEHOP
MITIGATION_DEP_NO_ATL_THUNK
MITIGATION_DEP

MITIGATION_BOTTOM_UP_ASLR
MITIGATION_HEAP_TERMINATE
MITIGATION_SEHOP
MITIGATION_DEP_NO_ATL_THUNK
MITIGATION_DEP

Delayed Mitigations None

MITIGATION_STRICT_HANDLE_CHECKS
MITIGATION_DLL_SEARCH_ORDER

MITIGATION_STRICT_HANDLE_CHECKS
MITIGATION_DLL_SEARCH_ORDER

Sandbox Feature Level 3 Level 10 Level 20
Job Level JOB_RESTRICTED JOB_RESTRICTED JOB_LOCKDOWN
Access Token Level USER_LIMITED USER_LIMITED USER_LOCKDOWN
Alternate Desktop no yes yes
Alternate Windows Station no yes yes
Initial Integrity Level INTEGRITY_LEVEL_LOW INTEGRITY_LEVEL_LOW INTEGRITY_LEVEL_LOW
Delayed Integrity Level INTEGRITY_LEVEL_LOW INTEGRITY_LEVEL_LOW INTEGRITY_LEVEL_UNTRUSTED
Mitigations

MITIGATION_BOTTOM_UP_ASLR
MITIGATION_HEAP_TERMINATE
MITIGATION_SEHOP
MITIGATION_DEP_NO_ATL_THUNK
MITIGATION_DEP
MITIGATION_EXTENSION_POINT_DISABLE

MITIGATION_BOTTOM_UP_ASLR
MITIGATION_HEAP_TERMINATE
MITIGATION_SEHOP
MITIGATION_DEP_NO_ATL_THUNK
MITIGATION_DEP
MITIGATION_EXTENSION_POINT_DISABLE

MITIGATION_BOTTOM_UP_ASLR
MITIGATION_HEAP_TERMINATE
MITIGATION_SEHOP
MITIGATION_DEP_NO_ATL_THUNK
MITIGATION_DEP
MITIGATION_EXTENSION_POINT_DISABLE

Delayed Mitigations

MITIGATION_STRICT_HANDLE_CHECKS
MITIGATION_DLL_SEARCH_ORDER

MITIGATION_STRICT_HANDLE_CHECKS
MITIGATION_DLL_SEARCH_ORDER

MITIGATION_STRICT_HANDLE_CHECKS
MITIGATION_DLL_SEARCH_ORDER


Windows Feature Header

Gecko Media Plugin

Sandbox Feature Level
Job Level JOB_LOCKDOWN
Access Token Level USER_LOCKDOWN, USER_RESTRICTED[1]
Initial Integrity Level INTEGRITY_LEVEL_LOW
Delayed Integrity Level INTEGRITY_LEVEL_UNTRUSTED
Alternate desktop yes
Mitigations

MITIGATION_BOTTOM_UP_ASLR
MITIGATION_HEAP_TERMINATE
MITIGATION_SEHOP
MITIGATION_DEP_NO_ATL_THUNK
MITIGATION_DEP

Delayed Mitigations

MITIGATION_STRICT_HANDLE_CHECKS
MITIGATION_DLL_SEARCH_ORDER

[1] depends on the media plugin

64-bit Plugin

Sandbox Feature Level
Job Level JOB_UNPROTECTED
Access Token Level USER_INTERACTIVE
Initial Integrity Level INTEGRITY_LEVEL_LOW
Delayed Integrity Level INTEGRITY_LEVEL_LOW
Alternate desktop no
Mitigations

MITIGATION_BOTTOM_UP_ASLR
MITIGATION_HEAP_TERMINATE
MITIGATION_SEHOP
MITIGATION_DEP_NO_ATL_THUNK
MITIGATION_DEP

Delayed Mitigations

OSX

Content Levels

Job Level What's Blocked by the Sandbox?
Level 1 [1]
  • write access to most of the filesystem
  • inbound/outbound network I/O
  • exec, fork
  • printing
Level 2
  • write access to most of the filesystem
  • inbound/outbound network I/O
  • exec, fork
  • printing
  • read access to the profile directory (apart from the chrome and extensions subdirectories)
  • read access to ~/Library
Level 3
  • write access to most of the filesystem
  • read access to most of the filesystem
    • read access to the profile directory (apart from the chrome and extensions subdirectories)
    • read access to the home directory
  • inbound/outbound network I/O
  • exec, fork
  • printing

[1] Level 1 restrictions are a subset of level 2. Level 2 restrictions are a subset of level 3.

See How security.sandbox.content.level Affects File Access and Filter rules for more details.

Gecko Media Plugins

Filter rules

Linux

Content

Filter ruleset

Filesystem access policy

Gecko Media Plugin

Filter ruleset

Preferences

Process Type Preference Type Preference
Content numerical security.sandbox.content.level
NPAPI Plugin boolean dom.ipc.plugins.sandbox-level.default
dom.ipc.plugins.sandbox-level.<plugintype>
Compositor numerical security.sandbox.gpu.level
Media Embedded N/A

Note - Levels greater than the current default for a particular process type are not implemented.

File System Restrictions

Sandboxing enforces file system write and read restrictions for XUL based add-on content (frame and process) scripts. To avoid issues as sandboxing features roll out add-on authors should update their legacy add-on code today such that content scripts no longer attempt to read or write from restricted locations. Note these restrictions do not affect WebExtension content script or XUL add-on script running in the browser process.

File system access rules for content processes, reverse precedence:

Location Access Type Restriction
file system read/write deny by default
install location write deny
install location read allow
system library locations write deny
system library locations read allow
profile/* read/write deny by default
profile/extensions write deny
profile/extensions read allow

Debugging Features

Activity Logging

The following prefs control sandbox logging. Output is sent to the Browser Console when available, and to a developer console attached to the running browser process. 

security.sandbox.logging.enabled (boolean)

security.sandbox.windows.log.stackTraceDepth (integer, Windows specific)

The following environment variables also triggers sandbox logging output: 

MOZ_SANDBOX_LOGGING=1

OSX Specific

Sandbox violation logging is on by default when the sandbox is enabled. Use the Console.app application to view the logs.

Environment variables

ENVIRONMENT VARIABLE DESCRIPTION PLATFORM
MOZ_DISABLE_CONTENT_SANDBOX Disables content process sandboxing for debugging purposes. All
MOZ_DISABLE_GMP_SANDBOX Disable media plugin sandbox for debugging purposes All
MOZ_DISABLE_NPAPI_SANDBOX Disable 64-bit NPAPI process sandbox Windows
MOZ_DISABLE_GPU_SANDBOX Disable GPU process sandbox Windows

Setting a custom environment in Windows

1) Close Firefox
2) Browser to the location of your Firefox install using Explorer
3) Shift + Right-click in the folder window where firefox.exe is located, select "Open command window here"
4) Add the environment variable(s) you wish to set to your command window -

set MOZ_DISABLE_NPAPI_SANDBOX=1(return)

5) enter firefox.exe and press enter to launch Firefox with your custom environment

Local Build Options

To disable building the sandbox completely build with this in your mozconfig:

ac_add_options --disable-sandbox

To disable just the content sandbox parts:

ac_add_options --disable-content-sandbox

Bug Lists

  • Windows Content Process
    • sbwc1
      • low integrity sandbox support
      • Roll out level 1 sandbox policy to release. (completed, fx50)
    • sbwc2
      • file:/// isolation
      • User token removal, to limit User directory file access
      • use JOB_RESTRICTED to apply further global restrictions
      • printing tests
      • roll out level 3 to release
    • Need to scope out future milestones including:
      • using an alternate desktop
      • using an alternate winstation and desktop
      • general file system (and registry) read access restrictions (USER_RESTRICTED / UESR_LOCKDOWN)
      • JOB_LOCKDOWN
      • reducing exposure to system APIs
      • running at untrusted integrity level
      • use of lowbox token / AppContainers
  • OSX Content Process
    • sbmc1
      • Roll out level 1 OSX security sandbox access ruleset. (completed, fx52)
      • Prevent file system write access
    • sbmc2
      • Home directory read access restrictions
      • file:/// isolation
      • roll out level2 OSX sandbox to release
    • sbmc3
      • TBD: Triage existing sandbox rules and define set to remove in milestone 3
      • File access: system /tmp and /var/folders/ and any other individual directories
      • Limit User directory file access
  • Linux Content Process
    • sblc1
      • enable (heavily perforated) seccomp-bpf filter by default in Nightly
    • sblc2
      • land basic file system broker
      • remove/restrict file system write access
      • roll out entry level file broker to release
    • sblc3
      • remove/restrict file system read access
      • file:/// isolation?
      • remote pulseaudio work (BLOCKED on media work, TBD)
    • sblc4
      • remove/restrict socket access/modification and solve X11 problem
    • sblc5
      • make use of chroot and user namespaces
  • Windows 64-bit NPAPI

Triage Lists

Communication

Weekly Team Meeting Thursday at 8:00am PT
  • Vidyo: "PlatInt" room
  • Invitation: Contact Jim Mathies to get added to the meeting invite list.
  • Meeting Notes Archive
IRC
  • Server: irc.mozilla.org
  • Channel: #boxing
Newsgroup/Mailing List

People

Engineering Management
  • Jim Mathies (jimm)
Project Management
  • TBD
QA
  • Tracy Walker (Quality Assurance Lead)
Development Team
  • Haik Aftandilian (haik)
  • Julian Hector (tedd)
  • Jim Mathies (jimm)
  • Bob Owen (bobowen)
  • David Parks (handyman)
  • Gian-Carlo Pascutto (gcp)
Other Teams

Repo Module Ownership

Links

Research

B2G Archive

B2G has always been “sandboxed” to some extent; every app/tab gets its own content process, which uses the Android security model: a separate uid per process, no group memberships, and kernel patches that require group membership for things like network access. But privilege escalation via kernel vulnerabilities is relatively common, so we also use the seccomp-bpf system call filter to reduce the attack surface that a compromised content process can directly access.

Older

Retrieved from "https://wiki.allizom.org/index.php?title=Security/Sandbox&oldid=1176500"