Security/Sandbox/Deny Filesystem Access: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
No edit summary
Line 50: Line 50:
|}
|}


== Windows Blockers ==
== Windows-Specific Blockers ==


== OS X Blockers ==
== Mac-Specific Blockers ==
{{bug|1228022}} Trigger print jobs from the parent instead of the child for OSX
{{bug|1228022}} Trigger print jobs from the parent instead of the child for OSX


== Linux Blockers ==
== Linux-Specific Blockers ==
 
== Other Blockers ==

Revision as of 23:48, 18 May 2016

References

Which URI's load where?

Status

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

Blockers

Cross-Platform Blockers

  • bug 1196384 - (sandbox-fs) [meta] Cross-platform blockers for default-deny filesystem policy for content processes
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
  1. 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
  1. For print-to-file (e.g., PDF, postscript).
  2. For printing? (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
  1. Addons can load scripts and resources from the profile directory using chrome:// and resource:// URI's. An add-on calling loadFromScript("chrome://foo/bar") from the Parent process results in Content trying to load that URL.
  2. Content scripts running in the content process may use chrome:// URI's to load supporting code.
  3. Web content can use chrome:// and resource:// URI's.

Another approach is to give the content process read access to the these chrome:// and resource:// files. That would be a place in the profile and also the Firefox install bundle. billm suspects those are safe locations in the profile that don't contain sensitive data.

bug 1109293 Desktop content process resource:// and moz-extension:// URIs should not directly use file:/// Might block how we handle file:// URI's
  1. 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.

Windows-Specific Blockers

Mac-Specific Blockers

bug 1228022 Trigger print jobs from the parent instead of the child for OSX

Linux-Specific Blockers