202
edits
Security/Sandbox/Deny Filesystem Access: Difference between revisions
Jump to navigation
Jump to search
Security/Sandbox/Deny Filesystem Access (view source)
Revision as of 23:45, 18 May 2016
, 18 May 2016→Cross-Platform Blockers
Haftandilian (talk | contribs) |
Haftandilian (talk | contribs) |
||
| Line 28: | Line 28: | ||
! Bug !! What does it block? !! Why do we need it? | ! 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. | | {{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. | Another approach to this is to open file:// URI's in the chrome process. | ||
| Line 34: | Line 35: | ||
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. So it follows that more than one content process would be needed. | 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. So it follows that more than one content process would be needed. | ||
|- | |- | ||
| {{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 || | | {{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. | | {{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. | # 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. | |||
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. | 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 || | | {{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. | # 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. | ||
|} | |} | ||