Sandbox Architecture

Multi-process Firefox employs a process sandbox to protect against malicious content. In this model, untrusted content is run in a sandboxed low-rights process so that in the event of a compromise, access to full system functionality and data is prevented by a sandbox. This document aims to provide an overview of the sandbox implementation and outline the design implications for Gecko features.

Process Model

For sandboxing to be an effective security control, Firefox must be split into parent and child processes, such that the child processes responsible for running untrusted content can be restricted to limit damage in the event of compromise. The Electrolysis project enabled moving parsing and execution of web content to a content process - and sandboxing is based off this process model. In general a child process is untrusted, and intended to run remote content. It’s sandbox is restricts privileges and prevents access to all but necessary system resources. The main focus of the sandbox project are child processes called "Web Content processes" - processes which parse and execute web content. However Firefox currently also makes use of several other types of sandboxed child process, and more are planned for future improvement.

Chrome process

The Chrome (or “parent”) process - named for where the browser’s “chrome” or UI is run - is the trusted process which controls interaction with the underlying operating system. The parent process is not sandboxed and has regular access to operating system in order to access files, devices and network resources as part of regular browser use. As such should only ever run trusted code - all untrusted web content should be processed in a child process. The parent also acts as a broker for privileged resource requests from the child.

Web Content Process

Firefox uses one content process to render all browser tabs. This web content process is responsible for parsing and executing all the web content currently loaded in the browser tabs that are open. As well as web pages, content processes contain privileged code responsible for the implementation of DOM APIs, and code which connects back up to parent to load resources. Content process are sandboxed, and prevented from direct resource access, with the goal being that they only have the ability to execute web content. The level of sandbox restrictions varies per platform, and is an ongoing project. But in general goal of restrictions are:

• All file system access is mediated by the Chrome process. In general, no access to the file system is allowed with the following general exceptions:
  • read-only access to essential Firefox program files (e.g. JSMs, libs etc)
  • meditiated access to create temp files
  • The exact list varies per platform, see the annotated rule set as an example.
• file:// protocol loads are to be restricted in the Web Content process once the separate File Content Process bug is landed
• No privileges to load and execute new processes
• No access to dangerous APIs & syscalls which could compromise system integrity
• Mediated access to system resources

GMP process (Widevine, Primetime, OpenH264)

Firefox includes a sandbox to isolate third-party binaries used for media playback. Media plugins differ from content in some important ways:

• The processing they do is relatively self-contained, so sandboxing policies can be much more restrictive.
• Sandboxing to protect the user’s privacy was an integral part of the media plugin feature from when it was first announced; as a result design decisions have generally been made with sandboxing in mind.
• Sandboxing is not optional; if we can’t support an effective sandbox on a given OS version then we don’t support GMP on that OS version.
• For CDMs, the plugin file itself is considered untrusted, not just its input. This means that sandboxing must be started before the plugin is processed by the system’s module loader (e.g., before dlopen() is called).

Our GMP sandbox allows a very specific set of privileges. For example, on Linux only the following is allowed (Windows is less specific but similarly restrictive):

• Reading/writing from/to file descriptors the process has
• Sending/receiving file descriptors to/from the parent process
• Managing the process’s own threads, including creating new threads
• Reading the current time and setting timers
• Notable features which are blocked by the GMP sandbox include:
• Any filesystem access other than as above (e.g., opening files, creating/deleting files, accessing named Unix-domain sockets or similar)
• Any direct network access
• Any direct interaction with other processes, other than the IPC channel established by the parent (e.g., signals or debugging/tracing)
• Creating new processes
• Any system calls not necessary for a media plugin’s normal operation (Linux specific)

Ideally, we aim to restrict the interface that could yield PII (e.g., MAC addresses or other hardware identifiers) should be disallowed, but this hasn’t yet been audited.

NPAPI process (64-bit windows only)

On Windows 64-bit Firefox employs a sandbox to limit the impact of compromised plug-ins. This sandbox landed in Firefox 41 and tightened but at a high level it aims to limit access to the file system and other system privileges. For further detail see the https://wiki.mozilla.org/Security/Sandbox#64-bit_Plugin and https://wiki.mozilla.org/Firefox/win64

Future Process Types

File Content Process

Priority for multiprocess Firefox is separating pages loaded from “file://” page loads in order to support more tightly restricting read access from the content process. Without this change, the Web Content process would need read access to arbitrary file:// URIs in order to support loading HTML pages from file://. The goal of this process is to handle all file:// page loads, so that Web Content Processes can have file access more tightly restricted.

One thing to note about this process is that it not prohibited from loading remote web content, as this is currently not prohibited on file loads.

Multiple Content Processes

In the future multiple content process will be supported which will allow to more segregation. Support for for granularity of sandboxing (e.g. sandboxing per tab, or sandbox per origin etc) requires support for multiple content processes.

Compositor Process

There is currently an ongoing project in the graphics team to move the compositor from the parent process to a separate process (roughly FF53). Currently child processes allocate shared memory for texture data, write to it, and then pass it to the compositor in the Chrome process via IPC. In the new compositor model, the compositor doesn’t need to manage shared memory, but it would be able to keep track of allocations per process and kill child processes using too much memory. In general moving this code will not have a material impact on security posture:

• The child process will still require access to the GPU
• On Windows, window handles (HWND) are expected to no longer be required in the child process
• On Linux, the GPU process will be a significant improvement since the X11 connection will be handled by the GPU process (instead of the child)
• The GPU process is not currently planned to be sandboxed, however this might be a future improvement