Security/Sandbox/Process model: Difference between revisions

Jump to navigation Jump to search

Security/Sandbox/Process model (view source)

Revision as of 04:04, 2 May 2019

428 bytes added ,  2 May 2019
no edit summary
(provide link to GPU sandbox bug)
No edit summary
Line 7: Line 7:
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).
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 Content Processes ==
These processes are instances of firefox.exe with the -content-proc flag set.
 
===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.  
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.  


Line 19: Line 22:
* No access to dangerous APIs &  syscalls which could compromise system integrity  
* No access to dangerous APIs &  syscalls which could compromise system integrity  
* Mediated access to system resources
* Mediated access to system resources
=== 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).  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.


=== Flash Sandboxing (Windows 64-bit & OSX) ===
=== Flash Sandboxing (Windows 64-bit & OSX) ===
Line 59: Line 43:
=== WebExtension Process ===
=== 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.
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.
== Plugin Content Process ==
These processes are instances of plugin-container.exe
=== Flash Plugin process ===
On Windows 64, Flash does not provide its own sandbox, so Firefox provides one. This process only exists while flash content is loaded.
=== 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 ==
== Future Work ==
Ptheriault
canmove, Confirmed users
1,220

edits

Retrieved from "https://wiki.allizom.org/Special:MobileDiff/1211579"

Navigation menu