Security/Sandbox/Deny Filesystem Access

From MozillaWiki
< Security‎ | Sandbox
Revision as of 15:12, 1 August 2016 by Jmathies (talk | contribs) (edits)
Jump to navigation Jump to search

References

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.

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:

Extensions:

  • Access to profile resources need to be restricted. This may break some extensions.
bug 1136836 Load chrome: URLs through parent process Blocks disabling read access to parts of the profile dir
  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 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. 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 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.
bug 1187099 User stylesheets loaded from a file inside ~/Library don't apply in the content process TBD TBD

Windows-Specific Blockers

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

Linux-Specific Blockers

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.
Retrieved from "https://wiki.allizom.org/index.php?title=Security/Sandbox/Deny_Filesystem_Access&oldid=1142050"