Confirm
502
edits
Changes
Updated mounts and current status of B2G multiprocess support, + minor edits
Gaia/B2G/Gecko are under heavy development, so some items below are subject to change, or incomplete. When possible, those are noted between [brackets].
This document primarily covers the security model and hardening applied to the [[B2G]] runtime.
* enforce the permissions granted to Web Apps
* protect the B2G core and content processes from attack from malicious content
* ensure the communication between the B2G core process and the B2G content process is not used in unintended manners
== Enforcing permissions ==
=== Content Processes ===
[B2G core and content process separation is not planned to be enabled in the Milestone 3 release]
* All Web Apps run in a low-rights, separate process: the B2G content process. The B2G core process fork() itself, then execve() the B2G content process [TBD use CLOEXEC]. The file descriptors are handled via FileMap which closes them on object destruction, and prior to the fork. Only a few select file descriptors are explicitely kept open for communication purposes between the 2 processes.* The content processes are sandboxed to have a , resulting in very limited OS level access [TBD exact list of syscalls, when process separation is enabled]. B2G content processes can only communicate through the IPC mechanism (IPDL) back to the B2G core process, which will perform actions on behalf of content.* Different Web Apps are loaded in separate content processes to allow for further attack surface reduction. Ideally apps are separated one per process, or if this isn’t possible due to resource constraints, trusted Web Apps with access to sensitive are separated from less trusted Web Apps(see the following points). [will that be true for M3?]* B2G content processes will have access to a record of the privileges associated with the applications running in them. B2G content processes will enforce this at a web API level, and as such will never send IPDL messages for APIs which the Web Apps in their process don’t have access to, unless they have been compromised in some way. In this case the B2G core process will enforce the permissions (see next point).
* In this way, each B2G content process is associated with a set of permissions – exactly the union of all permissions from each app running inside it. The B2G core process validates the IPDL messages from a B2G content process, and if a message is detected which requests access to an API that is outside the set of permissions, the B2G core process denies this request. This scenario should never happen under normal operation, as the B2G content process should be enforcing permissions on its apps, so as a precaution the offending B2G content process will be killed and re-spawned as described above.
== Protecting the underlying OS ==
In B2G applications are all Web Apps - there are strictly no binary ("native") applications installed by the user, and all system access is mediated through the Web APIs. There is no direct filesystem access. Files stored on the sdcard are exposed via the Web APIs as well. As such the key threats to the underlying operating system are:
* Memory corruption or logical errors in Gecko leading to arbitrary code execution
* Hardening gecko against attack (the same approach as for Firefox)
* Run web content in lower-rights child processes to reduce the impact of process compromise (the B2G content processexplained in the previous section)
* Harden the underlying OS to make post-exploitation more difficult
* Use the hardening features of the compilerwhen possible
=== Process model and separation (sandboxing, etc.) ===
Any other system call is denied by the kernel for B2G content processes.
The effectiveness of using low-rights B2G content process as a mitigation technique is also dependent on the control of communication between childs (B2G content processes) and the parent process (B2G core process).
IPDL is used as an IPC mechanism via UNIXSOCK and SHM (shared memory). Access requests are done via IPDL and authorized given a certain application ID. The core risk in IPDL is in the serialization and deserialization of data types. IPDL has built-in types which are well-known and tested, and are used where possible. Where deserialization must be done by hand, security review is required. Furthermore, upon encountering any deserialization errors, the child process is killed.
==== Future (M3+) ====
* The goal is to have a finer level of separation between various software components, in particular the B2G core process's components
** WebGL Graphics pipeline segregation and consequently tighter sanboxing of the B2G content processes
=== OS Hardening ===
Mozilla will provide provides a reference implementation and recommendations for OS security controls.* Filesystem privileges enforced by Linux's ACLs (pending review)** The B2G core process runs as root and has CAP_DAC_READ_SEARCH (and othersother capabilities), thus ACLs are not a security measure for this process
** The B2G content processes run as a regular user and have a very restricted access
* Review of system daemons setup (wpa_supplicant, gpsd, etc)
* Compilation of the software with full ASLR support (incl. linker) and SSP/PIE binaries has been found to currently impact the runtime performance significantly.
{| border="1" |+ Mounts|-! Mount point !! Filesystem !! Options|-| / || rootfs || read-only|- | /dev || tmpfs || read-write, nosuid, noexec, mode=0755|- | /dev/pts || ptsfs || read-write, nosuid, noexec, mode=600|-| /proc || proc || read-write, nosuid, nodev, noexec|-| /sys || sysfs || read-write, nosuid, nodev, noexec|-| /cache || yaffs2-or-ext4 || read-write, nosuid, nodev, noexec|-|| /efs || yaffs2-or-ext4 || read-only, nosuid, nodev, noexec|-|| /system || ext4 || read-only, nodev|-|| /data || ext4 || read-write, nosuid, nodev, noexec|-|| /mnt/sdcard || ext4-or-vfat || read-write, nosuid, nodev, noexec, uid=1000, fmask=0702, dmask=0702|-|} ==== Future (M3+) ====
* Investigate CoreBoot secure boot support (ala ChromeOS) http://review.coreboot.org/gitweb?p=coreboot.git;a=commit;h=9aea04aa892903009e487ada7f7b911691e68630 or enhancements to fastboot
* See also: http://www.chromium.org/chromium-os/chromiumos-design-docs/system-hardening
* Investigate running full ASLR with better performance
==== OS Update ====
