System security

Terminology

Before diving into the system security model, here are a few key terms you need to understand.

Web application

A web application, open web app, moz app, or application is a program written using HTML, JavaScript, and other open Web technologies, running on Firefox OS (or any other platform that supports the same installable app model). All user-facing applications on B2G are web applications. For example, the Dialer is a Web app in Firefox OS. Pages running within the browser are not referred to as Web apps in this context.

b2g process

The Firefox OS b2g process is typically referred to as "b2g" or "Gecko". This is, essentially, an application that runs with highly elevated privileges (i.e., runs as root) and controls the access that any web application has to all resources and devices.

Content process

This is a child 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). It communicates with the Firefox OS core process using inter-process communication (IPC).

IPDL

Intercommunication Protocol Definition Language, see also IPDL.

AOSP

Android Open Source Project.

System call

An interface to talk between the user-space (processes) and the kernel. There is no other direct way for a user-space process to talk to the kernel.

DAC, MAC

Discretionary Access Control (configured by the user) and Mandatory Access Control (enforced by the kernel).

FOTA

Firmware Over The Air update system mechanism. This describes full firmware updates, generally sent "over the air", i.e. over a wireless connection to a mobile phone.

MSU, MAR

Mozilla System Updater, Mozilla ARchive. Term used to describe Gecko updates, using the same updater mechanism and archive format as Firefox Desktop.

Goals and scope of the Firefox OS system security model

The Firefox OS system security model is designed to:

• 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, from the Gonk layer.
• Web application permissions and any application related security feature is detailed in the Application Security model.

See the sections below for more detailed explanations of each of these goals, and how they're addressed by Firefox OS.

Enforcing permissions

The Application Security model describes how users grant permissions to applications, either directly or through a trusted third party.  These permissions are enforced upon the content process by enforcing any access to resource is realized via an IPC call to the core process.

• The Firefox OS core process, b2g, has very high privileges and has access to most hardware devices.
• Web applications run in a low-privileged content process and only communicate with the b2g core process using IPC, which is implemented using IPDL.
• The content process has no operating system-level access to resources.
• Each Web API has one or more associated IPDL protocol declaration file(s) (*.ipdl).
• Firefox OS content processes can only communicate through the IPDL mechanism back to the core process, which will perform actions on behalf of content.

Content process initialization

All web appplications run in a low-rights, separate process: the Firefox OS content process. This process is launched by the b2g core process when it reaches a special <iframe> type: <iframe mozapp>. This separates the web application from the rest of the content and is strongly associated to a manifest (see the Application Security model 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.

Risks

• Leak of information when spawning the web application's content process.
• Possibility of accessing operating system resources, and escalating to the same level of privileges as the b2g process.
• Bypassing the content process initialization.

Implementation

Initialization within the b2g process

In this order:

1. fork()
2. setuid(new, different, unused user id|nobody) (which is an unprivileged user)
3. chrdir('/')
4. 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

File descriptors are handled using a whitelist method; a list of permitted file descriptors (FDs) is created and stored in the mFileMap object. The LaunchApp() function forcefully closes all FDs not on the whitelist. This is done after fork() (which is when FDs are copied) but before execve() (which is when the new app starts running).

Unlike the more traditional method which uses a blacklist (close-on-exec flag: CLOEXEC), this ensures no FDs are left open; this is, therefore, more reliable.

Content process sandboxing (lowered rights content processes)

Risks

• Memory corruption or logical errors in the Gecko runtime leading to arbitrary code execution.
• Similar faults in the operating system itself (in particular, the kernel) leading to arbitrary code execution.
• Information leakage, read/write access to the file system.

This item has a threat modeling table with the sandbox enabled, in addition to the quick-recap of risks aforementioned.

Implementation

Gecko’s APIs Implementation

APIs exposed via JavaScript in the content process should never attempt to access direct filesystem resources. Instead, these should issue an IPDL call for the resource. This means that any API doing resource access must have a component in the parent process, to access the resource on the behalf of the content process.

Additional care must be taken when implementing the calls. All input must be sanitized by the parent process. The content process cannot be trusted, and the IPDL messages coming from the content process cannot be trusted.

What is seccomp

Seccomp stands for secure computing mode. There are currently 2 version of seccomp:

1. seccomp, available in Linux kernel 2.6.12 and above:

   • Enabling seccomp limits the process’s system calls to read, write, sigreturn, and exit.

   • Uses prctl() system call.

   • Can be started after process initialization, at an arbitration location.

2. seccomp-bpf, also called seccomp mode filter or mode 2, available in Linux kernel 3.5 and above:

   • Same as seccomp, but implements BPF to filter system calls.

   • Can use a whitelist of system calls & arguments when initialized, instead of hard-coded system calls.

   • More flexible, allows for a “more permissive sandbox”. Useful for slightly weaker sandboxes, and for a smooth transition path to “stricter sandbox”.

   • Adds a flag that prevents the process and child processes for reverting privileges.

Seccomp-bpf performance

seccomp-bpf impacts performance every time there is a system call. There is no exact benchmark, as the measurement depends on the implementation. We estimate that it may impact performance by up to 1% when a system call is made and seccomp-bpf is enabled for the running process. This remains to be measured by QA.

Since the number of system calls is greatly reduced in our process model, we also predict the real-world performance impact should be nearly null.

IPDL calls may however add latency and reduce performance, depending on their implementation. It is highly recommended to look at Chromium’s implementation for resource-intensive APIs such as OpenGL calls. In a similar fashion to seccomp-bpf, if we minimize the number of IPDL calls we will minimize the impacts to performance.

Implementation

seccomp is enabled in Gecko with --enable-content-sandbox.

The reporter, which reports denied system calls (if any) is never built by default and is enabled with --enable-content-sandbox-reporter.

The bulk of the code is in gecko/security/sandbox. The whitelist itself is stored in gecko/security/sandbox/seccomp_filter.h.

The whitelist may contain system calls that can be used the compartimentization. Generally, those calls have comments indicating why, and should eventually be removed when the affected code is fixed. Therefore, it's almost never OK to add code that will break the sandbox, then add the call in the whitelist without very careful consideration. In doubt, raise a bug. Most of the time however, this is incorrect, and the resource should instead be controlled, accessed by the b2g process, then passed to the content process if access is granted and/or data is sanitized.

File system hardening

Risks

• Writing, deleting or reading files belonging to another user; this could result in an information leak or unexpected behavior such as privilege escalation.
• Execution of native code through an application vulnerability.
• Vulnerabilities in setuid programs (and thus, privilege escalation).

Implementation

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, and noexec options. The standard filesystem mounts are restricted as follows:

Linux DAC

The Linux DAC represents the well-known Linux filesystem permission model.

• The web application system user has no write access to any file.
• The usage of setuid binaries is limited to where necessary.
• New content processes are started with a sane umask.

Secure system 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 gets an out of date package as an update, which effectively downgrades the software on the device.
• System state compromised or unknown during the installation of the update; this may (for example) 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

Subsequent upgrades and patches to the Firefox OS platform are deployed using a secure Mozilla process that ensures the ongoing integrity of the system image on the mobile phone. The update is created by a known, trusted source — usually the device OEM — that is responsible for assembling, building, testing, and digitally signing the update package.

Firmware over the air updates

System updates can involve all or a portion of the Firefox OS stack. If changes to Gonk are included in the update, then FOTA (Firmware Over the Air) is the install process used. FOTA updates can also include any other part of the Firefox OS stack, including device management (FOTA, firmware / drivers), settings management (Firefox OS settings), security updates, Gaia, Gecko, and other patches.

MSU/MAR updates

Updates that do not involve Gonk can be done using the Mozilla System Update Utility. Firefox OS uses the same update framework, processes, and Mozilla ARchive (MAR) format (used for update packages) as the Firefox Desktop product.

Update service

A built-in update service on the mobile phone periodically checks for system updates. Once a system package becomes available and is detected by the update service, the user is prompted to confirm installation. Before updates are installed on the mobile device, the device storage is checked for sufficient space to apply the update, and the distribution is verified for:

• Update origin (verify the source location protocol:domain:port of the system update and manifest).
• File integrity (cryptographic hash checksums).
• Code signature (certificate check against a trusted root).

The following security measures are used during the update process:

• Mozilla recommends and expects that updates are fetched over an SSL connection with a trusted certificate.
• Strong cryptographic verification is required before installing a firmware package.
• The complete update must be downloaded in a specific and secure location before the update process begins.
• The system must be in a secure state when the update process starts, with no web applications running.
• The keys must be stored in a secure location on the device.

Rigorous checks are in place to ensure that the update is applied properly to the mobile phone.