System security

  • Revision slug: Mozilla/Firefox_OS/Security/System_security
  • Revision title: System security
  • Revision id: 364763
  • Created:
  • Creator: Sheppy
  • Is current revision? No
  • Comment

Revision Content

This article provides an overview of the Firefox OS sytem security model; that is, it explains how the operating system provides security and enforces permissions.

Terminology

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

Web application
A web application, web app, moz app, or application is a program written using HTML, JavaScript, and other open Web technologies, running on Firefox OS. 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. Term used to describe 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 {{HTMLElement("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, escalate 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.

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:

Mount point File system Options
/ rootfs read-only
/dev tmpfs read-write, nosuid, noexec, mode=0755
/dev/pts ptsfs read-write, nosuid, noexec, mode=0600
/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-write, 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

Note: The exact mount points may vary.

Linux DAC

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

Note: This is the traditional user/group/others permission model and not the Linux POSIX 1.e ACLs

  • 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. For more information, see {{interwiki("wikimo", "Software Update")}}.

Update service

Note: The update service may be provided by the OEM.

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.

Revision Source

<p>This article provides an overview of the Firefox OS sytem security model; that is, it explains how the operating system provides security and enforces permissions.</p>
<h2 id="Terminology">Terminology</h2>
<p>Before diving into the system security model, here are a few key terms you need to understand.</p>
<dl>
  <dt>
    Web application</dt>
  <dd>
    A <strong>web application</strong>, <strong>web app</strong>, <strong>moz app</strong>, or <strong>application</strong> is a program written using <a href="/en-US/docs/HTML" title="/en-US/docs/HTML">HTML</a>, <a href="/en-US/docs/JavaScript" title="/en-US/docs/JavaScript">JavaScript</a>, and other open Web technologies, running on Firefox OS. 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.</dd>
  <dt>
    b2g process</dt>
  <dd>
    The Firefox OS <strong>b2g process</strong> is typically referred to as "<strong>b2g</strong>" 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.</dd>
  <dt>
    Content process</dt>
  <dd>
    This is a child process spawned by the <strong>b2g process</strong>, 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).</dd>
  <dt>
    IPDL</dt>
  <dd>
    Intercommunication Protocol Definition Language, see also <a href="/en-US/docs/IPDL" title="/en-US/docs/">IPDL</a>.</dd>
  <dt>
    AOSP</dt>
  <dd>
    Android Open Source Project.</dd>
  <dt>
    System call</dt>
  <dd>
    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.</dd>
  <dt>
    DAC, MAC</dt>
  <dd>
    Discretionary Access Control (configured by the user) and Mandatory Access Control (enforced by the kernel).</dd>
  <dt>
    FOTA</dt>
  <dd>
    Firmware Over The Air update system mechanism. Term used to describe full firmware updates, generally sent "over the air", i.e. over a wireless connection to a mobile phone.</dd>
  <dt>
    MSU, MAR</dt>
  <dd>
    Mozilla System Updater, Mozilla ARchive. Term used to describe Gecko updates, using the same updater mechanism and archive format as Firefox Desktop.</dd>
</dl>
<h2 id="Goals_and_scope_of_the_Firefox_OS_system_security_model">Goals and scope of the Firefox OS system security model</h2>
<p>The Firefox OS system security model is designed to:</p>
<ul>
  <li>Limit and enforce the scope of resources that can be accessed or used by a web application.</li>
  <li>Ensure several layers of security are being correctly used in the operating system.</li>
  <li>Limit and contain the impact of vulnerabilities caused by security bugs, from the Gonk layer.</li>
  <li>Web application permissions and any application related security feature is detailed in the <a href="/en-US/docs/Mozilla/Firefox_OS/Security/Application_security" title="/en-US/docs/Mozilla/Firefox_OS/Security/Application_security">Application Security</a> model.</li>
</ul>
<p>See the sections below for more detailed explanations of each of these goals, and how they're addressed by Firefox OS.</p>
<h2 id="Enforcing_permissions">Enforcing permissions</h2>
<p>The <a href="/en-US/docs/Mozilla/Firefox_OS/Security/Application_security" title="/en-US/docs/Mozilla/Firefox_OS/Security/Application_security">Application Security</a> model describes how users grant permissions to applications, either directly or through a trusted third party.&nbsp; These permissions are enforced upon the <strong>content process</strong> by enforcing any access to resource is realized via an IPC call to the <strong>core process</strong>.</p>
<ul>
  <li>The Firefox OS core process, <code>b2g</code>, has very high privileges and has access to most hardware devices.</li>
  <li>Web applications run in a low-privileged content process and only communicate with the <code>b2g</code> core process using IPC, which is implemented using <a href="/en-US/docs/IPDL" title="/en-US/docs/IPDL">IPDL</a>.</li>
  <li>The content process has no operating system level access to resources.</li>
  <li>Each Web API has one or more associated IPDL protocol declaration file(s) (*.ipdl)</li>
  <li>Firefox OS content processes can only communicate through the <a href="/en-US/docs/IPDL" title="/en-US/docs/IPDL">IPDL</a> mechanism back to the core process, which will perform actions on behalf of content.</li>
</ul>
<h2 id="Content_process_initialization"><a name="Content_processes">Content process initialization</a></h2>
<p>All web appplications run in a low-rights, separate process: the Firefox OS <strong>content process</strong>. This process is launched by the <code>b2g</code> core process when it reaches a special {{HTMLElement("iframe")}} type: <em>&lt;iframe mozapp&gt;</em>. This separates the web application from the rest of the content and is strongly associated to a manifest (see the <a href="/en-US/docs/Mozilla/Firefox_OS/Security/Application_security" title="/en-US/docs/Mozilla/Firefox_OS/Security/Application_security">Application Security</a> 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 <code>plugin-container</code> process and uses similar code to the <code>plugin-container</code> used by the desktop Firefox.</p>
<h3 id="Risks">Risks</h3>
<ul>
  <li>Leak of information when spawning the web application's content process</li>
  <li>Possibility of accessing operating system resources, escalate to the same level of privileges as the <code>b2g</code> process</li>
  <li>Bypassing the content process initialization</li>
</ul>
<h3 id="Implementation">Implementation</h3>
<h4 id="Initialization_within_the_b2g_process">Initialization within the b2g process</h4>
<p>In this order:</p>
<ol>
  <li><code>fork()</code></li>
  <li><code>setuid</code>(new, different, unused user id|nobody) (which is an unprivileged user)</li>
  <li><code>chrdir('/')</code></li>
  <li><code>execve('plugin-container')</code></li>
</ol>
<p>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 <code>b2g</code> process.</p>
<h4 id="File_descriptor_handling">File descriptor handling</h4>
<p>File descriptors are handled using a whitelist method; a list of permitted file descriptors (FDs) is created and stored in the <code>mFileMap</code> object. The LaunchApp() function forcefully closes all FDs not on the whitelist. This is done after <code>fork()</code> (which is when FDs are copied) but before <code>execve()</code> (which is when the new app starts running).</p>
<p>Unlike the more traditional method which uses a blacklist (close-on-exec flag: <code>CLOEXEC</code>), this ensures no FDs are left open; this is, therefore, more reliable.</p>
<h2 id="File_system_hardening"><a name="File_system_hardening"></a>File system hardening</h2>
<h3 id="Risks">Risks</h3>
<ul>
  <li>Writing, deleting or reading files belonging to another user; this could result in an information leak or unexpected behavior such as privilege escalation</li>
  <li>Execution of native code through an application vulnerability</li>
  <li>Vulnerabilities in setuid programs (and thus, privilege escalation)</li>
</ul>
<h3 id="Implementation">Implementation</h3>
<p>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 <code>nodev</code>, <code>nosuid</code>, and <code>noexec</code> options. The standard filesystem mounts are restricted as follows:</p>
<table class="standard-table">
  <thead>
    <tr>
      <th scope="col">Mount point</th>
      <th scope="col">File system</th>
      <th scope="col">Options</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td><code>/</code></td>
      <td>rootfs</td>
      <td>read-only</td>
    </tr>
    <tr>
      <td><code>/dev</code></td>
      <td>tmpfs</td>
      <td>read-write, nosuid, noexec, mode=0755</td>
    </tr>
    <tr>
      <td><code>/dev/pts</code></td>
      <td>ptsfs</td>
      <td>read-write, nosuid, noexec, mode=0600</td>
    </tr>
    <tr>
      <td><code>/proc</code></td>
      <td>proc</td>
      <td>read-write, nosuid, nodev, noexec</td>
    </tr>
    <tr>
      <td><code>/sys</code></td>
      <td>sysfs</td>
      <td>read-write, nosuid, nodev, noexec</td>
    </tr>
    <tr>
      <td><code>/cache</code></td>
      <td>yaffs2 or ext4</td>
      <td>read-write, nosuid, nodev, noexec</td>
    </tr>
    <tr>
      <td><code>/efs</code></td>
      <td>yaffs2 or ext4</td>
      <td>read-write, nosuid, nodev, noexec</td>
    </tr>
    <tr>
      <td><code>/system</code></td>
      <td>ext4</td>
      <td>read-only, nodev</td>
    </tr>
    <tr>
      <td><code>/data</code></td>
      <td>ext4</td>
      <td>read-write, nosuid, nodev, noexec</td>
    </tr>
    <tr>
      <td><code>/mnt/sdcard</code></td>
      <td>ext4 or vfat</td>
      <td>read-write, nosuid, nodev, noexec, uid=1000, fmask=0702, dmask=0702</td>
    </tr>
    <tr>
      <td><code>/acct</code></td>
      <td>cgroup</td>
      <td>read-write, nosuid, nodev, noexec</td>
    </tr>
    <tr>
      <td><code>/dev/cpuctl</code></td>
      <td>cgroup</td>
      <td>read-write, nosuid, nodev, noexec</td>
    </tr>
  </tbody>
</table>
<div class="note">
  <p><strong>Note:</strong> The exact mount points may vary.</p>
</div>
<h3 id="Linux_DAC"><span class="mw-headline" id="Linux_DAC">Linux DAC</span></h3>
<p>The Linux DAC represents the well-known Linux filesystem permission model.</p>
<div class="note">
  <p><strong>Note: </strong>This is the traditional user/group/others permission model and <strong>not</strong> the Linux POSIX 1.e ACLs</p>
</div>
<ul>
  <li>The web application system user has no write access to any file</li>
  <li>The usage of setuid binaries is limited to where necessary</li>
  <li>New content processes are started with a sane umask</li>
</ul>
<h2 id="Secure_system_updates"><a name="System_updates"></a>Secure system updates</h2>
<h3 id="Risks">Risks</h3>
<ul>
  <li>Compromised update package data, resulting in an untrusted update package being installed</li>
  <li>Compromised update check
    <ul>
      <li>User does not see new updates are available</li>
      <li>User gets an out of date package as an update, which effectively downgrades the software on the device</li>
    </ul>
  </li>
  <li>System state compromised or unknown during the installation of the update; this may (for example) lead to:
    <ul>
      <li>Missing elements during the installation, some of which may be security fixes</li>
      <li>Security fixes reverted by the compromised system after upgrade</li>
    </ul>
  </li>
  <li>Vulnerabilities in the update checking mechanism running on the device</li>
  <li>Lack of updates or tracking for a software component with a known vulnerability</li>
</ul>
<h2 id="Implementation">Implementation</h2>
<p>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.</p>
<h3 id="Firmware_over_the_air_updates">Firmware over the air updates</h3>
<p>System updates can involve all or a portion of the Firefox OS stack. If changes to Gonk are included in the update, then <strong>FOTA</strong> (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.</p>
<h3 id="MSU.2FMAR_updates">MSU/MAR updates</h3>
<p>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. For more information, see {{interwiki("wikimo", "Software Update")}}.</p>
<h3 id="Update_service">Update service</h3>
<div class="note">
  <p><strong>Note: </strong>The update service may be provided by the OEM.</p>
</div>
<p>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:</p>
<ul>
  <li>update origin (verify the source location protocol:domain:port of the system update and manifest)</li>
  <li>file integrity (cryptographic hash checksums)</li>
  <li>code signature (certificate check against a trusted root)</li>
</ul>
<p>The following security measures are used during the update process:</p>
<ul>
  <li>Mozilla recommends and expects that updates are fetched over an SSL connection with a trusted certificate.</li>
  <li>Strong cryptographic verification is required before installing a firmware package.</li>
  <li>The complete update must be downloaded in a specific and secure location before the update process begins.</li>
  <li>The system must be in a secure state when the update process starts, with no web applications running.</li>
  <li>The keys must be stored in a secure location on the device.</li>
</ul>
<p>Rigorous checks are in place to ensure that the update is applied properly to the mobile phone.</p>
Revert to this revision