Security/Sandbox

From MozillaWiki
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
Simulate the absence of seccomp-bpf support MOZ_FAKE_NO_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

Roadmap (high-level)

This roadmap may evolve over time.

  1. Land sandbox implementation for all platforms with not-very-restrictive-whitelist
    1. [DONE] B2G
    2. [DONE] Windows
    3. [DONE] Linux
    4. [NEW] MacOS X
    5. [NEW] Fennec (inactive)
  2. (Desktop) Help e10s Electrolysis
    1. FIXME
  3. Documentation efforts
    1. Sandbox implementations
      1. [ON TRACK] B2G
      2. [NEW] Windows
      3. {ok|Linux}}
      4. [NEW] MacOS X (inactive)
      5. [NEW] Fennec (inactive)
    2. Remoting
      1. [ON TRACK] Security/B2G/FirefoxOSCommsHardening
  4. Tighten Sandbox
    1. Harden IPC
      1. Audit message manager protocols
      2. Audit IPDL protocols
    2. Reduce whitelist by fixing & remoting APIs
      1. Stage 1: No FS access, no process creation or no additional rights in child processes.
      2. Stage 2: Achieve strong whitelist: no direct resource access
    3. Harden APIs
      1. Review APIs for dangerous behavior
      2. Focus on sensitive/complex APIs
  5. Future Work
    1. Migrate processing to child reduce parent attack surface
    2. Maintain sandbox (e.g. file whitelist, performance etc)

Status

Firefox OS / B2G

Firefox OS 1.2

Firefox OS 1.4

Firefox OS 2.0

Dependencies (see bug 968608 for details):

Full Query
ID Summary Status
907006 seccomp-bpf doesn't fully kill processes with our kernel 3.0 backport RESOLVED
920372 Improve seccomp whitelist: use parameters where possible/reasonable RESOLVED
946407 Electrolyze memory report file writing (but not GC logs, yet) and work around DMD/sandbox conflict RESOLVED
973090 Electrolyze GC/CC log writing. RESOLVED
997469 Enable seccomp-bpf on emulator-x86-kk RESOLVED

5 Total; 0 Open (0%); 5 Resolved (100%); 0 Verified (0%);


NeedABug

  • [NEW] enable build/test devices (tbpl) to test with sandboxing


Permissions burndown

See seccomp_filter.h for current list. Note: More syscalls could be removed as some of them, while not a direct security issue, may lead to access to a kernel bug, for example, see do_brk()'s CVE-2003-0961)

Stage 1: File system access

To remove file system access and other syscalls of similar severity.

fstat64(), stat64(), lstat(), access() Med Information leak. Tells the process if a file/path exists, and its attributes (inode, etc. See man fstat64)
getdents(), getdents64() Med Information leak. Lists directories.
open() High FS access: Open files.
unlink() High FS access: Delete files.
socketpair() Med
readlink() Low File system access
fsync(), msync() Med Potential file system access
Stage 2: Remove resource access and reduce attack surface

To remove for achieving a "good whitelist". These syscalls are ones which are a lower priority due to being lower value to an attacker and/or more complicated to remove.

ioctl() High Mainly used for GL/Graphics. To be removed or/and argument-filtered, see bug 920372
sigprocmask() Med Change signals. We don't want signals to be rerouted in general.
prctl() Med Change process attributes, including security relevant bits. Note: when removed, this means no child process can tighten it's whitelist further either.
getpriority(), setpriority(), sched_get_priority_min, sched_get_priority_max Med Access priority attributes from target processes.
sched_setscheduler() Med Change scheduling policy/params of target processes.
sigprocmask(), rt_sigprocmask(), sigaltstack() Med control over signals
tgkill() med Already filtered so that its own process only, but should probably be removed. (more of an issue on desktop)
sendto(), recvfrom() med Arbitrary socket read/write. Sockets should be controlled but this is defense-in-depth.
epoll(), sched_yield(), sched_getscheduler(), sched_getscheduler() low Low defense-in-depth in depth changes
Stage 3: Future work

Sandboxing is an ongoing project, and it is likely that some syscalls will not be able to be blocked in previous stages. Future work include continuing to work on:

  • removing any remaining syscalls from previous stages,
  • Maintaining the the open whitelist.

Linux Firefox

  • [DONE] Land Library bug 742434
  • [ON TRACK] Enable sandbox

Permissions burndown

Permission burn down list (see bug 942695 for details):

Full Query
ID Summary Status
742434 Enable seccomp-bpf for nightly desktop Firefox content processes on Linux RESOLVED
936274 Remove open() from seccomp-bpf whitelist for Linux/Desktop RESOLVED
942696 Remove access() from seccomp-bpf whitelist for Linux/Desktop RESOLVED
942698 Remove syscalls operating on filesystem paths and network addresses from seccomp-bpf whitelist for Linux/Desktop RESOLVED

4 Total; 0 Open (0%); 4 Resolved (100%); 0 Verified (0%);


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

Some folks from the SecurityEngineering team:

  • briansmith, keeler, grobinson, ckerschb, sid, and bbondy.

Some folks from the Firefox OS Security team:

  • pauljt and kang.


Additional resources

Sandboxing

Not up to date/Archived

Related projects

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