Confirm
502
edits
Changes
Typos, etc. Fixes comes from :imelven. Thanks!
'''''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 [[https://wiki.mozilla.org/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 process 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 ==
=== Goals and scope of this document ===
* 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
* 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 content process initialization
=== Implementation ===
** execve('plugin-container')
This ensures the OOP process runs in a separate memory space (new process) and as a low right rights user, that cannot elevate it's its privileges to the level of the b2g process.
* File Descriptor handling:
** White list method** A - 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 method which uses a blacklist method (Close-on-exec flag: CLOEXEC), this ensures not FD is left open, and is therefore more reliable.
== Content process sand-boxing ==
** No filesystem access
** Very limited access to the kernel's system calls (no ioctl(), etc.)
** No execution of native ocodecode** Fuzzing of IPDL [DONE]*** See https://bugzilla.mozilla.org/show_bug.cgi?id=516716
Implementations of the above requirements, <u>by order of preferencemitigation strength</u>:
==== Seccomp ====
** 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 additionally system call calls can be white-listed based on the value of their arguments
* File system access, spawning of processes, access to most resources is nonexistent without escaping the sand-box
* Can Seccomp can be initialized once activated after the process has established access to all the initialized and already accessed its normallyneeded files & and resources, making the process of creating a white-list much easier
* Sand-box escape scenarios:
** Kernel vulnerability triggered via one of the very few allowed system calls, this may also lead to the ability to disable seccomp
** b2g process vulnerability triggered via IPDL
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 setting white-lists of system systems calls to 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 allows the framework to control the access with little or to no modifications made to modification of the running programsprogram, unlike seccomp.
* Allows for extremely flexible configurations
* Restrictions are always enforced by the kernel
* Restrictions can also be configured for other system processes and thus therefore sand-boxing of other processes as well (wpa_supplicant, init, etc.)
* Sand-box escape scenarios:
** The escape scenarios always depend security provided by the framework depends entirely on the security rules/policy applied to the system** Generally, any Any kernel vulnerability triggered via one of the an allowed systems calls, and in some cases, system call - this may also lead to the ability to disable the MAC framework
** b2g process vulnerability triggered via IPDL
* Misc & caveats:
** Require Requires a custom kernel with SELinux enabled, or other solutions patched in kernel patch based solution built and enabled
** WebGL requires some security sensitive system calls such as ioctl()
==== 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 explicitly designed to secure access to the file system access, but may be used in that this fashion, as long no privileged user (such as root) runs is running any process within the chrootafter the process has been initialized.
* Can be initialized once after the process has established access to already accessed all the its needed files & and resources, if although the program is modified to do so, as the program has to process muststill be running as root when calling chroot() is called (or to must have all needed files available in 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() provides restricts a different process' view of the filesystem, it does not provide any enforces no other separationrestrictions. All system calls are still available to the process.
* Does not require kernel modifications
=== Proposed advanced sand-boxing improvements ===
* Use of ARM TrustZones (TZ), which implements hardware virtualization and strong resources resource 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 taskamount of effort needed to implement
** May reduce execution speed of WebGL code
== Filesystem hardening ==
=== Risks ===
* Writing, deleting or reading files of belonging to another users, resulting user - this could result in an information leak, or unexpected behavior (, eg. 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 requires a new read-write area in the future), and must include nodev, nosuid, noexec options.
The filesystem mounts are restricted as follow:
| / || rootfs || read-only
|-
| /dev || tmpfs || read-write, nosuid, noexec, mode=07550644
|-
| /dev/pts || ptsfs || read-write, nosuid, noexec, mode=600
=== 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).
=== Risks ===
* User device Device is copied in order stolen and attacker has full access to steal his sensitive the user's datastorage
=== Proposed Implementation ===
* Android already uses FDE in a sane manner and their approach may be copiedre-used, 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(, this is enforced by fastboot)** Devices are installed 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:** Problem solved*** 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 secure mechanism (generally, a 4 to 8 number PIN code)for their screen lock*** User is Users are not tempted to use a weak PIN to decrypt the phone/password for FDE, since decryption they are only occurs during asked for the FDE password at phone startup (key is kept in memory afterwards), not every time they want to unlock their phone and use it
** Additional risks
*** Weaker screen unlock mechanism (such as a PIN), can lead to access to the encrypted data
=== Risks ===
* Vulnerabilities in the Loading libraries and application's code lead to easy at predictable or fixed addresses leads to guess addresses in the code, and thus easy exploitation of the vulnerabilitymemorycorruption 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
** Full This provides full ASLR, the complete process memory image's no fixed or predictable addresses are randomizedused** Require Requires upgrading the build system
* Enable ASLR support, PIE, and linker ASLR in the current build system
** Require Requires patching of various components*** Failure to do so would result in a half functioning only partial ASLR, which is not much no better than no ASLR support** May lead to slower process start startup and high performance penalties
== Updates ==
=== Risks ===
* Compromised update package data, resulting in an untrusted update package being installed
* Compromised update check, user ** User does not see new updates are available** User is gets an out of date package as update, which effectively downgrade the software on his device* System state compromised or unknown during the installation of the update, for example, this may lead to:** Missing elements during the installation, some of which may be security fixes** Security fixes reverted by the compromised system after upgrade* Vulnerabilities in the update checking mechanismrunning on the device
* Lack of updates or tracking for a software component with a known vulnerability
