Security/Sandbox: Difference between revisions
Haftandilian (talk | contribs) (Fix Table) |
Haftandilian (talk | contribs) (Fix table again.) |
||
Line 271: | Line 271: | ||
* read access to the profile directory (apart from the chrome and extensions subdirectories) | * read access to the profile directory (apart from the chrome and extensions subdirectories) | ||
* read access to the home directory | * read access to the home directory | ||
| | || | ||
|} | |} | ||
Revision as of 23:51, 18 April 2017
Overview
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 | Aurora | Beta | Release | ||||
---|---|---|---|---|---|---|---|---|
Level | Level | Version | Level | Version | Level | Version | ||
Windows (content) | Level 2 | Level 1 | Fx50 | Level 1 | Fx50 | Level 1 | Fx50 | |
Windows (compositor) | Level 0 | |||||||
Windows (GMP) | enabled | enabled | enabled | enabled | ||||
Windows 64bit (NPAPI Plugin) | enabled | enabled | enabled | enabled | ||||
OSX (content) | Level 2 | Level 1 | Fx52 | Level 1 | Fx52 | Level 1 | Fx52 | |
OSX (GMP) | enabled | enabled | enabled | enabled | ||||
Linux (content) | Level 2 | Level 2 | Fx54 | |||||
Linux (GMP) | enabled | enabled | enabled | enabled |
Windows
Content / Compositor Levels
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_BOTTOM_UP_ASLR |
Delayed Mitigations | None |
MITIGATION_STRICT_HANDLE_CHECKS |
MITIGATION_STRICT_HANDLE_CHECKS |
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 | yes** | 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_BOTTOM_UP_ASLR |
MITIGATION_BOTTOM_UP_ASLR |
Delayed Mitigations |
MITIGATION_STRICT_HANDLE_CHECKS |
MITIGATION_STRICT_HANDLE_CHECKS |
MITIGATION_STRICT_HANDLE_CHECKS |
* Not implemented yet.
** Might be dropped.
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 |
Delayed Mitigations |
MITIGATION_STRICT_HANDLE_CHECKS |
[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 |
Delayed Mitigations |
OSX
Content Levels
Job Level | What's Blocked by the Sandbox? | |
---|---|---|
Level 1 [1] |
| |
Level 2 |
| |
Level 3 |
|
[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
Linux
Content
Gecko Media Plugin
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 | TBD | TBD |
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.
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
Misc. 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 platforms. | All |
MOZ_DISABLE_NPAPI_SANDBOX | Disable 64-bit NPAPI process sandbox, Windows specific. | Windows |
MOZ_ALLOW_WEAKER_SANDBOX | Specific to 64-bit Plugin sandbox, allows 64-bit NPAPI sandbox level to drop below 2. | Windows |
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:
security/sandbox
The chromium sandbox is based on the chromium base libraries (Google's code) which are located at:
security/sandbox/chromium/base
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:
security/sandbox/chromium-shim/base
The chromium Windows sandbox itself (Google's code) is located at:
security/sandbox/chromium/sandbox/win
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:
Content process
GMP process
NPAPI process
Level descriptions header:
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:
https://dxr.mozilla.org/mozilla-central/rev/918df3a0bc1c/ipc/glue/GeckoChildProcessHost.cpp#1030
All of the code that sets policies can be found here:
http://dxr.mozilla.org/mozilla-central/source/security/sandbox/win/src/sandboxbroker/sandboxBroker.cpp
OSX
The OSX sandbox is based on the TrustedBSD MAC Framework. It is undocumented and considered private by Apple.
Linux
Seccomp stands for secure computing mode. It's a simple sandboxing tool in the Linux kernel, available since Linux version 2.6.12. When enabling seccomp, the process enters a "secure mode" where a very small number of system calls are available (exit(), read(), write(), sigreturn()). Writing code to work in this environment is difficult; for example, dynamic memory allocation (using brk() or mmap(), either directly or to implement malloc()) is not possible.
Seccomp-BPF is a more recent extension to seccomp, which allows filtering system calls with BPF (Berkeley Packet Filter) programs. Most of our Linux user base have systems that support seccomp-bpf.
These filters can be used to allow or deny an arbitrary set of system calls, as well as filter on system call arguments (numeric values only; pointer arguments can't be dereferenced). Additionally, instead of simply terminating the process, the filter can raise a signal, which allows the signal handler to simulate the effect of a disallowed system call (or simply gather more information on the failure for debugging purposes). Seccomp-bpf is available since Linux version 3.5 and is usable on the ARM architecture since Linux version 3.10. Several backports are available for earlier kernel versions.
For limitations that apply to the semantics of system calls (e.g., “can this process access the filesystem”, not “can this process use system call #83”) we require unprivileged user namespaces, which a large majority of desktop users don't support. Specifically: chroot()ing into a deleted directory to revoke FS access, and namespace unsharing for networking, SysV IPC if possible, and process IDs.
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
- sbwc1
- 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
- sbmc1
- 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
- sblc1
- Windows 64-bit NPAPI
- sbwn1
- (completed, fx52)
Triage Lists
- Triage list: http://is.gd/Mfb8L9
- Lists any bug with sb?
- Lists sandboxing component bugs that are not tracked by a milestone
- Ignores sb+, sb-, and sb? bugs with needinfos
- meta bugs
- sb? Triage List: http://is.gd/B3KscF
- does not include needinfo bugs
- sb? needinfos: http://is.gd/dnSyBs
- webrtc specific sandboxing bugs: https://is.gd/c5bAe6
- sb tracking + 'webrtc'
Communication
Weekly Team Meeting | Thursday at 8:00am PT
|
IRC |
|
Newsgroup/Mailing List |
People
Engineering Management |
|
Project Management |
|
QA |
|
Development Team |
|
Other Teams |
|
Repo Module Ownership
Links
- Electrolysis Wiki Page (lot of additional resource links)
- Chromium Sandbox
- Apple's Sandbox guide
- "Introducing Chrome's next-generation Linux sandbox" (seccomp-bpf related)
- Native Client on Wikipedia (Links to papers on Native Client's design and use of SFI, as well as papers on SFI itself.)
- Features of Protected Mode in Internet Explorer
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.