Security/Sandbox/Deny Filesystem Access

References

• Which URI's load where?
• Frame scripts loading and lifetime
• Limitations of frame scripts ("Do not use fileio" notes)

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. The sandbox on each platform will restricts read access to some areas. Windows: Level 2 access removes user's SID, removing access to various User resources (including the profile directory). System file access (Program Files, Windows system folder) still allowed for proper operation of binaries. OSX Filter rules restrict access to various areas of the system and $HOME Linux: File broker will manage read access to various areas of the system. User content navigation: We plan to have a separate content process that will handle accessing local content. (bug 1147911) Question: 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.) Internal uses: Parser, layout, XBL, Js access files using file:// need to be looked over. Most should be associated with loading content. Some may be leveraged by extensions. Extensions: Access to profile resources need to be restricted. This may break some extensions.
bug 1136836 Load chrome: URLs through parent process bug 1109293 Desktop content process resource:// and moz-extension:// URIs should not directly use file:///	Might block how we handle file:// URI's	Extensions load scripts and resources from the profile directory using chrome://, resource://, moz-extension:// URI's. Extensions call 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. Firefox may use chrome://, resource://, moz-extension:// URI's internally from the content process. Notes: resource: URLs Aliased mappings to chrome uris can be accessed via frame scripts moz-extension: URLs new scheme related to webextensions For chrome://, resource://, and moz-extension:// URI's accessible files are defined by registrations performed in the parent process and can be filtered. Question: Can extensions be installed outside the profile 'extensions' directory? Question: Do these methods of access all rely on our file:/// URLs handling?
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 1187099 User stylesheets loaded from a file inside ~/Library don't apply in the content process	Issue loading stylesheets via nsIStyleSheetService	This can be address via moz-extension, resource, or chrome URLs. Q: working on mac? (Bug 1187099) Does not work with file:// URLs, which is expected. Should we reject file urls here in the content process? What type of response do we give as a result? (file a bug)

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