Security/Sandbox/Deny Filesystem Access: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
(adding misc bugs to track)
(Removed old cruft)
 
(8 intermediate revisions by 3 users 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 || No filesystem policy enabled
|}
 
= 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.
 
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.)
Internal uses:
* [https://bugzilla.mozilla.org/show_bug.cgi?id=922481#c7 Parser, layout, XBL, Js access files using file://] need to be looked over. Most should be associated with loading content. Some may be leveraged by extensions.
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}} [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: <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://wiki.allizom.org/index.php?title=Security/Sandbox/Deny_Filesystem_Access&oldid=1184311"