MozillaWiki

Security/Sandbox/Deny Filesystem Access

< Security‎ | Sandbox
Revision as of 13:55, 4 August 2016 by Jmathies (talk | contribs) (edits)

References

Status

Platform Current Status of Content Filesystem Sandboxing on Nightly
Windows

Level 1: Low integrity restricts write access Level 2: Adds restrictions to read access

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

Open Issues

  • 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.

Sync file access from content: Parser, layout, XBL, Js access files using file:// need to be researched. Most should be associated with loading content. Some of this code may be leveraged by extensions. Most of these are sync in nature, and some leverage the nsIFile interface.

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.)

Extensions:

  • Access to profile resources need to be restricted. This may break some extensions. We should file bugs on individual issues.
bug 1147911 Use a separate content process for file:// URLs Isolate local user content in its own content process
  • More open file access security restrictions
  • e10s-multi dependent
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:

  • resource: URLs
  • 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 OSX specific: 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 Issue loading stylesheets via nsIStyleSheetService

This can be address via moz-extension, resource, or chrome URLs.

  • nsIStyleSheetService does not work with file:// URLs with read restricted sandbox, which is expected.
  • Should we reject file urls here in the content process? What type of error response do we give as a result?
bug 1221148 Mac Nightly with e10s on cannot open some files
  • Originally a dupe of bug 1187099
  • Jed commented that this could be used to fix Blob URL issues in the content process.

Misc. Bugs to Track

bug 1046166 [e10s] userContent.css doesn't work

  • Looks like the current solution here is to pass a file:// url pointing to the location into the content process for loading.

Extension Notes

bug 1288874 - Decide on our story for file access from add-ons, post-sandboxing

  • Traditional XUL and sdk extensions will never run in a separate process (bug 1136407)
  • Legacy extensions do a majority of their file access in the parent
  • Frame scripts are currently loaded by the content process directly
  • Extension write access issues?
    • Consensus is: This should always be accomplished through the parent process
    • Question: Are there extensions that try to do this from content that we'll break?
    • Question: Other areas content process frame scripts might try to write to?
    • Write to areas like $PROFILE/chrome/userContent.css
    • Extension directories that get created in the root profile directory:
      • $PROFILE/extension-data/* (uMatrix)
      • $PROFILE/adblockplus/* (AdBlockPlus)
      • …

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=1142673"