Security/Sandbox/Deny Filesystem Access: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
(Update Linux status.)
(Removed old cruft)
 
(3 intermediate revisions by the same user not shown)
Line 1: Line 1:
= References =
* [https://developer.mozilla.org/en-US/Firefox/Multiprocess_Firefox/Which_URIs_load_where Which URI's load where?]
* [https://developer.mozilla.org/en-US/Firefox/Multiprocess_Firefox/Message_Manager/Frame_script_loading_and_lifetime Frame scripts loading and lifetime]
* [https://developer.mozilla.org/en-US/Firefox/Multiprocess_Firefox/Limitations_of_frame_scripts Limitations of frame scripts ("Do not use fileio" notes)]
= Status =
= Status =
{| class="wikitable"
{| class="wikitable"
|-
|-
! Platform !! Current Status of Content Filesystem Sandboxing on Nightly
! Platform !! Current Status of Content Filesystem Sandboxing
|-
|-
| Windows ||
| Windows/Mac/Linux ||
Level 1: Low integrity restricts write access
Read and write filesystem access restrictions are now shipping on all platforms. See
Level 2: Adds restrictions to read access
[[Security/Sandbox#Current Status|the main sandboxing wiki page]] for more information.
|-
| 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
** [https://bugzilla.mozilla.org/showdependencytree.cgi?id=1196384&hide_resolved=1 Dependency Tree]
 
{| class="wikitable"
|-
! 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 ||
# 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:
* [https://bugzilla.mozilla.org/show_bug.cgi?id=922481#c7 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<br/><br/>{{bug|1109293}} Desktop content process resource:// and moz-extension:// URIs should not directly use file:/// || Might block how we handle file:// URI's ||
 
# Extensions load scripts and resources from the profile directory using chrome://, resource://, moz-extension:// URI's.
# Extensions call loadFromScript("chrome://foo/bar") from the Parent process results in Content trying to load that URL.
# Content scripts running in the content process may use chrome:// URI's to load supporting code.
# Web content can use chrome:// and resource:// URI's.
# Firefox may use chrome://, resource://, moz-extension:// URI's internally from the content process.
 
Notes:
* resource: URLs
** [https://developer.mozilla.org/en-US/docs/Chrome_Registration#resource Aliased mappings to chrome uris]
** can be accessed via frame scripts
* 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 ||
# For print-to-file (e.g., PDF, postscript).
# 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: <strong>This should always be accomplished through the parent process</strong>
** 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.
** [http://searchfox.org/mozilla-central/rev/496904277ce0143bc1a952f2eb2c7e6a81aa3d4d/dom/plugins/base/nsPluginHost.cpp#784 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

Latest revision as of 17:22, 16 November 2017

Status

Platform Current Status of Content Filesystem Sandboxing
Windows/Mac/Linux

Read and write filesystem access restrictions are now shipping on all platforms. See the main sandboxing wiki page for more information.

Retrieved from "https://dev.wikimo.nonprod.webservices.mozgcp.net/index.php?title=Security/Sandbox/Deny_Filesystem_Access&oldid=1184311"