Security/Sandbox/Deny Filesystem Access: Difference between revisions

Jump to navigation Jump to search

Security/Sandbox/Deny Filesystem Access (view source)

Revision as of 15:24, 1 August 2016

65 bytes removed ,  1 August 2016
edits
(edits)
(edits)
Line 47: Line 47:


|-
|-
| {{bug|1136836}} Load chrome: URLs through parent process || Blocks disabling read access to parts of the profile dir ||
| {{bug|1136836}} Load chrome: URLs through parent process<br>{{bug|1109293}} Desktop content process resource:// and moz-extension:// URIs should not directly use file:/// || Might block how we handle file:// URI's ||
# 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.
 
# 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.
# 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.
# Firefox may use chrome://, resource://, moz-extension:// URI's internally from the content process.


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.
Notes:
* 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?


|-
|-
Line 58: Line 64:
# For print-to-file (e.g., PDF, postscript).
# 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}.
# 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|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.
|-
|-
| {{bug|1187099}} User stylesheets loaded from a file inside ~/Library don't apply in the content process || TBD || TBD
| {{bug|1187099}} User stylesheets loaded from a file inside ~/Library don't apply in the content process || TBD || TBD
Jmathies
Confirmed users
1,982

edits

Retrieved from "https://wiki.allizom.org/Special:MobileDiff/1142052"

Navigation menu