Canmove, confirm
1,220
edits
Changes
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..."
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 security model and hardening applied to the [[B2G]] runtime.
== Terminology ==
'''''Web App''''' : A Web App is an HTML application running in B2G. For example, Firefox is a Web App in B2G. Pages inside Firefox are not called Web Apps in this document.
'''''B2G core process''''' : The B2G core process is generally referred to as '''b2g'''. This is the process that control the Web Application access to _any_ resource.
'''''B2G content process''''' : The B2G content process is often referred to as '''content''' or '''content process'''. This is the process in which Web Apps are running. It communicates with the B2G Core process via IPC.
The goals of the [[B2G]] runtime security model are to:
* enforce the permissions granted to Web Apps
* protect the B2G core and content processes from attack from malicious content
== Enforcing permissions ==
The Web App Permissions model [LINK TDB] describes how users grant permissions to applications (either directly, or through a trusted third party). Ensuring that these permissions are enforced correctly is critical to ensuring the security of user data and the integrity of the application platform [[B2G]] provides. With this in mind, Web App permissions are enforced at multiple layers within [[B2G]] to reduce the risk of the permission model being compromised.
The controls outlined below are based on the architecture documented at [[B2G/Architecture]], in particular:
* The B2G core process is high-privileged and has access to most hardware devices
* Web Apps run in a low-privileged B2G content process and only communicate to the B2G core process via IPC, as implemented by IPDL
* Each Web API has an associated IPDL interface
* B2G Permissions Database: [[B2G]] contains a central permissions database that stores the permissions granted to all Web Apps. Permissions are added at installation time, and can only be modified by the permissions manager app.
=== Web App Layer ===
* Web Apps are loaded inside a special type of iframe ('''<iframe mozapp>''') that separates the Web Apps from other content, and is strongly associated with a Web App manifest, which describes the Web App.
* Each Web App has an associated set of permissions. When the Web App attempts to call certain sensitive APIs, the B2G permission database is checked, and the call will succeed only if the application is granted the associated permission(s).
* Each Web App is hosted on a separate domain. It may only access the resources associated with its domain (indexedDB, cookie store, offline storage etc.). The only exception is if the Web App has permissions to access APIs that access common resources such as contacts, photo gallery, media store, usb devices etc. [Not really true, and TBD to boot]
=== Content Processes ===
* 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 content processes are sandboxed to have a very limited OS level access [TBD exact list of syscalls]. 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. [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. As such the key threats to the underlying operating system are:
* Memory corruption or logical errors in Gecko leading to arbitrary code execution
* Similar faults in the operating system itself (kernel and daemons) leading to arbitrary code execution
* Compromise of the update mechanism used
* Hijacking another web application (XSS, or memory corruption for example)
* IPDL vulnerability
The approach to mitigation of the two code execution threats is:
* 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)
* Harden the underlying OS to make post-exploitation more difficult
* Use the hardening features of the compiler
=== Process model and separation (sandboxing, etc.) ===
As previously specified the B2G process model is based on:
* One B2G core process (parent) which has access to all hardware, devices etc
* One or more B2G content processes (child), which only needs enough system access access to communicate with the parent process [it also has WebGl needs, currently]
In case of a vulnerability in B2G content processes, the OS limits the impact by denying system level resource access to the low-privilege content processes. Compromising the B2G core process is equivalent to complete system compromise.
Compromising a B2G content process can still lead to the access of application's permissions running in the same B2G content process.
We are Investigating seccomp mode 2 (require kernel patch for < 3.5) in order to allow:
recv, send, exit (+any other whitelisted system call necessary for WebGL, such as mmap) for B2G content processes.
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
* Investigate running the B2G core process and B2G content processes in separate ARM TrustZones
* Investigate Role Based Access Control (enforced at the kernel level): RSBAC/SELinux/Etc (see also a similar project: http://selinuxproject.org/page/SEAndroid ,mainly the policy at http://selinuxproject.org/~seandroid/git/selinux/sepolicy/)
=== OS Hardening ===
Mozilla will provide 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 others), 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
* /system mounted read-only
* Compilation of all the software with SSP/PIE and FORTIFY_SOURCE.
* Review of system daemons setup (wpa_supplicant, gpsd, etc)
==== 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
==== OS Update ====
OS updates includes everything except Gecko, which has its own update process (see below).
OS updates are issued when a user-impacting bug or a security bug is found, or when a required for a B2G major upgrade.
OS Updates can be done in 2 different ways:
* Via a firmware image, through USB. The fast boot bootloader is required. Note that this can be used to install any other OS as well and has no restrictions.
This method is also used when method 2) fails (power issue, hardware failure, etc.) and "brick" the device.
* OTA ("on the air"). While the preferred method, this mechanism has not yet been defined from a functional point of view. It will be similar to Android's OTA mechanism.
However:
* Strong crypto signature verification is required before installing those packages
* The complete update must be downloaded in a specific and secure location before the update process starts
* The system must be in a secure state when the update process starts (no Web Apps running)
* The keys must be stored in a secure location on the device
==== B2G Update ====
B2G updates itself using the same mechanism as Firefox on the desktop.
* The updates are fetched over SSL
* SSL certificate's issuer names are pinned in B2G
* Updates are signed in the update file (MAR format, see also: https://wiki.mozilla.org/Software_Update:MAR)
See https://bugzilla.mozilla.org/show_bug.cgi?id=715816 for implementation (in progress)
== Protecting the user data ==
* Fastboot, the boot loader, enforce erasing user data when the boot loader is unlocked (fastboot oem unlock), which makes extracting the user data more difficult
* Physical access to an unlocked device means the user data is unprotected
=== Future ===
* Full disk encryption is recommended
** Encryption depends on the device's password which can be a useability issue
** Investigate the option of unlocking at boot time only (less secure, but not too bad), possibly via a configuration option
** Users could also forget their encryption password more easily
This document primarily covers the security model and hardening applied to the [[B2G]] runtime.
== Terminology ==
'''''Web App''''' : A Web App is an HTML application running in B2G. For example, Firefox is a Web App in B2G. Pages inside Firefox are not called Web Apps in this document.
'''''B2G core process''''' : The B2G core process is generally referred to as '''b2g'''. This is the process that control the Web Application access to _any_ resource.
'''''B2G content process''''' : The B2G content process is often referred to as '''content''' or '''content process'''. This is the process in which Web Apps are running. It communicates with the B2G Core process via IPC.
The goals of the [[B2G]] runtime security model are to:
* enforce the permissions granted to Web Apps
* protect the B2G core and content processes from attack from malicious content
== Enforcing permissions ==
The Web App Permissions model [LINK TDB] describes how users grant permissions to applications (either directly, or through a trusted third party). Ensuring that these permissions are enforced correctly is critical to ensuring the security of user data and the integrity of the application platform [[B2G]] provides. With this in mind, Web App permissions are enforced at multiple layers within [[B2G]] to reduce the risk of the permission model being compromised.
The controls outlined below are based on the architecture documented at [[B2G/Architecture]], in particular:
* The B2G core process is high-privileged and has access to most hardware devices
* Web Apps run in a low-privileged B2G content process and only communicate to the B2G core process via IPC, as implemented by IPDL
* Each Web API has an associated IPDL interface
* B2G Permissions Database: [[B2G]] contains a central permissions database that stores the permissions granted to all Web Apps. Permissions are added at installation time, and can only be modified by the permissions manager app.
=== Web App Layer ===
* Web Apps are loaded inside a special type of iframe ('''<iframe mozapp>''') that separates the Web Apps from other content, and is strongly associated with a Web App manifest, which describes the Web App.
* Each Web App has an associated set of permissions. When the Web App attempts to call certain sensitive APIs, the B2G permission database is checked, and the call will succeed only if the application is granted the associated permission(s).
* Each Web App is hosted on a separate domain. It may only access the resources associated with its domain (indexedDB, cookie store, offline storage etc.). The only exception is if the Web App has permissions to access APIs that access common resources such as contacts, photo gallery, media store, usb devices etc. [Not really true, and TBD to boot]
=== Content Processes ===
* 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 content processes are sandboxed to have a very limited OS level access [TBD exact list of syscalls]. 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. [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. As such the key threats to the underlying operating system are:
* Memory corruption or logical errors in Gecko leading to arbitrary code execution
* Similar faults in the operating system itself (kernel and daemons) leading to arbitrary code execution
* Compromise of the update mechanism used
* Hijacking another web application (XSS, or memory corruption for example)
* IPDL vulnerability
The approach to mitigation of the two code execution threats is:
* 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)
* Harden the underlying OS to make post-exploitation more difficult
* Use the hardening features of the compiler
=== Process model and separation (sandboxing, etc.) ===
As previously specified the B2G process model is based on:
* One B2G core process (parent) which has access to all hardware, devices etc
* One or more B2G content processes (child), which only needs enough system access access to communicate with the parent process [it also has WebGl needs, currently]
In case of a vulnerability in B2G content processes, the OS limits the impact by denying system level resource access to the low-privilege content processes. Compromising the B2G core process is equivalent to complete system compromise.
Compromising a B2G content process can still lead to the access of application's permissions running in the same B2G content process.
We are Investigating seccomp mode 2 (require kernel patch for < 3.5) in order to allow:
recv, send, exit (+any other whitelisted system call necessary for WebGL, such as mmap) for B2G content processes.
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
* Investigate running the B2G core process and B2G content processes in separate ARM TrustZones
* Investigate Role Based Access Control (enforced at the kernel level): RSBAC/SELinux/Etc (see also a similar project: http://selinuxproject.org/page/SEAndroid ,mainly the policy at http://selinuxproject.org/~seandroid/git/selinux/sepolicy/)
=== OS Hardening ===
Mozilla will provide 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 others), 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
* /system mounted read-only
* Compilation of all the software with SSP/PIE and FORTIFY_SOURCE.
* Review of system daemons setup (wpa_supplicant, gpsd, etc)
==== 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
==== OS Update ====
OS updates includes everything except Gecko, which has its own update process (see below).
OS updates are issued when a user-impacting bug or a security bug is found, or when a required for a B2G major upgrade.
OS Updates can be done in 2 different ways:
* Via a firmware image, through USB. The fast boot bootloader is required. Note that this can be used to install any other OS as well and has no restrictions.
This method is also used when method 2) fails (power issue, hardware failure, etc.) and "brick" the device.
* OTA ("on the air"). While the preferred method, this mechanism has not yet been defined from a functional point of view. It will be similar to Android's OTA mechanism.
However:
* Strong crypto signature verification is required before installing those packages
* The complete update must be downloaded in a specific and secure location before the update process starts
* The system must be in a secure state when the update process starts (no Web Apps running)
* The keys must be stored in a secure location on the device
==== B2G Update ====
B2G updates itself using the same mechanism as Firefox on the desktop.
* The updates are fetched over SSL
* SSL certificate's issuer names are pinned in B2G
* Updates are signed in the update file (MAR format, see also: https://wiki.mozilla.org/Software_Update:MAR)
See https://bugzilla.mozilla.org/show_bug.cgi?id=715816 for implementation (in progress)
== Protecting the user data ==
* Fastboot, the boot loader, enforce erasing user data when the boot loader is unlocked (fastboot oem unlock), which makes extracting the user data more difficult
* Physical access to an unlocked device means the user data is unprotected
=== Future ===
* Full disk encryption is recommended
** Encryption depends on the device's password which can be a useability issue
** Investigate the option of unlocking at boot time only (less secure, but not too bad), possibly via a configuration option
** Users could also forget their encryption password more easily
