Security/Sandbox/Deny Filesystem Access

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
  • 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. If 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, it follows that more than one content process would be needed. See bug 1147911 Use a separate content process for file:// URLs. If file:// access is remoted to the parent, could the contents of the URL bar be used to determine the allowable scope and accept/reject files as necessary? (Discussed previously by :billm, :bobowen.)
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	For print-to-file (e.g., PDF, postscript). Printing to a printer seems to work with write access to $HOME disabled. Without using print_via_parent, using dtrace I saw plugin-container read from ~/.cups/client.conf and write to the content process temp dir ~/Library/Caches/TemporaryItems/Temp-{UUID}.
bug 1136836 Load chrome: URLs through parent process	Blocks disabling read access to parts of the profile dir	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. Content scripts running in the content process may use chrome:// URI's to load supporting code. 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	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.
bug 1187099 User stylesheets loaded from a file inside ~/Library don't apply in the content process	TBD	TBD

Mac-Specific Blockers

1. bug 1228022 Trigger print jobs from the parent instead of the child for OSX
2. bug 1187099 User stylesheets loaded from a file inside ~/Library don't apply in the content process

Plugin File Access

General

• (FIXED) bug 1270018 Create NS_APP_CONTENT_PROCESS_TEMP_DIR
  • Re-routes NS_OS_TEMP_DIR in the content process to a sandbox safe temp directory.
  • Cleans up the directory on every restart.
  • nsPluginHost::GetPluginTempDir uses NS_APP_CONTENT_PROCESS_TEMP_DIR through NS_OS_TEMP_DIR.

Linux

• (OPEN) bug 1284458 nsPluginHost::GetPluginTempDir should return a sandbox writeable temp (Linux)
  • Currently not an issue since we do not restrict file access

OSX

• (FIXED) bug 1190032 Sandbox failure in nsPluginHost::GetPluginTempDir (OSX)
  • Older bug that opened file access and new sub dir for GetPluginTempDir on OSX
  • This rule is now obsolete, superseded by the rule that allows access to NS_APP_CONTENT_PROCESS_TEMP_DIR.
    • (OPEN) bug 1288774 filed to remove this rule