Revision as of 23:23, 16 May 2016

Status

Platform	Current Status of Content Filesystem Sandboxing
Windows	TBD
OS X	Some directories are read/write protected, but this will not provide real security until the bulk of the $HOME directory is fully write protected. On OS X, the Firefox Profile directory is stored within ~/Library/Application Support/Firefox/Profiles/. ~/Library is read/write protected with a few exceptions for some specific subdirectories. Access to $HOME and other areas of the filesystem is not restricted. i.e., the content process can read and write to/from anywhere the OS permits: $HOME and temporary directories. The ~/Library read/write prevention could be bypassed because the rest of the $HOME is read/write accessible. For example, a compromised process could add malicious commands to ~/.login-type files to copy data from ~/Library when a user logs in.
Linux	No filesystem policy enabled
Other	No filesystem policy enabled

bug 1196384 - (sandbox-fs) [meta] Cross-platform blockers for default-deny filesystem policy for content processes
- Dependency Tree

Bug	What does it block?	Why do we need it?
bug 922481 e10s: remote the file:// protocol	Blocks disabling read access to $HOME and other locations	A compromised content process shouldn't be able to read arbitrary files, but when the user does File->Open or uses a file:/// URL, that must continue to work.
bug 1136836 Load chrome: URLs through parent process	Blocks disabling read access to $HOME	Addons can load scripts and resources from the profile directory using chrome: and resource: URL's. Example, an add-on calling loadFromScript("chrome://foo/bar") from the Parent process results in Content trying to load that URL.

@@ Line 21: / Line 21: @@
 * {{bug|1196384}} - (sandbox-fs) [meta] Cross-platform blockers for default-deny filesystem policy for content processes
 ** [https://bugzilla.mozilla.org/showdependencytree.cgi?id=1196384&hide_resolved=1 Dependency Tree]
+{| class="wikitable"
+|-
+! Bug !! What does it block? || Why do we need it?
+|-
+| {{bug|922481}} e10s: remote the file:// protocol || Blocks disabling read access to $HOME and other locations || A compromised content process shouldn't be able to read arbitrary files, but when the user does File->Open or uses a file:/// URL, that must continue to work.
+|-
+| {{bug|1136836}} Load chrome: URLs through parent process || Blocks disabling read access to $HOME || Addons can load scripts and resources from the profile directory using chrome: and resource: URL's. Example, an add-on calling loadFromScript("chrome://foo/bar") from the Parent process results in Content trying to load that URL.
+|}
 == Windows Blockers ==