Security/Sandbox/Deny Filesystem Access
- Which URI's load where?
- Frame scripts loading and lifetime
- Limitations of frame scripts ("Do not use fileio" notes)
|Platform||Current Status of Content Filesystem Sandboxing on Nightly|
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.
Level 2: Read allowed. Write allowed in /dev/shm and /tmp (TMPDIR).
- 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:
|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||
|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:///)
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
- (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.
- (OPEN) bug 1284458 nsPluginHost::GetPluginTempDir should return a sandbox writeable temp (Linux)
- Currently not an issue since we do not restrict file access
- (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