Revision as of 22:59, 18 May 2016

References

Platform	Current Status of Content Filesystem Sandboxing on Nightly
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 read/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:/// URI, that must continue to work. Another approach to this is to open file:// URI's in the chrome process. A content process that has read or write access to a local file (even indirectly through the parent), shouldn't also be used for web content. So it follows that more than one content process would be needed.
bug 1090454 Trigger print jobs from the parent instead of the child when printing from a remote browser	Blocks disabling write access to $HOME and other locations	TBD. For printing and print-to-file. (TBD, because I don't understand the details of why printing requires writing to filesystem).
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. An add-on calling loadFromScript("chrome://foo/bar") from the Parent process results in Content trying to load that URL.
bug 1109293 Desktop content process resource:// and moz-extension:// URIs should not directly use file:///	Might block how we handle file:// URI's	The content process is using resource:// and moz-extension:// URI's that resolve to file:// URI's, but we want to treat these URI's differently compared to file:// URI's.

@@ Line 26: / Line 26: @@
 {| class="wikitable"
 |-
-! Bug !! What does it block? || Why do we need it?
+! 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|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:/// URI, that must continue to work.
+Another approach to this is to open file:// URI's in the chrome process.
+A content process that has read or write access to a local file (even indirectly through the parent), shouldn't also be used for web content. So it follows that more than one content process would be needed.
 |-
 | {{bug|1090454}} Trigger print jobs from the parent instead of the child when printing from a remote browser || Blocks disabling write access to $HOME and other locations || TBD. For printing and print-to-file. (TBD, because I don't understand the details of why printing requires writing to filesystem).