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 is 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. Each child process has a sandbox that 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. Below is a description of various processes used in Firefox.

The type of content processes is defined in GeckoProcessTypes.h:

• Default: The main Firefox process which runs without a sandbox at full user privileges
• Plugin: Used for running flash content on some platforms
• Content: Used to run web content of various types. There are different remote types of content process (defined here) including the following sub-types:
  • Web Content Processes: used for loading remote web content
  • File Content Process : used for loading web content hosted on file:// URIs
  • Privileged Content process: loads privileged content
  • Web Extension Content Process
• IPDLUnitTest
• GMPlugin : for loading DRM media in a highly sandboxed process
• GPU (or Compositor) process: does compositing and talks to GPU hardware
• VR: process which talks to VR hardware
• RDD: Remote Data Decoder process is used to decode media in a seperate process
• Socket: used for loading network data
• RemoteSandboxBroker: part of the Chromium sandbox mechanism (? TBC)

Chrome process (Parent)

The Chrome (or "parent", "main" or "master) process - is 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, this process should only ever run trusted code - all untrusted web content should be processed in a child process. The parent acts as a broker for privileged resource requests from the various child processes, mediating access to os resources - the checks which the parent applies prior to granting access to a resource are a critical part of the sandbox model (otherwise the child could ask the parent for a sensitive resource and bypass any sandbox restrictions).

Web Content Processes

Firefox uses multiple content processes to render the web content loaded in the browser's tabs. Web Content processes are responsible for parsing and executing all the web content. 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.

Web Content processes are sandboxed, and prevented from direct OS access, with the goal being that they have the minimal set of privileges required to execute web content. 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 not permitted (see the file:// process below)
• No privileges to load and execute new processes
• No access to dangerous APIs & syscalls which could compromise system integrity
• Mediated access to system resources

File (File://) Content Process

Firefox is separates pages loaded from “file://” page loads in order to support more tightly restricting read access from regular web content processes. Since file:// page loads are forbidden from web content, this allows Firefox to prevents regular web content processes from accessing the local filesystem directly.

Note that the reverse is not forbidden: content loaded from file:// is permitted to load remote web content.

GPU Process

Todo. Not sandboxed currently Only present on windows, but will likely be added to OSx and linux with Web Render. Implemented in bug 1347710 but waiting on VR process work.

WebExtension Process

This is similar to the web content process, except that the content that is run here is the background pages of Web Extensions. The sandbox restrictions are the same as for Web Content, but there are many more APIs exposed to this process, to allow for Web Extensions to function.

Privileged Content Process

about:newtab is loaded in a separate content process.

Remote Data Decoder (RDD)

Several media decoders are in their own process. Initially for AV1, eventually for other things. This process has a strict sandbox, probably similar to GMP - see bug 1498624 for details.

VR Process

A process is planned that runs VR services, and planned (in bug 1430043) to sandbox this process.

Plugin Content Process

These processes are instances of plugin-container.exe

Flash Sandboxing (Windows 64-bit & OSX)

Firefox runs Flash content in a separate process (plugin-container.exe) for stability and security reasons. Firefox 64-bit on Window (since Firefox 41) and OSX (since Firefox 62) both employ a sandbox to mitigate the risk of malicious flash content. At a high level this sandbox aims to limit access to the file system and other system privileges. For further detail see

• Windows: Security/Sandbox#64-bit_Plugin and Firefox/win64
• OSX: Security/Sandbox#NPAPI_Flash_Process

GMP process (Widevine, Primetime, OpenH264)

Firefox includes a sandbox to isolate third-party binaries used for media playback (known as "Content Decryption Modules" or CDMs). This process only exists while DRM enabled content is loaded.

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.

Future Work