|
|
| (20 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 || TBD | | | Windows/Mac/Linux || |
| |-
| | Read and write filesystem access restrictions are now shipping on all platforms. See |
| | 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.
| | [[Security/Sandbox#Current Status|the main sandboxing wiki page]] for more information. |
| | |
| 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
| |
| |-
| |
| | Other || No filesystem policy enabled
| |
| |}
| |
| | |
| = Blockers =
| |
| | |
| == Cross-Platform Blockers ==
| |
| * {{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.
| |
| | |
| |-
| |
| | {{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 || 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.
| |
| * Q: working on mac? (Bug 1187099)
| |
| * Does not work with file:// URLs, which is expected.
| |
| * Should we reject file urls here in the content process? What type of response do we give as a result? (file a bug)
| |
| | |
| |} | | |} |
|
| |
| == Windows-Specific Blockers ==
| |
|
| |
| == Mac-Specific Blockers ==
| |
| # {{bug|1228022}} Trigger print jobs from the parent instead of the child for OSX
| |
| # {{bug|1187099}} User stylesheets loaded from a file inside ~/Library don't apply in the content process
| |
|
| |
| == Linux-Specific Blockers ==
| |
|
| |
| = 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.
| |
| *** (OPEN) {{bug|1288774}} filed to remove this rule
| |