B2G/Architecture/System Security

From MozillaWiki
< B2G‎ | Architecture
Revision as of 00:13, 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 /IPDL.

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 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.
  • 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 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 right user, that cannot elevate it's 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 blacklist method (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

  • All access to resources must 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, by order of preference:

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

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), 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. This allow the framework to control the access with little or no modifications made to the running programs, 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 sand-boxing of other processes (wpa_supplicant, init, etc.)
  • Sand-box escape scenarios:
    • The escape scenarios always depend on the security rules
    • Generally, any kernel vulnerability triggered via one of the allowed systems calls, and in some cases, the ability to disable the framework
    • b2g process vulnerability triggered via IPDL
  • 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()

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:

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

  • User device is copied in order to steal his sensitive data

Proposed Implementation

  • 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
  • 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 mechanism (generally, a 4 to 8 number PIN code)
      • 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)
    • 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

  • Vulnerabilities in the application's code lead to easy to guess addresses in the code, and thus easy exploitation of the vulnerability

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 ASLR, the complete process memory image's addresses are randomized
    • Require upgrading the build system
  • Enable ASLR support, PIE, and linker ASLR in the current build system
    • Require patching of various components
      • Failure to do so would result in a half functioning ASLR, which is not much better than no ASLR support
    • May lead to slower process start 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
  • 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

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=484554"