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 |
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 |
The sandbox on each platform will restricts read access to some areas.
Sync file access from content:
User content navigation:
Extensions:
|
bug 1147911 Use a separate content process for file:// URLs | Isolate local user content in its own content process |
|
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 |
Notes:
|
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 |
|
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.
|
bug 1221148 Mac Nightly with e10s on cannot open some files |
|
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.
- (FIXED) bug 1288774 filed to remove this rule