MozillaWiki

B2G/Architecture/System Security: Difference between revisions

Page Discussion

B2G/Architecture/System Security (view source)

Revision as of 04:23, 22 October 2012

734 bytes removed ,  22 October 2012
Entire rewrite based on implementation status, risk and priority
(Entire rewrite based on implementation status, risk and priority)
Line 1: Line 1:
Gaia/B2G/Gecko are under heavy development, so some items below are subject to change, or incomplete. When possible, those are noted between [brackets].
== Terminology ==
This document primarily covers the security model and hardening applied to the [[B2G]] runtime.
'''''Web application''''': An HTML/JS application started within a content process. All user-facing applications on B2G are web applications.
 
'''''b2g process''''': This is the main process of B2G, it controls web application's access to resources, 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, and 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).
 
'''''IPDL''''': Intercommunication Protocol Definition Language, see [[/IPDL]].
 
'''''AOSP''''': Android Open Source Project.
 
'''''Proposed <*>''''': This means the 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 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]] Runtime 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''''' : 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.
* File Descriptor handling:
** White list method
** A list of permitted file descriptors (FD) is created and stored in the mFileMap object
** All unlisted FDs are forcefully closed in LaunchApp(), after fork() (where FDs are copied), and before execve()


'''''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.
Unlike the blacklist method (Close-on-exec flag: CLOEXEC), this ensures not FD is left open, and is therefore more reliable.


'''''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.
== Content process sand-boxing ==
{|
|Implementation Status||Priority||Proposed ETA
|-
|N/A||High||Release 2
|}


The goals of the [[B2G]] runtime security model are to:
=== Risks ===
* Memory corruption or logical errors in the Gecko runtime leading to arbitrary code execution
* Similar faults in the operating system itself (kernel) leading to arbitrary code execution


* enforce the permissions granted to Web Apps
=== Proposed implementation ===
* protect the B2G core and content processes from attack from malicious content
* All access to resources <b>must</b> happen via IPDL, this means:
* ensure the communication between the B2G core process and the B2G content process is not used in unintended manners
** No filesystem access
** Very limited access to the kernel's system calls (no ioctl(), etc.)
** No execution of native ocode
** 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 (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.
==== Seccomp ====
Secure computing mode (seccomp) is a Linux kernel system call that allow us to limit which system calls (and any sub-process spawned from that point forward) can be used the process.
The controls outlined below are based on the architecture documented at [[B2G/Architecture]], in particular:
This is the preferred implementation.


* The B2G core process is high-privileged and has access to most hardware devices
* Seccomp mode 2:
* Web Apps run in a low-privileged B2G content process and only communicate to the B2G core process via IPC, as implemented by IPDL
** The no new privileges (NNP) flag ensures that the restrictions cannot be reverted, and are inherited by sub-processes
* Each Web API has an associated IPDL interface
** Restrictions are therefore kept until the process (and/or sub-processes) exits
* 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.
** White-listing of authorized system calls, may include system call arguments
* File system access, spawning of processes, access to most resources is nonexistent without escaping the sand-box
=== Web App Layer ===
* Can be initialized once the process has established access to all the 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 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).
** Kernel vulnerability triggered via one of the 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]
** b2g process vulnerability triggered via IPDL
=== 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. 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.
* Misc & caveats:
* 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.
** Requires kernel patch and kernel sources, or Linux kernel >=3.5
* 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).
** Currently only available on the Nexus S AOSP sources https://bugzilla.mozilla.org/show_bug.cgi?id=790923
* 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).
** WebGL requires some security sensitive system calls such as ioctl()
* 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:
==== RBAC (Role Based Access Control) ====
RBAC is implemented by various frameworks, including SELinux, RSBAC RC, and GrSecurity RBAC.


* Memory corruption or logical errors in Gecko leading to arbitrary code execution
These frameworks are generally called Mandatory Access Control frameworks (MAC), and allow to set white-lists of system calls to any process, or group of processes, based on roles and types. Roles are assigned to the processes and users, types to the resources they access.
* Similar faults in the operating system itself (kernel and daemons) leading to arbitrary code execution
This allow the framework to control the access with little or no modifications made to the running programs, unlike seccomp.
* 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:
* 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 other processes (wpa_supplicant, init, etc.)


* Hardening gecko against attack (the same approach as for Firefox)
* Sand-box escape scenarios:
* Run web content in lower-rights child processes to reduce the impact of process compromise (the B2G content process explained in the previous section)
** The escape scenarios always depend on the security rules
* Harden the underlying OS to make post-exploitation more difficult
** Generally, any kernel vulnerability triggered via one of the allowed systems calls, and in some cases, the ability to disable the framework
* Use the hardening features of the compiler when possible
** b2g process vulnerability triggered via IPDL


=== Process model and separation (sandboxing, etc.) ===
* Misc & caveats:
** Require a custom kernel with SELinux enabled, or other solutions patched in and enabled
** WebGL requires some security sensitive system calls such as ioctl()


As previously specified the B2G process model is based on:
==== chroot ====
* One B2G core process (parent) which has access to all hardware, devices etc
chroot() is a well-known system call, which changes the view of the root filesystem of the process. This system call is not made for security file system access, but may be used in that fashion, as long no privileged user (such as root) runs within the chroot.
* 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.
* Can be initialized once the process has established access to all the needed files & resources, if the program is modified to do so, as the program has to still be running as root when chroot() is called (or to have all files available in 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() provides a different view of the filesystem, it does not provide any other separation. All system calls are still available to the process.
* Does not require kernel modifications


Compromising a B2G content process can still lead to the access of application's permissions running in the same B2G content process.
* 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


We are Investigating seccomp mode 2 (require kernel patch for < 3.5) in order to allow:
=== Proposed advanced sand-boxing improvements ===
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.
* 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 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-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.
== Filesystem hardening ==
{|
|Implementation Status||Priority||Proposed ETA
|-
|Done||N/A||N/A
|}


==== Future ====
=== Risks ===
* The goal is to have a finer level of separation between various software components, in particular the B2G core process's components
* Writing, deleting or reading files of another users, resulting in information leak, or unexpected behavior (privilege escalation, etc.)
** WebGL Graphics pipeline segregation and consequently tighter sanboxing of the B2G content processes
* Execution of native code via an application vulnerability
* Investigate running the B2G core process and B2G content processes in separate ARM TrustZones
* Vulnerabilities in setuid programs (and thus, privilege escalation)
* 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  provides a reference implementation and recommendations for OS security controls.
=== Mountpoints ===
* Filesystem privileges enforced by Linux's ACLs
The rationale 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.
** 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 filesystem mounts are restricted as follow:
** 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.
* Mount point should contain the following mount options (and may contain more options):


{| border="1"  
{| border="1"  
Line 124: Line 182:
|}
|}


* 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.
=== Linux DAC's ACLs ===
* Mount points path may vary


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 to fastboot
Due to the flexible nature of the DAC ACLs, this section is subject to regular reviews.
* See also: http://www.chromium.org/chromium-os/chromiumos-design-docs/system-hardening
* Investigate running full ASLR with better performance


==== OS Update ====
== Full disk encryption (FDE) ==
{|
|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 is found, or when a required for a B2G major upgrade.
* User device is copied in order to steal his sensitive data


OS Updates can be done in 2 different ways:
=== Proposed Implementation ===


* 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.
* Android already uses FDE in a sane manner and may be copied
This method is also used when method 2) fails (power issue, hardware failure, etc.) and "brick" the device.
** Locking/Unlocking the bootloader wipes the device (all blocks to 0) and restores it to factory settings(fastboot)
* 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.
** Devices are installed with the bootloader locked by default
* A user interface must be present to set the encryption password
* May allow a weaker screen lock password if the user is informed of the possible consequences:
** Unlocking the phone screen can give access to sensitive data, depending on the applications and the configuration


However:
== Address Space Layout Randomization (ASLR) ==
* 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
|Implementation Status||Priority||Proposed ETA
* 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
|N/A||High||Release 2
|}
 
=== Risks ===
* Vulnerabilities in the application's code lead to easy to guess addresses in the code, and thus easy exploitation of the vulnerability
 
=== 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 the same mechanism as Firefox on the desktop.
* Enable ASLR support, PIE, and linker ASLR in the current build system
* The updates are fetched over SSL
** Require patching of various components
* SSL certificate's issuer names are pinned in B2G
*** Failure to do so would result in a half functioning ASLR, which is not much better than no ASLR support
* Updates are signed in the update file (MAR format, see also: https://wiki.mozilla.org/Software_Update:MAR)
** May lead to slower process start and high performance penalties
See https://bugzilla.mozilla.org/show_bug.cgi?id=715816 for implementation (in progress)
 
== Updates ==
[TDB with paul]
* https://bugzilla.mozilla.org/show_bug.cgi?id=783638
* https://bugzilla.mozilla.org/show_bug.cgi?id=715816
 
=== Proposed Implementation: Tracking of applications versions for known security patches ===
{|
|Implementation Status||Priority||Proposed ETA
|-
|N/A||High||Release 2
|}


== Protecting the user data ==
A version tracking mechanism is necessary in order to decide when components of B2G need to be updated due to a security vulnerability.
* 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
A list of the currently installed applications in Gonk must therefore be maintained, in particular for:
* Physical access to an unlocked device means the user data is unprotected
* The kernel
* The gonk processes such as wpa_supplicant
* The gonk libraries such as Bionic


=== Future ===
The version tracking mechanism should automatically warn the product security group based on a security feed (CVEs, Android Security upgrades)
* 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
Gdestuynder
Confirmed users
502

edits

Retrieved from "https://wiki.allizom.org/Special:MobileDiff/481499"