Security/Sandbox/Deny Filesystem Access: Difference between revisions

Security/Sandbox/Deny Filesystem Access (view source)

Revision as of 15:12, 1 August 2016

579 bytes added , 1 August 2016

edits

Jmathies

Confirmed users

1,982

edits

@@ Line 31: / Line 31: @@
 |-
 | {{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
+# 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.
+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.
-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.
+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.
-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).
-# 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|1136836}} Load chrome: URLs through parent process || Blocks disabling read access to parts of the profile dir ||
@@ Line 49: / Line 53: @@
 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|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|1109293}} Desktop content process resource:// and moz-extension:// URIs should not directly use file:/// || Might block how we handle file:// URI's ||