MozillaWiki

B2G/Architecture/System Security: Difference between revisions

Page Discussion

B2G/Architecture/System Security (view source)

Revision as of 19:53, 16 November 2013

140 bytes removed ,  16 November 2013
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.
(→‎Proposed Implementation: additional information for split encryption/unlock codes)
(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.)
 
(19 intermediate revisions by 3 users not shown)
Line 6: Line 6:
'''''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).
'''''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]].
'''''IPDL''''': Intercommunication Protocol Definition Language, see [https://wiki.mozilla.org/IPDL].


'''''AOSP''''': Android Open Source Project.
'''''AOSP''''': Android Open Source Project.
Line 12: Line 12:
'''''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.
'''''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.
'''''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)
'''''DAC, MAC''''': Discretionary Access Control (up to the user) and Mandatory Access Control (enforced by the kernel)


== [[B2G]] Runtime Security Model ==
== [[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
* 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
* 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
* 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]]
* Web application permissions and any application related security feature are not detailed here
* Expose a road-map of the upcoming system-related security features


=== Content process initialization ===
=== Road Map ===
{|
{|
|Implementation Status||Priority||Proposed ETA
||Feature||Implementation Status||Priority/Importance||
|-
|-
|Done||N/A||N/A
||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||
|}
|}


* 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).
== Features implementation details, risk analysis, discussion ==
* 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.
* Related bugs
** https://bugzilla.mozilla.org/show_bug.cgi?id=753107


=== Risks ===
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.
* 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 ===
=== Supervisor process ===
* b2g calls:
==== Risks ====
** fork()
* Parent process (b2g) is compromised, gives full device access (run as root with no restriction).
** setuid(app_0|nobody) (which is an unprivileged user)
** chrdir('/')
** execve('plugin-container')


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.
==== 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.


* File Descriptor handling:
* Select an IPC mechanism. It may use libxul for this (such as IPDL).
** 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()


Unlike the blacklist method (Close-on-exec flag: CLOEXEC), this ensures not FD is left open, and is therefore more reliable.
See also bugs (up for discussion):
* https://bugzilla.mozilla.org/show_bug.cgi?id=845736
* https://bugzilla.mozilla.org/show_bug.cgi?id=845738


== Content process sand-boxing ==
{|
|Implementation Status||Priority||Proposed ETA
|-
|N/A||High||Release 2
|}
=== 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
=== Proposed implementation ===
* All access to resources <b>must</b> happen via IPDL, this means:
** No filesystem access
** Very limited access to the kernel's system calls (no ioctl(), etc.)
** No execution of native ocode
** Fuzzing of IPDL [DONE]
Implementations of the above requirements, <u>by order of preference</u>:
==== 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.
This is the preferred implementation.
* Seccomp mode 2:
** The 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 (and/or sub-processes) exits
** 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
* Can be initialized once the process has established access to all the needed files & resources
* Sand-box escape scenarios:
** Kernel vulnerability triggered via one of the very few allowed system calls
** b2g process vulnerability triggered via IPDL


* Misc & caveats:
=== RBAC (Role Based Access Control) ===
** Requires kernel patch and kernel sources, or Linux kernel >=3.5
==== Risks ====
** Currently only available on the Nexus S AOSP sources https://bugzilla.mozilla.org/show_bug.cgi?id=790923
* Ability from the attacker to run arbitrary code on the device once a process has been compromised
** WebGL requires some security sensitive system calls such as ioctl()
* 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


==== RBAC (Role Based Access Control) ====
==== Implementation ====
RBAC is implemented by various frameworks, including SELinux, RSBAC RC, and GrSecurity RBAC.
RBAC is implemented by various frameworks, including SELinux, RSBAC RC, and GrSecurity RBAC.


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.
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 allow the framework to control the access with little or no modifications made to the running programs, unlike seccomp.
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
* Allows for extremely flexible configurations
* Restrictions are always enforced by the kernel
* 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.)
* 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:
* Sand-box escape scenarios:
** The escape scenarios always depend on the security rules
** The security provided by the framework depends entirely on the rules/policy applied to the system
** Generally, any kernel vulnerability triggered via one of the allowed systems calls, and in some cases, the ability to disable the framework
** 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
** b2g process vulnerability triggered via IPDL


* Misc & caveats:
* Misc & caveats:
** Require a custom kernel with SELinux enabled, or other solutions patched in and enabled
** 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.
** WebGL requires some security sensitive system calls such as ioctl()
** 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
==== chroot ====
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.
 
* 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
 
* 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
 
=== Proposed advanced sand-boxing improvements ===
 
* 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
 
 
== Filesystem hardening ==
{|
|Implementation Status||Priority||Proposed ETA
|-
|Done||N/A||N/A
|}
 
=== Risks ===
* Writing, deleting or reading files of another users, resulting in information leak, or unexpected behavior (privilege escalation, etc.)
* Execution of native code via an application vulnerability
* Vulnerabilities in setuid programs (and thus, privilege escalation)
 
=== Mountpoints ===
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 filesystem mounts are restricted as follow:
 
{| border="1"
|+ Mounts
|-
! Mount point !!  Filesystem !! Options
|-
| / || rootfs || read-only
|-
| /dev || tmpfs || read-write, nosuid, noexec, mode=0755
|-
| /dev/pts || ptsfs || read-write, nosuid, noexec, mode=600
|-
| /proc || proc || read-write, nosuid, nodev, noexec
|-
| /sys || sysfs || read-write, nosuid, nodev, noexec
|-
| /cache || yaffs2-or-ext4 || read-write, nosuid, nodev, noexec
|-
|| /efs || yaffs2-or-ext4 || read-only, nosuid, nodev, noexec
|-
|| /system || ext4 || read-only, nodev
|-
|| /data || ext4 || read-write, nosuid, nodev, noexec
|-
|| /mnt/sdcard || ext4-or-vfat || read-write, nosuid, nodev, noexec, uid=1000, fmask=0702, dmask=0702
|-
|| /acct || cgroup || read-write, nosuid, nodev, noexec
|-
|| /dev/cpuctl || cgroup || read-write, nosuid, nodev, noexec
|}
 
=== 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).


* The app_0/nobody user has no write access to any file
=== Disk encryption ===
* The usage of setuid binaries is limited to where necessary
==== Risks ====
* Starting processes with a sane umask
* Device is stolen and attacker has full access to the user's data storage


Due to the flexible nature of the DAC ACLs, this section is subject to regular reviews.
==== Requirements ====
* Phone should be able to dial emergency numbers even when without the decryption key


== Full disk encryption (FDE) ==
==== Proposed Implementation ====
{|
|Implementation Status||Priority||Proposed ETA
|-
|N/A||Medium||Release 2
|}


=== Risks ===
* 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).
* User device is copied in order to steal his sensitive data
** Android encrypts only the data partition
 
** Uses read-only partitions when unencrypted to ensure no data is being written
=== Proposed Implementation ===
** 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
* Android already uses FDE in a sane manner and may be copied, see http://source.android.com/tech/encryption/android_crypto_implementation.html
** Locking/Unlocking the bootloader wipes the device (all blocks to 0) and restores it to factory settings(fastboot)
** Devices are installed with the bootloader locked by default
* A user interface must be present to set the encryption password
* A user interface must be present to set the encryption password
* Allow a weaker screen lock password:
* Potential UX issues and proposed solutions
** Problem solved
** 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 very rarely use a strong phone unlocking mechanism (generally, a 4 to 8 number PIN code)
*** 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
*** User is not tempted to use a weak PIN to decrypt the phone, since decryption only occurs during phone startup (key is kept in memory afterwards)
*** 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
** Additional risks
** Additional risks
*** Weaker screen unlock mechanism (such as a PIN), can lead to access to the encrypted data
*** Weaker screen unlock mechanism (such as a PIN), can lead to access to the encrypted data
Line 220: Line 145:
*** Shutting the phone down ensures a better level of security assurance since the encryption is using a strong password
*** 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 )
*** 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 )
* Use TRESOR to store the secret key outside RAM.
** See http://www1.informatik.uni-erlangen.de/tresor for implementation on ARM.
* 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) ==
=== Address Space Layout Randomization (ASLR) ===
{|
|Implementation Status||Priority||Proposed ETA
|-
|N/A||High||Release 2
|}


=== Risks ===
==== Risks ====
* Vulnerabilities in the application's code lead to easy to guess addresses in the code, and thus easy exploitation of the vulnerability
* Loading libraries and application code at predictable or fixed addresses leads to easy exploitation of memory corruption vulnerabilities


=== Proposed Implementations ===
==== Proposed Implementations ====


* Upgrade Gonk to Jelly Bean's build system (newer GCC version, and complete ASLR support)
* Upgrade Gonk to Jelly Bean's build system (newer GCC version, and complete ASLR support)
** Faster, newer GCC, smaller performance impact from ASLR
** Faster, newer GCC, smaller performance impact from ASLR
** Full ASLR, the complete process memory image's addresses are randomized
** This provides full ASLR, no fixed or predictable addresses are used
** Require upgrading the build system
** Requires upgrading the build system


* Enable ASLR support, PIE, and linker ASLR in the current build system
* Enable ASLR support, PIE, and linker ASLR in the current build system
** Require patching of various components
** Requires patching of various components
*** Failure to do so would result in a half functioning ASLR, which is not much better than no ASLR support
*** Failure to do would result in only partial ASLR, which is no better than no ASLR
** May lead to slower process start and high performance penalties
** 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 ==
 
* Related bugs:
** https://bugzilla.mozilla.org/show_bug.cgi?id=783638
** https://bugzilla.mozilla.org/show_bug.cgi?id=715816
** https://bugzilla.mozilla.org/show_bug.cgi?id=792452
 
=== Risks ===
* Compromised update package data, resulting in an untrusted update package being installed
* Compromised update check, user does not see new updates are available
* System state compromised or unknown during the installation of the update
* Vulnerabilities in the update checking mechanism
* Lack of updates or tracking for a software component with a known vulnerability


=== Implementation ===
=== Updates: Proposed Additional Implementation: Tracking of applications versions for known security patches ===
 
* See the Security Review for the implementation information
** https://wiki.mozilla.org/Security/Reviews/B2GUpdates
 
=== Proposed Additional Implementation: Tracking of applications versions for known security patches ===
{|
|Implementation Status||Priority||Proposed ETA
|-
|N/A||High||Release 2
|}


A version tracking mechanism is necessary in order to decide when components of B2G need to be updated due to a security vulnerability.
A version tracking mechanism is necessary in order to decide when components of B2G need to be updated due to a security vulnerability.
Line 276: Line 181:


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

edits

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