|
|
| (32 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?]
| |
|
| |
| = 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
| |
| | |
| Another approach to this is to open file:// URI's in the chrome process.
| |
| | |
| If a content process that has read or write access to a local file (even indirectly through the parent) shouldn't also be used for web content, it follows that more than one content process would be needed. See {{bug|1147911}} Use a separate content process for file:// URLs.
| |
| | |
| 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.)
| |
| |-
| |
| | {{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).
| |
| # For printing? (I don't understand the details of why printing requires writing to filesystem). | |
| |-
| |
| | {{bug|1136836}} Load chrome: URLs through parent process || Blocks disabling read access to $HOME ||
| |
| # Addons can load scripts and resources from the profile directory using chrome:// and resource:// URI's. An add-on calling 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.
| |
| | |
| Another approach is to give the content process read access to the these chrome:// and resource:// files. That would be a place in the profile and also the Firefox install bundle. billm suspects those are safe locations in the profile that don't contain sensitive data.
| |
| |-
| |
| | {{bug|1109293}} Desktop content process resource:// and moz-extension:// URIs should not directly use file:/// || Might block how we handle file:// URI's ||
| |
| # The content process is using resource:// and moz-extension:// URI's that resolve to file:// URI's, but we want to treat these URI's differently compared to file:// URI's.
| |
| |} | | |} |
|
| |
| == Windows-Specific Blockers ==
| |
|
| |
| == Mac-Specific Blockers ==
| |
| {{bug|1228022}} Trigger print jobs from the parent instead of the child for OSX
| |
|
| |
| == Linux-Specific Blockers ==
| |