Security/Sandbox/Process model: Difference between revisions

= 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 [https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Multiprocess_Firefox 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.

=== 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).

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.  

* No access to dangerous APIs &  syscalls which could compromise system integrity  

* Mediated access to system resources

=== GMP process (Widevine, Primetime, OpenH264) ===

* 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.

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 ==