Confirm
502
edits
Changes
Added road map, cleaned up features
Current implementation is documented at https://developer.mozilla.org/en-US/docs/Mozilla/Firefox_OS/Security/System_security
Global tracking bug https://bugzilla.mozilla.org/show_bug.cgi?id=862082
=== Goals and scope of this document ===
* Limit and contain the impact of vulnerabilities caused by security bugs, system-wide
* Web application permissions and any application related security feature is detailed in [[/Apps/Security]]
* Expose a road-map of the upcoming system-related security features
== Content process sand-boxing = Road Map ===
{|
|Feature||Implementation Status||Priority/Importance||Proposed ETA
|-
|Seccomp|https://bugzilla.mozilla.org/show_bug.cgi?id=790923 (ASAP)||High|||-|GL Proxy|N/A||High||Release 2|-|Supervisor process|https://bugzilla.mozilla.org/show_bug.cgi?id=845191 (Soon)||High|||-|RBAC (MAC)|N/A|Medium|||-|Disk Encryption|https://bugzilla.mozilla.org/show_bug.cgi?id=777917||Medium|||-|ASLR|https://bugzilla.mozilla.org/show_bug.cgi?id=777948 (Soon)||Medium|||-|Compiler hardening|https://bugzilla.mozilla.org/show_bug.cgi?id=620058||Medium|||-|JIT hardening|https://bugzilla.mozilla.org/show_bug.cgi?id=677272||Low|||-|Implement automated compliance testing of security features|N/A||Medium|||-|Integrity measurements|N/A|Low||
|}
==== RBAC (Role Based Access Control) ====
* Allows for extremely flexible configurations
* Restrictions are always enforced by the kernel
* Restrictions can also be configured for other system processes any process and therefore sand-boxing of other the non-b2g processes as well (wpa_supplicant, init, etc.)* Possible to target only some processes (targeted policy), albeit a complete policy (all processes, no exception) is preferred from the security point of view.
* Sand-box escape scenarios:
* Misc & caveats:
** Requires a custom kernel with SELinux enabled, or other kernel patch based solution built and enabled
** WebGL requires some security sensitive system calls such as ioctl() ==== rlimit ====rlimit() is a system call that Security policy can be used to deny file and process creation. Like chroot(), this may be used as long as no privileged user (such as root) is running any process that is being rlimit'ed. * Relatively easy to implement, supported by various operating systems** RLIMIT_FSIZE = 0 requires that no file is written to (within the process) - this can already works** RLIMIT_NOFILE = 0 requires that no new file descriptor is opened (within the process)** RLIMIT_NPROC = 0 requires that no new thread of process is created (within the process)* Does not require kernel modifications* Used as fall-back sand-box in other programs, such as OpenSSH * Sand-box escape scenario:** Kernel vulnerability (any)** Loading code directly in memory (instead of executing, for example, /bin/sh), then finding user-space vulnerabilities in other processes** Privilege escalation to root/privileged user, then disable rlimits** User-land vulnerability via any kind of IPC** b2g process vulnerability triggered via IPDL ==== chroot ====chroot() is a well-known system call, which changes the view of the root filesystem of the process.This system call is not explicitly designed to secure access to the file system but may be used in this fashion as long no privileged user (such as root) is running any process within the chroot after the process has been initialized. * Can be initialized after the process has already accessed all its needed files extensive and resources, although the process muststill be running as root when calling chroot() or must have all needed files located inside the chroot directory). See https://bugzilla.mozilla.org/show_bug.cgi?id=776648.** Linux namespaces can be used in combination with the chroot in order to reduce the amount of code changes or files copied* While chroot() restricts a process' view of the filesystem, it enforces no other restrictions. All system calls are still available to the process.* Does not eventually require kernel modifications * Sand-box escape scenario:** Kernel vulnerability (any)** User-land vulnerability via any kind of IPC** Privilege escalation to root/privileged user, then escape via chdir('.run on different devices.') and chrooting back to the original root, or simply by remounting the entire device's root** b2g process vulnerability triggered via IPDL === Proposed advanced sand-boxing improvements === * Use of ARM TrustZones (TZ), which implements hardware virtualization and strong resource separation** Wrapping of the IPDL messages over the TZ communication mechanism* WebGL proxy** Ensures the content processes do not need additional system calls such as ioctl()** Large amount of effort needed to implement** May reduce execution speed of WebGL code == Full disk encryption (FDE) =={||Implementation Status||Priority||Proposed ETA|-|N/A||Medium||Release 2|}
== Disk encryption ==
=== Risks ===
* Device is stolen and attacker has full access to the user's data storage
=== Proposed Implementation ===
* Android already uses FDE disk encryption in a relatively sane manner and their approach may be re-used, see http://source.android.com/tech/encryption/android_crypto_implementation.html- Password handling should be revisited (different encryption/unlock passwords, better derivation of the password, as Android needs a very long password to resist brute force attacks).** Android encrypts only the data partition** Uses read-only partitions when unencrypted to ensure no data is being written
** Locking/Unlocking the bootloader wipes the device and restores it to factory settings, this is enforced by fastboot
** Devices are shipped with the bootloader locked by default
*** Shutting the phone down ensures a better level of security assurance since the encryption is using a strong password
*** Using a PIN for encryption generally renders the encryption useless as those can be cracked in seconds (see for example https://viaforensics.com/viaextract/viaextract-includes-android-encryption-cracking.html )
* ChromeOS uses a slightly different disk encryption mechanism using eCryptFS.
** ChromeOS only encrypts the user's home directory.
* FDE (Full Disk Encryption)
** Requires a fast CPU or hardware acceleration
** Ensures no data is left unencrypted on the flash device
== Address Space Layout Randomization (ASLR) ==
=== Risks ===
== Updates: Proposed Additional Implementation: Tracking of applications versions for known security patches ==
A version tracking mechanism is necessary in order to decide when components of B2G need to be updated due to a security vulnerability.
* The tracking software may however be provided to them, with guidance, for example
* Guidance on updates may also be provided instead
=== Sandbox implementations that were not selected (kept for reference) ===
==== rlimit sandbox ====
rlimit() is a system call that can be used to deny file and process creation. Like chroot(), this may be used as long as no privileged user (such as root) is running any process that is being rlimit'ed.
* Relatively easy to implement, supported by various operating systems
** RLIMIT_FSIZE = 0 requires that no file is written to (within the process) - this can already works
** RLIMIT_NOFILE = 0 requires that no new file descriptor is opened (within the process)
** RLIMIT_NPROC = 0 requires that no new thread of process is created (within the process)
* Does not require kernel modifications
* Used as fall-back sand-box in other programs, such as OpenSSH
* Sand-box escape scenario:
** Kernel vulnerability (any)
** Loading code directly in memory (instead of executing, for example, /bin/sh), then finding user-space vulnerabilities in other processes
** Privilege escalation to root/privileged user, then disable rlimits
** User-land vulnerability via any kind of IPC
** b2g process vulnerability triggered via IPDL
==== chroot ====
chroot() is a well-known system call, which changes the view of the root filesystem of the process.
This system call is not explicitly designed to secure access to the file system but may be used in this fashion as long no privileged user (such as root) is running any process within the chroot after the process has been initialized.
* Can be initialized after the process has already accessed all its needed files and resources, although the process must
still be running as root when calling chroot() or must have all needed files located inside the chroot directory). See https://bugzilla.mozilla.org/show_bug.cgi?id=776648.
** Linux namespaces can be used in combination with the chroot in order to reduce the amount of code changes or files copied
* While chroot() restricts a process' view of the filesystem, it enforces no other restrictions. All system calls are still available to the process.
* Does not require kernel modifications
* Sand-box escape scenario:
** Kernel vulnerability (any)
** User-land vulnerability via any kind of IPC
** Privilege escalation to root/privileged user, then escape via chdir('..') and chrooting back to the original root, or simply by remounting the entire device's root
** b2g process vulnerability triggered via IPDL
