Gaia== Terminology =='''''Web application''''': An HTML/JS application started within a content process. All user-facing applications on B2G/Gecko are under heavy developmentweb applications. '''''b2g process''''': This is the main process of B2G, so some items below are subject it controls web application's access to changeresources, the API, etc. This is a high-privileged process (i.e., runs as root) '''''Content process''''' : This is a sub-process spawned by the b2g process, or incompleteand which communicates with the b2g process. It represents a web application. This is a low-privileged process (i.e., run as regular user and has a very limited access and view of/to the operating system). When possible '''''IPDL''''': Intercommunication Protocol Definition Language, those are noted between see [[brackets/IPDL]]. '''''AOSP''''': Android Open Source Project. '''''Proposed <*>''''': This document primarily covers means the security model section has <b>NOT</b> yet been implemented in b2g and is being discussed. In that case, a status, priority and a proposed ETA is also included. '''''system call''''': An interface to talk between the user-space(processes) and hardening applied the kernel. There is no other way for a user-space to talk to the kernel. '''''DAC, MAC''''': Discretionary Access Control (up to the user) and Mandatory Access Control (enforced by the kernel) == [[B2G]] runtimeRuntime Security Model ==* Limit and enforce the scope of resources that can be accessed or used by a web application* Ensure several layers of security are being correctly used in the operating system* 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]] === Content process initialization ==={||Implementation Status||Priority||Proposed ETA|-|Done||N/A||N/A|} * The b2g process starts content processes, when it reaches a special type of iframe ('''<iframe mozapp>''').This separates the web application from the rest of the content and is strongly associated to a manifest (see [[/Apps/Security]] for more information).* The content processes are started in the container called an "out of process" container, or an OOP. It is represented by the plugin-container process and uses similar code to the plugin-container used by the desktop Firefox. === Risks ===* Leak of information when spawning the web application's content process* Possibility to access resources/same level of privileges as the b2g process* Bypassing the initialization === Implementation ===* b2g calls:** fork()** setuid(app_0|nobody) (which is an unprivileged user)** chrdir('/')** execve('plugin-container')
== Terminology ==This ensures the OOP process runs in a separate memory space (new process) and as a low right user, that cannot elevate it's privileges to the level of the b2g process.
'''''Web App''''' * File Descriptor handling: ** White list method** A Web App list of permitted file descriptors (FD) is an HTML application running created and stored in B2G. For examplethe mFileMap object** All unlisted FDs are forcefully closed in LaunchApp(), Firefox is a Web App in B2G. Pages inside Firefox after fork() (where FDs are not called Web Apps in this document.copied), and before execve()
'''''B2G core process''''' Unlike the blacklist method (Close-on-exec flag: The B2G core process CLOEXEC), this ensures not FD is generally referred to as '''b2g'''. This left open, and is the process that control the Web Application access to _any_ resourcetherefore more reliable.
'''''B2G content == 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.sand-boxing =={||Implementation Status||Priority||Proposed ETA|-|N/A||High||Release 2|}
The goals of === Risks ===* Memory corruption or logical errors in the [[B2G]] Gecko runtime security model are leading to:arbitrary code execution* Similar faults in the operating system itself (kernel) leading to arbitrary code execution
=== Proposed implementation ===* enforce the permissions granted All access to Web Appsresources <b>must</b> happen via IPDL, this means:* protect * No filesystem access** Very limited access to the B2G core and content processes from attack from malicious contentkernel's system calls (no ioctl(), etc.)** No execution of native ocode* ensure the communication between the B2G core process and the B2G content process is not used in unintended manners* Fuzzing of IPDL [DONE]
== Enforcing permissions ==Implementations of the above requirements, <u>by order of preference</u>:
The Web App Permissions model [LINK TDB] describes how users grant permissions to applications ==== Seccomp ====Secure computing mode (either directly, or through seccomp) is a trusted third party). Ensuring Linux kernel system call that these permissions are enforced correctly is critical allow us to ensuring the security of user data limit which system calls (and any sub-process spawned from that point forward) can be used the integrity of the application platform [[B2G]] providesprocess. With this in mind, Web App permissions are enforced at multiple layers within [[B2G]] to reduce This is the risk of the permission model being compromisedpreferred implementation. The controls outlined below are based on the architecture documented at [[B2G/Architecture]], in particular:
* Seccomp mode 2:** The B2G core no new privileges (NNP) flag ensures that the restrictions cannot be reverted, and are inherited by sub-processes** Restrictions are therefore kept until the process is high(and/or sub-privileged and has access to most hardware devicesprocesses) exits* Web Apps run in a low* White-privileged B2G content process and only communicate to the B2G core process via IPClisting of authorized system calls, as implemented by IPDLmay include system call arguments* Each Web API has an associated IPDL interfaceFile system access, spawning of processes, access to most resources is nonexistent without escaping the sand-box* B2G Permissions Database: [[B2G]] contains a central permissions database that stores Can be initialized once the permissions granted process has established access to all Web Apps. Permissions are added at installation time, and can only be modified by the permissions manager app. === Web App Layer ===needed files & resources
* 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.Sand-box escape scenarios:* Each Web App has an associated set * Kernel vulnerability triggered via one 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). very few allowed system calls* 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 ===[B2G core and content * b2g process separation is not planned to be enabled in the Milestone 3 release]vulnerability triggered via IPDL
* All Web Apps run in a low-rights, separate processMisc & caveats: 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.* 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.* Different Web Apps are loaded in separate content processes to allow for further attack surface reduction. Ideally apps are separated one per processRequires kernel patch and kernel sources, 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)Linux kernel >=3.5* B2G content processes have access to a record of * Currently only available on the privileges associated with the applications running in themNexus S AOSP sources https://bugzilla. 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 waymozilla. In this case the B2G core process will enforce the permissions (see next point)org/show_bug.cgi?id=790923* 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, * WebGL requires some security sensitive system calls such 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 ==ioctl()
In B2G applications are all Web Apps - there are strictly no binary ==== RBAC ("native"Role Based Access Control) applications installed ====RBAC is implemented by the uservarious frameworks, including SELinux, RSBAC RC, 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 wellGrSecurity RBAC. As such the key threats to the underlying operating system are:
* Memory corruption These frameworks are generally called Mandatory Access Control frameworks (MAC), and allow to set white-lists of system calls to any process, or logical errors in Gecko leading group of processes, based on roles and types. Roles are assigned to arbitrary code execution* Similar faults in the operating system itself (kernel processes and daemons) leading users, types to arbitrary code executionthe resources they access.* Compromise of This allow the framework to control the access with little or no modifications made to the update mechanism used* Hijacking another web application (XSSrunning programs, or memory corruption for example)* IPDL vulnerabilityunlike seccomp.
The approach to mitigation * Allows for extremely flexible configurations* Restrictions are always enforced by the kernel* Restrictions can also be configured for other system processes and thus sand-boxing of the two code execution threats is:other processes (wpa_supplicant, init, etc.)
* Hardening gecko against attack (Sand-box escape scenarios:** The escape scenarios always depend on the same approach as for Firefox)security rules* Run web content in lower-rights child processes to reduce the impact * Generally, any kernel vulnerability triggered via one of process compromise (the B2G content process explained allowed systems calls, and in some cases, the previous section)ability to disable the framework* Harden the underlying OS to make post-exploitation more difficult* Use the hardening features of the compiler when possibleb2g process vulnerability triggered via IPDL
=== Process model * Misc & caveats:** Require a custom kernel with SELinux enabled, or other solutions patched in and separation enabled** WebGL requires some security sensitive system calls such as ioctl(sandboxing, etc.) ===
As previously specified the B2G process model is based on: ==== chroot ====* One B2G core process chroot(parent) is a well-known system call, which has changes the view of the root filesystem of the process. This system call is not made for security file system access to all hardware, devices etc* One or more B2G content processes but may be used in that fashion, as long no privileged user (childsuch as root), which only needs enough system access access to communicate with runs within the parent process [it also has WebGl needs, currently]chroot.
In case of a vulnerability in B2G content processes* Can be initialized once the process has established access to all the needed files & resources, if the OS limits program is modified to do so, as the impact by denying system level resource access program has to still be running as root when chroot() is called (or to have all files available in the low-privilege content processeschroot directory). See https://bugzilla.mozilla. Compromising org/show_bug.cgi?id=776648.** Linux namespaces can be used in combination with the B2G core process is equivalent chroot in order to complete reduce the amount of code changes or files copied* While chroot() provides a different view of the filesystem, it does not provide any other separation. All system compromisecalls are still available to the process.* Does not require kernel modifications
Compromising a B2G content process can still lead * 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 access of applicationoriginal root, or simply by remounting the entire device's permissions running in the same B2G content root** b2g process.vulnerability triggered via IPDL
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.=== Proposed advanced sand-boxing improvements ===
Any other system call is denied by * Use of ARM TrustZones (TZ), which implements hardware virtualization and strong resources separation** Wrapping of the IPDL messages over the TZ communication mechanism* WebGL proxy** Ensures the kernel for B2G content processes.do not need additional system calls such as ioctl()** Large task** May reduce execution speed of WebGL code
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== Filesystem hardening =={||Implementation Status||Priority||Proposed ETA|-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.|Done||N/A||N/A|}
==== Future =Risks ===* The goal is to have a finer level Writing, deleting or reading files of separation between various software componentsanother users, resulting in particular the B2G core process's componentsinformation leak, or unexpected behavior (privilege escalation, etc.)** WebGL Graphics pipeline segregation and consequently tighter sanboxing Execution of the B2G content processesnative code via an application vulnerability* Investigate running the B2G core process and B2G content processes Vulnerabilities in separate ARM TrustZones* Investigate Role Based Access Control setuid programs (enforced at the kernel level): RSBAC/SELinux/Etc (see also a similar project: http://selinuxproject.org/page/SEAndroid and thus,mainly the policy at http://selinuxproject.org/~seandroid/git/selinux/sepolicy/privilege escalation) === OS Hardening ===
Mozilla provides a reference implementation and recommendations for OS security controls.=== Mountpoints ===* Filesystem privileges enforced by Linux's ACLs** The B2G core process runs as root and has CAP_DAC_READ_SEARCH rationale is that only areas that contain user-content may be read-write (and other capabilitiesunless the OS itself require a new read-write area in the future), 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_supplicantmust include nodev, gpsdnosuid, etc)* Compilation of the software with full ASLR support (incl. linker) and SSP/PIE binaries has been found to currently impact the runtime performance significantlynoexec options.* Mount point should contain the following mount options (and may contain more options)The filesystem mounts are restricted as follow:
{| border="1"
|}
* If any additional mount is present, the rational is that only areas that contain user-content may be read-write (unless the OS itself require a new read-write area in the future), and must include nodev, nosuid, noexec options.* Mount points path may vary=== Linux DAC's ACLs ===
The Linux DAC's ACLS represents the well-known Linux filesystem permission model. (User, group, others owners and read, write, execute modes).
==== Future ====* The app_0/nobody user has no write access to any file* The usage of setuid binaries is limited to where necessary* Starting processes with a sane umask
* Investigate CoreBoot secure boot support (ala ChromeOS) http://review.coreboot.org/gitweb?p=coreboot.git;a=commit;h=9aea04aa892903009e487ada7f7b911691e68630 or enhancements Due to the flexible nature of the DAC ACLs, this section is subject to fastboot* See also: http://www.chromiumregular reviews.org/chromium-os/chromiumos-design-docs/system-hardening* Investigate running full ASLR with better performance
==Full disk encryption (FDE) == OS Update ===={||Implementation Status||Priority||Proposed ETA|-|N/A||Medium||Release 2|}
OS updates includes everything except Gecko, which has its own update process (see below).=== Risks ===OS updates are issued when a user-impacting bug or a security bug * User device is found, or when a required for a B2G major upgrade.copied in order to steal his sensitive data
OS Updates can be done in 2 different ways:=== Proposed Implementation ===
* Via Android already uses FDE in a firmware image, through USB. The fast boot sane manner and may be copied** Locking/Unlocking the bootloader is required. Note that this can be used wipes the device (all blocks to install any other OS as well 0) and has no restrictions.This method is also used when method 2) fails restores it to factory settings(power issue, hardware failure, etc.fastboot) and "brick" ** Devices are installed with the device.bootloader locked by default* OTA ("on A user interface must be present to set the air"). While encryption password* May allow a weaker screen lock password if the preferred method, this mechanism has not yet been defined from a functional point user is informed of view. It will be similar the possible consequences:** Unlocking the phone screen can give access to Android's OTA mechanism.sensitive data, depending on the applications and the configuration
However:== Address Space Layout Randomization (ASLR) =={||Implementation Status||Priority||Proposed ETA|-|N/A||High||Release 2* Strong crypto signature verification is required before installing those packages|} === Risks ===* The complete update must be downloaded Vulnerabilities in the application's code lead to easy to guess addresses in a specific the code, and secure location before thus easy exploitation of the update process startsvulnerability* 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=== Proposed Implementations ===
==== B2G Update ====* Upgrade Gonk to Jelly Bean's build system (newer GCC version, and complete ASLR support)** Faster, newer GCC, smaller performance impact from ASLR** Full ASLR, the complete process memory image's addresses are randomized** Require upgrading the build system
B2G updates itself using * Enable ASLR support, PIE, and linker ASLR in the same mechanism as Firefox on the desktop.current build system* The updates are fetched over SSL* Require patching of various components* SSL certificate's issuer names are pinned ** Failure to do so would result in B2Ga half functioning ASLR, which is not much better than no ASLR support* * May lead to slower process start and high performance penalties == Updates are signed in the update file (MAR format, see also: ==[TDB with paul]* https://wikibugzilla.mozilla.org/Software_Update:MAR)show_bug.cgi?id=783638See * https://bugzilla.mozilla.org/show_bug.cgi?id=715816 === Proposed Implementation: Tracking of applications versions for implementation (in progress)known security patches ==={||Implementation Status||Priority||Proposed ETA|-|N/A||High||Release 2|}
== Protecting A version tracking mechanism is necessary in order to decide when components of B2G need to be updated due to a security vulnerability.A list of the user data ==currently installed applications in Gonk must therefore be maintained, in particular for:* Fastboot, the boot loader, enforce erasing user data when the boot loader is unlocked (fastboot oem unlock), which makes extracting the user data more difficultThe kernel * The gonk processes such as wpa_supplicant* Physical access to an unlocked device means the user data is unprotectedThe gonk libraries such as Bionic
=== Future ===* Full disk encryption is recommended** Encryption depends The version tracking mechanism should automatically warn the product security group based on the device's password which can be a useability issue** Investigate the option of unlocking at boot time only security feed (less secureCVEs, but not too badAndroid Security upgrades), possibly via a configuration option** Users could also forget their encryption password more easily
