Security/Sandbox/Deny Filesystem Access

From MozillaWiki
Jump to: navigation, search

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

Level 2: Read allowed. Write allowed in /dev/shm and /tmp (TMPDIR).

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:

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

bug 1221148 Make blob URLs work with mozIJSSubScriptLoader (and anything else that wants a file:///)

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.