B2G/Architecture/System Security: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
(Updated for SELinux as Android supports SELinux in 4.3/4.4. Also updated how it's related to seccomp since we have seccomp now.)
 
(24 intermediate revisions by 3 users not shown)
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].
This document primarily covers the security model and hardening applied to the [[B2G]] runtime.
== Terminology ==
== Terminology ==
'''''Web application''''': An HTML/JS application started within a content process. All user-facing applications on B2G are web applications.


'''''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 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)


'''''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.
'''''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).


'''''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.
'''''IPDL''''': Intercommunication Protocol Definition Language, see [https://wiki.mozilla.org/IPDL].


The goals of the [[B2G]] runtime security model are to:
'''''AOSP''''': Android Open Source Project.


* enforce the permissions granted to Web Apps
'''''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.
* 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 ==
'''''system call''''': An interface to talk between the user-space(processes) and the kernel. There is no other way for a user-space process to talk to the kernel.


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.
'''''DAC, MAC''''': Discretionary Access Control (up to the user) and Mandatory Access Control (enforced by the kernel)
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
== [[B2G]] System Security Model ==
* 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.
Current implementation is documented at https://developer.mozilla.org/en-US/docs/Mozilla/Firefox_OS/Security/System_security
* 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 ===
[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.
Global tracking bug https://bugzilla.mozilla.org/show_bug.cgi?id=862082
* 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 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.
== 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:
=== Goals and scope of this document ===
* Extend the security measures documented on https://developer.mozilla.org/en-US/docs/Mozilla/Firefox_OS/Security/System_security
* 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 are not detailed here
* Expose a road-map of the upcoming system-related security features


* Memory corruption or logical errors in Gecko leading to arbitrary code execution
=== Road Map ===
* Similar faults in the operating system itself (kernel and daemons) leading to arbitrary code execution
{|
* Compromise of the update mechanism used
||Feature||Implementation Status||Priority/Importance||
* Hijacking another web application (XSS, or memory corruption for example)
|-
* IPDL vulnerability
||Seccomp||https://bugzilla.mozilla.org/show_bug.cgi?id=790923 (ASAP)||High||
|-
||GL Proxy||N/A||High||
|-
||Supervisor process||https://bugzilla.mozilla.org/show_bug.cgi?id=845191 (Soon)||High||
|-
||RBAC (MAC)||N/A|Medium||
|-
||Disk Encryption||https://bugzilla.mozilla.org/show_bug.cgi?id=777917||Medium||
|-
||ASLR||https://bugzilla.mozilla.org/show_bug.cgi?id=777948 (Soon)||Medium||
|-
||Compiler hardening||https://bugzilla.mozilla.org/show_bug.cgi?id=620058||Medium||
|-
||JIT hardening||https://bugzilla.mozilla.org/show_bug.cgi?id=677272||Low||
|-
||Implement automated compliance testing of security features||N/A||Medium||
|-
||Integrity measurements||N/A|Low||
|}
 
== Features implementation details, risk analysis, discussion ==
 
Features get scoped here, before going into a tracking bug if they're selected to be worked on. Each feature should in general include some sort of risk analysis (or a threat model), and some implementation details.
 
=== Supervisor process ===
==== Risks ====
* Parent process (b2g) is compromised, gives full device access (run as root with no restriction).
 
==== Implementation ====
* Create a new, small footprint process called "Supervisor".
** Supervisor provides the following features:
*** Start system update (Any kind of - Gecko and full system updates)
*** Shutdown, Reboot system
*** Adjust process priorities (nice/renice)
*** Adjust OOM killer values (oom_adjust)
*** Possibly, load kernel modules at process startup. If not, the init process should take care of starting the necessary scripts for this task.
*** Drop privileges of spawned subprocesses
** Supervisor DOES NOT provide the following features:
*** XPCOM
*** JS runtime
*** Any other such gecko feature. This is not gecko. It MAY link to libxul and use a subset of features for IPC communication only.
* the b2g process should run as system:system instead of root:root.
* the supervisor process should run as root:root.


The approach to mitigation of the two code execution threats is:
* Select an IPC mechanism. It may use libxul for this (such as IPDL).


* Hardening gecko against attack (the same approach as for Firefox)
See also bugs (up for discussion):
* Run web content in lower-rights child processes to reduce the impact of process compromise (the B2G content process explained in the previous section)
* https://bugzilla.mozilla.org/show_bug.cgi?id=845736
* Harden the underlying OS to make post-exploitation more difficult
* https://bugzilla.mozilla.org/show_bug.cgi?id=845738
* Use the hardening features of the compiler when possible


=== Process model and separation (sandboxing, etc.) ===


As previously specified the B2G process model is based on:
=== RBAC (Role Based Access Control) ===
* One B2G core process (parent) which has access to all hardware, devices etc
==== Risks ====
* 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]
* Ability from the attacker to run arbitrary code on the device once a process has been compromised
* Ability from the attacker to use a process in an unintended way and access resources that the Linux DAC cannot control access to
* In some cases, ability from the attacker to exploit the kernel through vulnerable system calls, that the processes normally wouldn't use


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.
==== Implementation ====
RBAC is implemented by various frameworks, including SELinux, RSBAC RC, and GrSecurity RBAC.


Compromising a B2G content process can still lead to the access of application's permissions running in the same B2G content process.
These frameworks are generally called Mandatory Access Control frameworks (MAC), allow setting white-lists of systems calls on 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.
This allows the framework to control the access with little to no modification of the running program, unlike seccomp.
Both SELinux and seccomp enforce their policies by controlling system calls at the kernel level.


We are Investigating seccomp mode 2 (require kernel patch for < 3.5) in order to allow:
* Allows for extremely flexible configurations
recv, send, exit (+any other whitelisted system call necessary for WebGL, such as mmap) for B2G content processes.
* Restrictions are always enforced by the kernel
* Restrictions can also be configured for any  process and therefore sand-boxing of the non-b2g processes (wpa_supplicant, init, etc.)
* Restrictions can be configured for the B2G process, even thus it's running as root
* Restrictions to the content-processes make little sense when seccomp-bpf is already being used.
** Further decrease performance
** Does not lock down the content-process more strictly than seccomp
** Similar checks being performed
* Possible to target only some processes (targeted policy), albeit a complete policy (all processes, no exception) is preferred from the security point of view.


Any other system call is denied by the kernel for B2G content processes.
* Sand-box escape scenarios:
** The security provided by the framework depends entirely on the rules/policy applied to the system
** Any kernel vulnerability triggered via an allowed system call - this may also lead to the ability to disable the MAC framework
** b2g process vulnerability triggered via IPDL


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).
* Misc & caveats:
** Requires a custom kernel with SELinux enabled, or other kernel patch based solution built and enabled, until Android 4.3 and 4.4 based Gonk, which has SELinux enabled kernels, userspace tools and an Android-only policy.
** Security policy can be extensive and eventually require modifications to run on different devices.
** Security policy from Android most likely needs large changes to run with B2G, and to be taken advantage of for B2G


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.
=== Disk encryption ===
==== Risks ====
* Device is stolen and attacker has full access to the user's data storage


==== Future ====
==== Requirements ====
* The goal is to have a finer level of separation between various software components, in particular the B2G core process's components
* Phone should be able to dial emergency numbers even when without the decryption key
** 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  provides a reference implementation and recommendations for OS security controls.
==== Proposed Implementation ====
* Filesystem privileges enforced by Linux's ACLs
** 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
* 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"
* Android already uses disk encryption in a relatively sane manner and their approach may be re-used, see http://source.android.com/tech/encryption/android_crypto_implementation.html - Password handling should be revisited (different encryption/unlock passwords, better derivation of the password, as Android needs a very long password to resist brute force attacks).
|+ Mounts
** Android encrypts only the data partition
|-
** Uses read-only partitions when unencrypted to ensure no data is being written
! Mount point !!  Filesystem !! Options
** Locking/Unlocking the bootloader wipes the device and restores it to factory settings, this is enforced by fastboot
|-
** Devices are shipped with the bootloader locked by default
| / || rootfs || read-only
* A user interface must be present to set the encryption password
|-
* Potential UX issues and proposed solutions
| /dev || tmpfs || read-write, nosuid, noexec, mode=0755
** Allow a weaker screen lock password:
|-
*** Unlocking the phone screen is done several times a day, sometimes several times within a few minutes, thus users rarely use a secure mechanism for their screen lock
| /dev/pts || ptsfs || read-write, nosuid, noexec, mode=600
*** Users are not tempted to use a weak PIN/password for FDE, since they are only asked for the FDE password at phone startup, not
|-
every time they want to unlock their phone and use it
| /proc || proc || read-write, nosuid, nodev, noexec
** Additional risks
|-
*** Weaker screen unlock mechanism (such as a PIN), can lead to access to the encrypted data
| /sys || sysfs || read-write, nosuid, nodev, noexec
** Rationale
|-
*** It is currently harder to crack a PIN on a running device (no brute force input available)
| /cache || yaffs2-or-ext4 || read-write, nosuid, nodev, noexec
*** Shutting the phone down ensures a better level of security assurance since the encryption is using a strong password
|-
*** Using a PIN for encryption generally renders the encryption useless as those can be cracked in seconds (see for example https://viaforensics.com/viaextract/viaextract-includes-android-encryption-cracking.html )
|| /efs || yaffs2-or-ext4 || read-only, nosuid, nodev, noexec
* Use TRESOR to store the secret key outside RAM.
|-
** See http://www1.informatik.uni-erlangen.de/tresor for implementation on ARM.
|| /system || ext4 || read-only, nodev
 
|-
* ChromeOS uses a slightly different disk encryption mechanism using eCryptFS.
|| /data || ext4 || read-write, nosuid, nodev, noexec
** ChromeOS only encrypts the user's home directory.
|-
 
|| /mnt/sdcard || ext4-or-vfat || read-write, nosuid, nodev, noexec, uid=1000, fmask=0702, dmask=0702
* FDE (Full Disk Encryption)
|-
** Requires a fast CPU or hardware acceleration
|| /acct || cgroup || read-write, nosuid, nodev, noexec
** Ensures no data is left unencrypted on the flash device
|-
 
|| /dev/cpuctl || cgroup || read-write, nosuid, nodev, noexec
=== Address Space Layout Randomization (ASLR) ===
|}
 
==== Risks ====
* Loading libraries and application code at predictable or fixed addresses leads to easy exploitation of memory corruption vulnerabilities
 
==== Proposed Implementations ====


* 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.
* Upgrade Gonk to Jelly Bean's build system (newer GCC version, and complete ASLR support)
* Mount points path may vary
** Faster, newer GCC, smaller performance impact from ASLR
** This provides full ASLR, no fixed or predictable addresses are used
** Requires upgrading the build system


* Enable ASLR support, PIE, and linker ASLR in the current build system
** Requires patching of various components
*** Failure to do would result in only partial ASLR, which is no better than no ASLR
** May lead to slower process startup and high performance penalties - however, recent builds of B2G pre-start a content-process, which may hide any performance penalty


==== Future ====
=== Updates: Proposed Additional Implementation: Tracking of applications versions for known security patches ===


* Investigate CoreBoot secure boot support (ala ChromeOS) http://review.coreboot.org/gitweb?p=coreboot.git;a=commit;h=9aea04aa892903009e487ada7f7b911691e68630 or enhancements to fastboot
A version tracking mechanism is necessary in order to decide when components of B2G need to be updated due to a security vulnerability.
* See also: http://www.chromium.org/chromium-os/chromiumos-design-docs/system-hardening
A list of the currently installed applications in Gonk must therefore be maintained, in particular for:
* Investigate running full ASLR with better performance
* The kernel
* The gonk processes such as wpa_supplicant
* The gonk libraries such as Bionic


==== OS Update ====
The version tracking mechanism should automatically warn the product security group based on a security feed (CVEs, Android Security upgrades)


OS updates includes everything except Gecko, which has its own update process (see below).
==== Issues ====
OS updates are issued when a user-impacting bug or a security bug is found, or when a required for a B2G major upgrade.
* This part of B2G may differ and generally be handled by a third party, such as a vendor or carrier, thus, they must be the ones running the tracking software
* The tracking software may however be provided to them, with guidance, for example
* Guidance on updates may also be provided instead


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.
=== Sandbox implementations that were not selected (kept for reference) ===
This method is also used when method 2) fails (power issue, hardware failure, etc.) and "brick" the device.
==== rlimit sandbox ====
* 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.
rlimit() is a system call that can be used to deny file and process creation. Like chroot(), this may be used as long as no privileged user (such as root) is running any process that is being rlimit'ed.


However:
* Relatively easy to implement, supported by various operating systems
* Strong crypto signature verification is required before installing those packages
** RLIMIT_FSIZE = 0 requires that no file is written to (within the process) - this can already works
* The complete update must be downloaded in a specific and secure location before the update process starts
** RLIMIT_NOFILE = 0 requires that no new file descriptor is opened (within the process)
* The system must be in a secure state when the update process starts (no Web Apps running)
** RLIMIT_NPROC = 0 requires that no new thread of process is created (within the process)
* The keys must be stored in a secure location on the device
* Does not require kernel modifications
* Used as fall-back sand-box in other programs, such as OpenSSH


==== B2G Update ====
* Sand-box escape scenario:
** Kernel vulnerability (any)
** Loading code directly in memory (instead of executing, for example, /bin/sh), then finding user-space vulnerabilities in other processes
** Privilege escalation to root/privileged user, then disable rlimits
** User-land vulnerability via any kind of IPC
** b2g process vulnerability triggered via IPDL


B2G updates itself using the same mechanism as Firefox on the desktop.
==== chroot ====
* The updates are fetched over SSL
chroot() is a well-known system call, which changes the view of the root filesystem of the process.
* SSL certificate's issuer names are pinned in B2G
This system call is not explicitly designed to secure access to the file system but may be used in this fashion as long no privileged user (such as root) is running any process within the chroot after the process has been initialized.
* 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 ==
* Can be initialized after the process has already accessed all its needed files and resources, although the process must
* 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
still be running as root when calling chroot() or must have all needed files located inside the chroot directory). See https://bugzilla.mozilla.org/show_bug.cgi?id=776648.
* Physical access to an unlocked device means the user data is unprotected
** Linux namespaces can be used in combination with the chroot in order to reduce the amount of code changes or files copied
* While chroot() restricts a process' view of the filesystem, it enforces no other restrictions. All system calls are still available to the process.
* Does not require kernel modifications


=== Future ===
* Sand-box escape scenario:
* Full disk encryption is recommended
** Kernel vulnerability (any)
** Encryption depends on the device's password which can be a useability issue
** User-land vulnerability via any kind of IPC
** Investigate the option of unlocking at boot time only (less secure, but not too bad), possibly via a configuration option
** 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
** Users could also forget their encryption password more easily
** b2g process vulnerability triggered via IPDL

Latest revision as of 19:53, 16 November 2013

Terminology

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 [1].

AOSP: Android Open Source Project.

Proposed <*>: This means the section has NOT 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 process to talk to the kernel.

DAC, MAC: Discretionary Access Control (up to the user) and Mandatory Access Control (enforced by the kernel)

B2G System Security Model

Current implementation is documented at https://developer.mozilla.org/en-US/docs/Mozilla/Firefox_OS/Security/System_security

Global tracking bug https://bugzilla.mozilla.org/show_bug.cgi?id=862082

Goals and scope of this document

  • Extend the security measures documented on https://developer.mozilla.org/en-US/docs/Mozilla/Firefox_OS/Security/System_security
  • 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 are not detailed here
  • Expose a road-map of the upcoming system-related security features

Road Map

Feature Implementation Status Priority/Importance
Seccomp https://bugzilla.mozilla.org/show_bug.cgi?id=790923 (ASAP) High
GL Proxy N/A High
Supervisor process https://bugzilla.mozilla.org/show_bug.cgi?id=845191 (Soon) High
RBAC (MAC) Medium
Disk Encryption https://bugzilla.mozilla.org/show_bug.cgi?id=777917 Medium
ASLR https://bugzilla.mozilla.org/show_bug.cgi?id=777948 (Soon) Medium
Compiler hardening https://bugzilla.mozilla.org/show_bug.cgi?id=620058 Medium
JIT hardening https://bugzilla.mozilla.org/show_bug.cgi?id=677272 Low
Implement automated compliance testing of security features N/A Medium
Integrity measurements Low

Features implementation details, risk analysis, discussion

Features get scoped here, before going into a tracking bug if they're selected to be worked on. Each feature should in general include some sort of risk analysis (or a threat model), and some implementation details.

Supervisor process

Risks

  • Parent process (b2g) is compromised, gives full device access (run as root with no restriction).

Implementation

  • Create a new, small footprint process called "Supervisor".
    • Supervisor provides the following features:
      • Start system update (Any kind of - Gecko and full system updates)
      • Shutdown, Reboot system
      • Adjust process priorities (nice/renice)
      • Adjust OOM killer values (oom_adjust)
      • Possibly, load kernel modules at process startup. If not, the init process should take care of starting the necessary scripts for this task.
      • Drop privileges of spawned subprocesses
    • Supervisor DOES NOT provide the following features:
      • XPCOM
      • JS runtime
      • Any other such gecko feature. This is not gecko. It MAY link to libxul and use a subset of features for IPC communication only.
  • the b2g process should run as system:system instead of root:root.
  • the supervisor process should run as root:root.
  • Select an IPC mechanism. It may use libxul for this (such as IPDL).

See also bugs (up for discussion):


RBAC (Role Based Access Control)

Risks

  • Ability from the attacker to run arbitrary code on the device once a process has been compromised
  • Ability from the attacker to use a process in an unintended way and access resources that the Linux DAC cannot control access to
  • In some cases, ability from the attacker to exploit the kernel through vulnerable system calls, that the processes normally wouldn't use

Implementation

RBAC is implemented by various frameworks, including SELinux, RSBAC RC, and GrSecurity RBAC.

These frameworks are generally called Mandatory Access Control frameworks (MAC), allow setting white-lists of systems calls on 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. This allows the framework to control the access with little to no modification of the running program, unlike seccomp. Both SELinux and seccomp enforce their policies by controlling system calls at the kernel level.

  • Allows for extremely flexible configurations
  • Restrictions are always enforced by the kernel
  • Restrictions can also be configured for any process and therefore sand-boxing of the non-b2g processes (wpa_supplicant, init, etc.)
  • Restrictions can be configured for the B2G process, even thus it's running as root
  • Restrictions to the content-processes make little sense when seccomp-bpf is already being used.
    • Further decrease performance
    • Does not lock down the content-process more strictly than seccomp
    • Similar checks being performed
  • Possible to target only some processes (targeted policy), albeit a complete policy (all processes, no exception) is preferred from the security point of view.
  • Sand-box escape scenarios:
    • The security provided by the framework depends entirely on the rules/policy applied to the system
    • Any kernel vulnerability triggered via an allowed system call - this may also lead to the ability to disable the MAC framework
    • b2g process vulnerability triggered via IPDL
  • Misc & caveats:
    • Requires a custom kernel with SELinux enabled, or other kernel patch based solution built and enabled, until Android 4.3 and 4.4 based Gonk, which has SELinux enabled kernels, userspace tools and an Android-only policy.
    • Security policy can be extensive and eventually require modifications to run on different devices.
    • Security policy from Android most likely needs large changes to run with B2G, and to be taken advantage of for B2G

Disk encryption

Risks

  • Device is stolen and attacker has full access to the user's data storage

Requirements

  • Phone should be able to dial emergency numbers even when without the decryption key

Proposed Implementation

  • Android already uses disk encryption in a relatively sane manner and their approach may be re-used, see http://source.android.com/tech/encryption/android_crypto_implementation.html - Password handling should be revisited (different encryption/unlock passwords, better derivation of the password, as Android needs a very long password to resist brute force attacks).
    • Android encrypts only the data partition
    • Uses read-only partitions when unencrypted to ensure no data is being written
    • Locking/Unlocking the bootloader wipes the device and restores it to factory settings, this is enforced by fastboot
    • Devices are shipped with the bootloader locked by default
  • A user interface must be present to set the encryption password
  • Potential UX issues and proposed solutions
    • Allow a weaker screen lock password:
      • Unlocking the phone screen is done several times a day, sometimes several times within a few minutes, thus users rarely use a secure mechanism for their screen lock
      • Users are not tempted to use a weak PIN/password for FDE, since they are only asked for the FDE password at phone startup, not

every time they want to unlock their phone and use it

  • ChromeOS uses a slightly different disk encryption mechanism using eCryptFS.
    • ChromeOS only encrypts the user's home directory.
  • FDE (Full Disk Encryption)
    • Requires a fast CPU or hardware acceleration
    • Ensures no data is left unencrypted on the flash device

Address Space Layout Randomization (ASLR)

Risks

  • Loading libraries and application code at predictable or fixed addresses leads to easy exploitation of memory corruption vulnerabilities

Proposed Implementations

  • Upgrade Gonk to Jelly Bean's build system (newer GCC version, and complete ASLR support)
    • Faster, newer GCC, smaller performance impact from ASLR
    • This provides full ASLR, no fixed or predictable addresses are used
    • Requires upgrading the build system
  • Enable ASLR support, PIE, and linker ASLR in the current build system
    • Requires patching of various components
      • Failure to do would result in only partial ASLR, which is no better than no ASLR
    • May lead to slower process startup and high performance penalties - however, recent builds of B2G pre-start a content-process, which may hide any performance penalty

Updates: Proposed Additional Implementation: Tracking of applications versions for known security patches

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 currently installed applications in Gonk must therefore be maintained, in particular for:

  • The kernel
  • The gonk processes such as wpa_supplicant
  • The gonk libraries such as Bionic

The version tracking mechanism should automatically warn the product security group based on a security feed (CVEs, Android Security upgrades)

Issues

  • This part of B2G may differ and generally be handled by a third party, such as a vendor or carrier, thus, they must be the ones running the tracking software
  • The tracking software may however be provided to them, with guidance, for example
  • Guidance on updates may also be provided instead


Sandbox implementations that were not selected (kept for reference)

rlimit sandbox

rlimit() is a system call that can be used to deny file and process creation. Like chroot(), this may be used as long as no privileged user (such as root) is running any process that is being rlimit'ed.

  • Relatively easy to implement, supported by various operating systems
    • RLIMIT_FSIZE = 0 requires that no file is written to (within the process) - this can already works
    • RLIMIT_NOFILE = 0 requires that no new file descriptor is opened (within the process)
    • RLIMIT_NPROC = 0 requires that no new thread of process is created (within the process)
  • Does not require kernel modifications
  • Used as fall-back sand-box in other programs, such as OpenSSH
  • Sand-box escape scenario:
    • Kernel vulnerability (any)
    • Loading code directly in memory (instead of executing, for example, /bin/sh), then finding user-space vulnerabilities in other processes
    • Privilege escalation to root/privileged user, then disable rlimits
    • User-land vulnerability via any kind of IPC
    • b2g process vulnerability triggered via IPDL

chroot

chroot() is a well-known system call, which changes the view of the root filesystem of the process. This system call is not explicitly designed to secure access to the file system but may be used in this fashion as long no privileged user (such as root) is running any process within the chroot after the process has been initialized.

  • Can be initialized after the process has already accessed all its needed files and resources, although the process must

still be running as root when calling chroot() or must have all needed files located inside 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() restricts a process' view of the filesystem, it enforces no other restrictions. All system calls are still available to the process.
  • Does not require kernel modifications
  • 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
Retrieved from "https://wiki.allizom.org/index.php?title=B2G/Architecture/System_Security&oldid=763454"