Security/Sandbox/Deny Filesystem Access: Difference between revisions
Jump to navigation
Jump to search
Haftandilian (talk | contribs) (Initial version with table for status of filesystem sandbox in Nightly) |
Haftandilian (talk | contribs) (Cleanup) |
||
| Line 1: | Line 1: | ||
= Status = | |||
{| class="wikitable" | {| class="wikitable" | ||
|- | |- | ||
! Platform !! Status | ! Platform !! Current Status of Content Filesystem Sandboxing | ||
|- | |- | ||
| Windows || TBD | | Windows || TBD | ||
| Line 17: | Line 15: | ||
| Other || No filesystem policy enabled | | Other || No filesystem policy enabled | ||
|} | |} | ||
= Blockers = | |||
== Cross-Platform Blockers == | |||
== Windows Blockers == | |||
== OS X Blockers == | |||
== Linux Blockers == | |||
== Other Blockers == | |||
Revision as of 22:46, 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 fully 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 |