Security/Sandbox/Deny Filesystem Access

From MozillaWiki
< Security‎ | Sandbox
Revision as of 15:24, 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
bug 1109293 Desktop content process resource:// and moz-extension:// URIs should not directly use file:///		 Might block how we handle file:// URI's
  1. Extensions load scripts and resources from the profile directory using chrome://, resource://, moz-extension:// URI's.
  2. Extensions call loadFromScript("chrome://foo/bar") from the Parent process results in Content trying to load that URL.
  3. Content scripts running in the content process may use chrome:// URI's to load supporting code.
  4. Web content can use chrome:// and resource:// URI's.
  5. Firefox may use chrome://, resource://, moz-extension:// URI's internally from the content process.

Notes:

  • 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
  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 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=1142052"