Security/Sandbox

From MozillaWiki
< Security
Revision as of 22:51, 16 October 2015 by JLD (talk | contribs) (→‎Status: Wipe the years-old Linux/B2G status/planning info and replace with notes from the now-frozen etherpad)
Jump to navigation Jump to search
The fox cannot escape the box.
The fox is safe in the sandbox. The fox cannot escape.

Sandboxing Firefox

This page tracks and explain how sandboxing is being worked on for Firefox (OS, Desktop, etc.)


Sandboxes use the process as the security boundary. The process model, i.e. how we split Firefox into processes and how the processes interact between each other is common to all platforms.

The implementation of the sandbox mechanism is independent, per platform. Firefox OS and Linux desktop Firefox use the same implementation.

Sandboxing basic architecture.png

Documentation

Windows Sandbox overview

Source code overview

Relative to the root of mozilla-central, the sandbox exists at: ./security/sandbox

Linux related sandbox is inside the linux subfolder.

The core of the Windows sandbox is Google's chromium sandbox.

The chromium sandbox is based on the chromium base libraries (Gogole's code) which are located at: ./security/sandbox/chromium (excluding ./security/sandbox/chromium/base/shim/ which overrides some functionality to make it compatible with our SDK build settings, which is Mozilla code) The chromiums Windows sandbox itself (Google's code) is inside ./security/sandbox/win/src (excluding ./security/sandbox/win/src/sandboxbroker and ./security/sandbox/win/src/sandboxtarget subfolders, which is Mozilla code)

There are 2 processes when dealing with a sandboxed application:

  1. The broker: The parent process that starts sandboxed children
  2. 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:

  1. For the broker, ./security/sandbox/win/src/sandboxbroker
  2. For the target, ./security/sandbox/win/src/sandboxtarget

Build settings

To enable e10s you can use a normal mozilla-central build but you should enable this pref: browser.tabs.remote.autostart It's recommended to use a different profile for dev if you don't want to trash your existing profile.

The sandbox is in use by our e10s code when you build with this in your mozconfig: ac_add_options --enable-content-sandbox

Environment variables

Disable content process sandbox MOZ_DISABLE_CONTENT_SANDBOX
Disable media plugin sandbox MOZ_DISABLE_GMP_SANDBOX

Key source code locations

The sandboxed target process lowers its own privliges after initialization via this call: http://dxr.mozilla.org/mozilla-central/source/ipc/app/MozillaRuntimeMain.cpp#78

The call that starts the sandboxed process in Firefox is: http://dxr.mozilla.org/mozilla-central/source/ipc/glue/GeckoChildProcessHost.cpp#784

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

Linux/B2G Sandbox Overview

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 Security/Sandbox/Seccomp to try to reduce the attack surface that a compromised content process can directly access. (TODO: also point to the SELinux work.)

Desktop Linux is similar but more complicated; most systems have seccomp-bpf, but 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 minority of desktop Firefoxes don't yet have. (TODO: link to bugs with discussion/rationale.) Specifically: chroot()ing into a deleted directory to revoke FS access, and namespace unsharing for networking, SysV IPC if possible, and process IDs. (TODO: link to more info / code, and maybe make this a sub-page like seccomp.)

Roadmap (high-level)

This roadmap may evolve over time.

  1. Land core sandboxing code
    1. [DONE] B2G
    2. [DONE] Linux (except pid namespaces)
    3. [DONE] Windows
    4. [DONE] MacOS X
  2. Sandbox GeckoMediaPlugins
    1. [INVALID] B2G
    2. [DONE] Linux
    3. [DONE] Windows
    4. [DONE] MacOS X
  3. Minimal non-breaking “sandbox” for content
    1. [DONE] B2G
    2. [DONE] MacOS X
    3. [DONE] Windows
    4. [IN PROGRESS] Linux bug 742434
  4. Content sandbox milestones
    1. File write access
      1. [IN PROGRESS] B2G bug 1214947
      2. [IN PROGRESS] Desktop — printing is main blocker
    2. File read access
      1. [IN PROGRESS] B2G bug 1214947
      2. [NEW] Desktop — see dependencies of bug sandbox-fs
    3. Network access
      1. [DONE] B2G (since 1.0)
      2. [NEW] Linux
      3. [DONE] MacOS X
      4. Windows status unknown; FIXME
    4. Others (maybe platform specific)
      1. [NEW] X11 (Linux)
      2. [NEW] SysV SHM (Linux)
  5. Auditing/Hardening (future goals)
    1. Attack surface of MesssageManager protocols
    2. Attack surface of IPDL protocols
    3. CPOWs
    4. Improve understanding of rationale/implications of sandbox policy rules
    5. Where can we rearrange child/parent division to reduce total attack surface?

Status

Firefox OS / B2G

  • [DONE] Android permissions — content processes treated like separate no-permissions Android apps
  • [DONE] seccomp-bpf — syscall filtering for kernel attack surface reduction
  • [IN PROGRESS] chroot — bug 1151632, and depends on filesystem brokering
  • [IN PROGRESS] filesystem brokering
  • [IN PROGRESS] SELinux — bug 1186103
  • [NEW] filesystem whitelist reduction — bug 1121295 tracks all whitelist entries, but some are more feasible targets than others.
  • [NEW] restrict ioctl() — bug needs to be filed; could help with driver attack surface

Desktop Firefox (cross-platform)

  • bug sandbox-fs tracks blockers for restricting filesystem access
  • [IN PROGRESS] printing, bug 1090454; print-to-PDF and similar need file write access
  • Reading files:
    • [NEW] resource URIs, bug 1109293 (also moz-extension://), probably the least difficult of these
    • [NEW] chrome URIs, bug 1136836, more special-case logic than resource:// but basically the same problem
    • [NEW] file URIs: bug 922481 would remote it but we'd need an allow-all policy, which isn't much help; maybe the FirefoxOS/New_security_model isolation machinery can help us compartmentalize file:/// in its own content process.
    • [NEW] NPAPI stuff, because parts of the “plugin host” are in the content process; bug 1202910, but we're sunsetting NPAPI so this may not matter in practice
  • [DONE] camera access, bug 1104616
  • [NEW] audio device access, bug 1104619

Linux Firefox

  • Shares most core code with B2G, but much more difficult to deploy without breaking things.
  • [NEW] apply permissive seccomp-bpf policy, bug 742434, blocked by:
  • [NEW] deal with PulseAudio, which does file/socket I/O on user-configurable paths, chmod()s files, does kill(0) to other processes, etc.. See bug 1104619 above, or maybe there's some way to configure/monkey-patch it into a manageable state that's not just as hard.
  • [NEW] pid namespace isolation, bug 1151624; would be usable immediately for GeckoMediaPlugins, not just for content in the future
  • [NEW] X11 security or lack thereof, bug 1129492
  • [NEW] filesystem/network access restriction, tracked by bug 942698

Windows Firefox

  • [DONE] Land Library bug 922756
  • [DONE] Start using library to sandbox e10s processes unrestricted bug 925571
  • [NEW] List and prioritize permissions to shut off
  • [NEW] Burn down permission list

Permission List:

  • [DONE] Use a separate Windows Desktop within the same Windows Station - bug 928061
  • [ON TRACK] Use a separate Windows Station + Desktop - bug 928055
  • [ON TRACK] Set low integrity on content processes for Windows sandboxing policy - bug 928062
  • more not yet posted

MacOS X Firefox

  • [NEW] Land Library -- bug 387248
  • [NEW] List and prioritize permissions to shut off
  • [NEW] Burn down permission list

Permission List:

TBD

Future work

These are some things that we need to attack next (after a basic sandbox).

  • Process Model
    • Parent process as enforcing + ACL check only?
  • Resource limits
  • (Desktop) DevTools support
  • (Desktop) Accessibility support

Modules

Modules per widget:

  • Windows: Owner: Tim Abraldes; Peers: Bob Owen, Aaron Klotz, Brian Bondy
  • OSX: Owner: Steven Michaud; Peers: Andre Reinald
  • Linux/B2G: Owner: Jed Davis; Peers: Guillaume Destuynder

Contact

See also module owners/peers.

MoCo managers of related groups:

Some folks from the SecurityEngineering team:

  • keeler, ckerschb, sid, and bbondy.

Meeting Notes

Create a new weekly agenda from the template: <createbox> align=left type=create preload=Security/Sandbox/0-0-0 default=2025-06-12 prefix=Security/Sandbox/ </createbox>

2015

2014

Additional resources

Sandboxing

Not up to date/Archived

Related projects

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