Confirmed users
502
edits
B2G/Architecture/System Security: Difference between revisions
Jump to navigation
Jump to search
Updated mounts and current status of B2G multiprocess support, + minor edits
Ptheriault (talk | contribs) (Created page with "Gaia/B2G/Gecko are under heavy development, so some items below are subject to change. When possible, those are noted between [brackets]. This document primarily covers the secur...") |
Gdestuynder (talk | contribs) (Updated mounts and current status of B2G multiprocess support, + minor edits) |
||
| Line 1: | Line 1: | ||
Gaia/B2G/Gecko are under heavy development, so some items below are subject to change. When possible, those are noted between [brackets]. | 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. | This document primarily covers the security model and hardening applied to the [[B2G]] runtime. | ||
| Line 14: | Line 14: | ||
* enforce the permissions granted to Web Apps | * enforce the permissions granted to Web Apps | ||
* protect the B2G core and content processes from attack from malicious content | * 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 == | == Enforcing permissions == | ||
| Line 33: | Line 34: | ||
=== Content Processes === | === 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 | * 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. 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. | ||
* 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. | * The content processes are sandboxed, 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. | ||
* B2G content processes | * 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). | ||
* B2G content processes have access to a record of the privileges associated with the applications running in them. B2G content processes 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. | * 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 == | == 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. As such the key threats to the underlying operating system are: | 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 | * Memory corruption or logical errors in Gecko leading to arbitrary code execution | ||
| Line 52: | Line 55: | ||
* Hardening gecko against attack (the same approach as for Firefox) | * 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 process) | * Run web content in lower-rights child processes to reduce the impact of process compromise (the B2G content process explained in the previous section) | ||
* Harden the underlying OS to make post-exploitation more difficult | * Harden the underlying OS to make post-exploitation more difficult | ||
* Use the hardening features of the compiler | * Use the hardening features of the compiler when possible | ||
=== Process model and separation (sandboxing, etc.) === | === Process model and separation (sandboxing, etc.) === | ||
| Line 71: | Line 74: | ||
Any other system call is denied by the kernel for B2G content processes. | Any other system call is denied by the kernel for B2G content processes. | ||
The effectiveness of using | 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. | 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 | ==== Future ==== | ||
* The goal is to have a finer level of separation between various software components, in particular the B2G core process's components | * 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 | ** WebGL Graphics pipeline segregation and consequently tighter sanboxing of the B2G content processes | ||
| Line 83: | Line 86: | ||
=== OS Hardening === | === OS Hardening === | ||
Mozilla | Mozilla provides a reference implementation and recommendations for OS security controls. | ||
* Filesystem privileges enforced by Linux's ACLs | * Filesystem privileges enforced by Linux's ACLs | ||
** The B2G core process runs as root and has CAP_DAC_READ_SEARCH (and | ** The B2G core process runs as root and has CAP_DAC_READ_SEARCH (and other 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 | ** The B2G content processes run as a regular user and have a very restricted access | ||
* Review of system daemons setup (wpa_supplicant, gpsd, etc) | * 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. | |||
==== Future | {| 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 ==== | |||
* Investigate CoreBoot secure boot support (ala ChromeOS) http://review.coreboot.org/gitweb?p=coreboot.git;a=commit;h=9aea04aa892903009e487ada7f7b911691e68630 or enhancements to fastboot | * 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 | * See also: http://www.chromium.org/chromium-os/chromiumos-design-docs/system-hardening | ||
* Investigate running full ASLR with better performance | |||
==== OS Update ==== | ==== OS Update ==== | ||