Security/Sandbox/Deny Filesystem Access: Difference between revisions
Jump to navigation
Jump to search
Haftandilian (talk | contribs) (→Status) |
Haftandilian (talk | contribs) |
||
| Line 27: | Line 27: | ||
|- | |- | ||
| {{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:/// URL, 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:/// URL, that must continue to work. | ||
|- | |||
| {{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 || TBD. For printing and print-to-file. (TBD, because 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: URL's. Example, 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: URL's. Example, an add-on calling loadFromScript("chrome://foo/bar") from the Parent process results in Content trying to load that URL. | ||
Revision as of 23:32, 16 May 2016
Status
| Platform | Current Status of Content Filesystem Sandboxing |
|---|---|
| Windows | TBD |
| 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.
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
| 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:/// URL, that must continue to work. |
| 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 | TBD. For printing and print-to-file. (TBD, because 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: URL's. Example, an add-on calling loadFromScript("chrome://foo/bar") from the Parent process results in Content trying to load that URL. |