Changes

In the section below “content process” refers the “Web Content Process” unless otherwise specified.

===File access===

Compromised child process read or modifies user data or systems files. Arbitrary file write is equivalent to arbitrary code execution.

Protect user data and sensitive configuration file in the event of a compromised content process. By default the sandbox should block access to files in the content process, and any necessary exceptions (e.g. reading program files, writing temp file etc) must be mediated by the Chrome process.

On all platforms, access to the filesystem is mediated by a file broker running the Chrome process.

The GMP process has no access to file system at all.

# The file content process is currently allowed to access remote content, and this is likely to remain as conceptually locally hosted webpages may legally request remote resources. A remote attacker able to coerce the browser to initiate the File Content process to load a nested resource such as iframe, would be able to bypass the file read restrictions of the Web Content Sandbox. We need to ensure that this is not possible.

# What is the file access policy for the WebExtension process? Can we increase restrictions of the content process sandbox post-depreciation of old-style addons?

Network architecture is already such that low-level connectivity and security decisions are implemented in the parent process. For detail, see [Necko:_Electrolysis_design_and_subprojects]. This gives us a strong basis to enforce security rules on network traffic.

Attack local system services or connect to resources behind firewalls.

De-anonymise VPN users?

* Direct network access is prohibited in the content process

* All network access is provided through the chrome process

* Global network restrictions (e.g. no connections to low numbered TCP ports) should be enforced in the Chrome process

* Necko is remoted such that all access is performed through the content process

* Access to low ports could & should be restricted? Do we do this already?

* Does all network access go through the parent (via necko)? If not, what connection are directly initiated from the child?

The main consequence of this architecture is that the content process talks to the GPU directly, and subsequently needs access to low-level APIs to facilitate this communication. While there are plans to move compositing from the parent process to a separate GPU process (roughly FF53), the focus of this project is to improve stability and is not expected to meaningfully reduce the privileges required in the child process.

* Plan to move compositor from parent to separate process (roughly FF53)

* Largely would not affect sandboxing efforts, as child still requires access to the GPU. One benefit may be that on Windows, window handles (HWND) would not be required in the child process

* GPU process will benefit linux greatly because it will move the X11 connection to the GPU process (instead of the child)

* Historically graphics system calls have been common privilege escalation path (e.g. GDI on windows)

* Access to X on linux is significant attack service and direct security threat

* Reduce attack surface from content process

* Allow stronger windows sandbox levels by reducing necessary syscalls in content process

* tbd

* Communication with GPU limits the restrictions that can be placed on child process

* Windows: access to GPU prevents the use of the Untrusted integrity level sandbox

===DOM===

* Privilege escalation through implementation bugs

* Broken security model allows sandbox bypass

Dom API have chrome and content components. Need to ensure that security model for DOM APIs respects sandbox (ie all security decisions, permission checks etc must be performed in the parent).

* tbd

* Audit of DOM API IPC underway

===Script Execution===

* JS engine presents the largest attack surface in the browser

Objectives

* All untrusted javascript to be executed in the child

* What JS code is executued in the Chrome process?

* What JS contexts exist?

** Web content

tbd

* Parts of service workers are currently executed in the parent.

=== Web Content (HTML, CSS, XML, SVG) ===

All parsing and execution of untrusted content to be performed in the child

=== Printing & Fonts ===

Played back in the parent

* Strategy is to trigger printing from the parent, not the child.

* How is data passed from child to parent? (shared memory, files? )

=== TLS Stack ===

* Attacking NSS code

* Putting fake certs/creds etc in the trust store

* Direct file access to steal keys e.g. client certs?

* Content process should not be able to modify certificate database (add certs, exceptions etc)

*

* nsISiteSecurityService (security/manager/ssl/nsISiteSecurityService.idl) deals with HPKP/HSTS

** Underlying DataStorage checks to see if we are in the parent process before reading/writing, if in the child, asks parent to read/write, so for this we should be able to exclude the HPKP/HSTS database from read/write in child. Child needs to do this in order to alter entries based on headers.

Note: sandbox can not restrict access to web crypto (child can load any origin, so can load any origin’s data)

* Is PSM remoted securely? How are certificate exceptions handled?

* Check where the following:

=== DevTools ===

* What is the process model?

* What is in parent vs child?

=== WebRTC===

* Unauthorized camera and microphone access

* Eavesdropping on existing connections

* Raw socket connections

Camera/Microphone

* Requests for camera and microphone mediated by the Chrome process

Network Connectivity

Camera/Microphone

https://bugzilla.mozilla.org/show_bug.cgi?id=1177242

* What other threats exist with WebRTC and the sandbox

** Socket Connectivity

===Media Playback===

* Mainly just attack surface for priv esc?

* Support media playback while minimizing attack surface

* Remote audio to the parent to minimise syscalls necessary in the child (allowing tighter sandbox restrictions)

* Linux?

* Libcubeb - Audio interfacehttps://dxr.mozilla.org/mozilla-central/source/media/libcubeb/src/cubeb-internal.h#14

=== Firefox Preferences ===

* Ability to change arbitrary preferences is equivalent to code execution

* Restrict access to preferences in the content process to an absolute minimum

* Whitelist of prefs which child can write to

* Can only simple prefs

* Actual prefs live in parent

=== Printing ===

* System calls involved in printing is historically dangerous attack surface for kernel privilege escalation

Objectives

* Remote access to the parent to minimize access to the parent

Printing pages are remoted to the parent: the content process serializes the document to the parent which interprets it.

=== Other things: Places, History & Bookmarks etc? ===

* Implementation of the remoting of this functionality presents privilege escalation attack surfce

* Read bookmarks in content process

* Content process should not be able to read bookmarks?

* We can’t restrict access to history since this is needed to display web content?

* Ensure security model for these components are safe

tbd

* What other things fall into the same category (is there a better name for this?)