B2G/Architecture/System Security

From MozillaWiki
< B2G‎ | Architecture
Revision as of 01:23, 2 November 2012 by Gdestuynder (talk | contribs)
Jump to navigation Jump to search

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 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
  • 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.
  • Related bugs

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 content process initialization

Implementation

  • b2g calls:
    • fork()
    • 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 rights user that cannot elevate its privileges to the level of the b2g process.

  • 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()

Unlike the method which uses a blacklist (Close-on-exec flag: CLOEXEC), this ensures not FD is left open, and is therefore more reliable.

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

Implementations of the above requirements, by order of mitigation strength:

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, additionally system 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
  • Seccomp can be activated after the process has initialized and already accessed its normally

needed 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 (Role Based Access Control)

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.

  • Allows for extremely flexible configurations
  • Restrictions are always enforced by the kernel
  • Restrictions can also be configured for other system processes and therefore sand-boxing of other processes as well (wpa_supplicant, init, etc.)
  • 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
    • 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 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

Proposed advanced sand-boxing improvements

  • Use of ARM TrustZones (TZ), which implements hardware virtualization and strong 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 amount of effort needed to implement
    • 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 belonging to another 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 requires a new read-write area in the future), and must include nodev, nosuid, noexec options. The filesystem mounts are restricted as follow:

Mounts
Mount point Filesystem Options
/ rootfs read-only
/dev tmpfs read-write, nosuid, noexec, mode=0644
/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
  • The usage of setuid binaries is limited to where necessary
  • Starting processes with a sane umask

Due to the flexible nature of the DAC ACLs, this section is subject to regular reviews.

Full disk encryption (FDE)

Implementation Status Priority Proposed ETA
N/A Medium Release 2

Risks

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

Proposed Implementation

  • Android already uses FDE in a sane manner and their approach may be re-used, see http://source.android.com/tech/encryption/android_crypto_implementation.html
    • 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

    • Additional risks
      • Weaker screen unlock mechanism (such as a PIN), can lead to access to the encrypted data
    • Rationale

Address Space Layout Randomization (ASLR)

Implementation Status Priority Proposed ETA
N/A High Release 2

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

Updates

Risks

  • Compromised update package data, resulting in an untrusted update package being installed
  • Compromised update check
    • 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 mechanism running on the device
  • Lack of updates or tracking for a software component with a known vulnerability

Implementation

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

Implementation Status Priority Proposed ETA
N/A Medium Unknown

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
Retrieved from "https://wiki.allizom.org/index.php?title=B2G/Architecture/System_Security&oldid=484559"