Firefox OS security overview

  • Revision slug: Mozilla/Firefox_OS/Security/Security_model
  • Revision title: Security model
  • Revision id: 343783
  • Created:
  • Creator: bholley
  • Is current revision? No
  • Comment typo

Revision Content

{{draft()}}

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

Terminology

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

Web application
A web application or web app is a program written using HTML, JavaScript, and other open Web technologies, running on Firefox OS. 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.
Core process
The Firefox OS core process is typically referred to as "b2g". This is, essentially, an application that runs with highly elevated privileges and controls the access that any Web application has to all resources and devices.
Content process
The Firefox OS content process is often referred to by the name content. This is the process in which Web apps are running. It communicates with the Firefox OS core process using inter-process communication (IPC).

Goals of the runtime security model

The Firefox OS runtime security model is designed to:

  • Enforce the permissions granted to Web apps.
  • Protect the Firefox OS core and content processes from attack by malicious content.
  • Ensure that communication channels between the content process and the core process are not used in unintended ways.

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

Enforcing permissions

The Web app permissions model describes how users grant permissions to applications, either directly or through a trusted third party. Ensuring that these permissions are enforced correctly is key to ensuring the security of user data and the integrity of the application platform provided by Firefox OS. With this in mind, Web app permissions are enforced at multiple layers within Firefox OS; this reduces the risk of the permission model being compromised.

The permission controls outlined below are based on the architecture outlined in the Firefox OS architecture overview, as follows:

  • The Firefox OS core process, b2g, has very high privileges and has access to most hardware devices.
  • Web apps run in a low-privileged content process and only communicate with the b2g core process using IPC, which is implemented using IPDL.
  • Each Web API has an associated IPDL interface.
  • Firefox OS maintains a central permissions database that stores the permissions granted to each Web app. Permissions are added at installation time, and can only be modified by the permissions manager application.

Web app layer

Web applications have, by default, the lowest access to system resources, unless expressly granted access to them by the permissions manager.

Web apps are loaded inside a special type of {{HTMLElement("iframe")}}, using the {{HTMLAttrXRef("mozapp", "iframe")}} attribute; this separates Web apps from other content, and is closely associated with a Web app manifest. This manifest describes the Web app.

In order to know what each Web app is allowed to do, each Web app has an associated set of permissions. When the Web app attempts to call certain sensitive APIs, the Firefox OS permission database is checked to ensure that the app has the requisite permission. If it doesn't, the call will not succeed.

To prevent Web apps from interfering with one another, each one is hosted on a separate domain, and therefore may only access the resources associated with its domain. These resources include things such as IndexedDB databases, cookies, offline storage, and so forth. The only exception is if the Web app has permission to access APIs that utilize shared resources such as contacts, the photo gallery, media storage, USB devices, and so forth.

Note: That last bullet point is not necessarily final; you should assume that your app has access to nothing outside its own domain at all.

Content processes

It's important to understand what privileges content has, and what privileges are reserved for the core process.

Note: The Firefox OS core and content process separation is not enabled yet.

All Web apps run in a low-rights, separate process: the Firefox OS content process. This process is launched by the b2g core process using fork() and execve(). File descriptors are handled using FileMap, which closes them on object destruction, and before the fork. Only a few select file descriptors are kept open in order to enable communication between the two processes.

The content processes are sandboxed; this prevents the content process from accessing the operating system level. Firefox OS content processes can only communicate through the IPDL mechanism back to the core process, which will perform actions on behalf of content.

Each Web app is loaded into separate content processes; this provides additional protection by reducing the number of attack vectors each individual app has. Under ideal conditions, each app is loaded into its own process; however, resource constraints may require multiple apps to share a content process. When this happens, Firefox OS only groups apps with similar trust levels and similar access levels to system resources.

Each Firefox OS content process has access to a record indicating the privileges associated with the applications running in it. The content processes enforce these privileges at a Web API level; as such, they will never send IPDL messages for APIs to which the Web apps within them do not have access, unless they have been compromised in some way. In the case of compromise, the core process will enforce the permissions. By having multiple layers of protection, security can be better assured.

Through all of this, each Firefox OS content process is associated with a set of permissions. This set of permissions is the union of all permissions required by each app running inside it. The Firefox OS core process validates the IPDL messages from each content process; if a message is detected which requests access to an API that is outside that set of permissions, the core process denies the request. This should never happen under normal circumstances, since the content process has already checked for this and enforced permissions on its apps.

Note: If the core process detects an attempt to use an API without permission, the content process will be terminated and respawned.

Protecting the operating system

There is an inherent degree of security offered by the fact that in Firefox OS, all applications are Web apps. There are no strictly binary ("native") applications installed by the user, and all system access is mediated through the Web APIs. In addition, there's no direct access to the file system; files stored on the SD card are exposed using Web APIs as well. Because of this, the key potential threats to the underlying operating system are:

  • Memory corruption or logical errors in Gecko that lead to arbitrary code execution.
  • Similar faults in the operating system itself (the kernel and daemons) that lead to arbitrary code execution.
  • A compromise of the software update mechanism.
  • Hijacking of a Web application using XSS or memory corruption (for example).
  • A vulnerability in IPDL.

Mitigation of code execution threats is introduced by taking the following steps:

  • Gecko is hardened against attack (just like it is in Firefox).
  • Web content is run in lower-rights child processes in order to reduce the impact a process compromise introduces. This is the Firefox OS content process.
  • The underlying operating system is hardened to make post-exploitation more difficult.
  • When available, hardening features of the compiler are used.

Process model and separation

As previously explained, the Firefox OS process model is based on the concept of a single core process (the parent process), which has access to all hardware, services, and so forth, and one or more content processes (the children), each of which has only enough access to the system to communicate with the parent process.

In case of a vulnerability in a content process, the operating system limits the impact by denying system level resource access to the low-privilege content process. Compromising the core process is equivalent to complete compromise of the operating system.

If a content process is compromised, this can lead to the access of resources available to other applications running in the same content process.

Note: The Firefox OS development team is investigating seccomp mode 2 (which requires a kernel patch for versions below 3.5). This would allow content processes to call recv(), send(), exit(), and any other system call that's whitelisted to support WebGL, such as mmap().

Calls to any other system routines are denied by the kernel for all content processes.

Of course, the effectiveness of using low-rights content processes as a mitigation technique is also dependent upon the control of communication between children (that is, content processes) and the parent process (the Firefox OS core process).

IPDL is used as an IPC mechanism via UNIXSOCK and shared memory (SHM). Access requests are performed using IPDL requests, and are authorized given a certain application ID. The primary risk in IPDL is the serialization and deserialization of data types. IPDL has built-in types which are well-known and tested; these are used whenever possible. However, when deserialization must be done by Firefox OS code, a security review is required. In addition, any time a deserialization error occurs, the responsible child process is terminated.

Future improvements

There are future improvements planned to this model, including:

  • The ultimate goal is to have a finer level of separation between various software components, such as the core processes components. For example, segregating the WebGL graphics pipeline would allow tighter sandboxing of the Firefox OS content processes.
  • We plan to investigate running the Firefox OS core process and the content processes in separate ARM TrustZones.
  • In addition, we plan to investigate Role Based Access Control, enforced at the kernel level. This is done in RSBAC, SELinux, and other operating systems. There is a similar project for Android; in particular, see the security policy document.

Operating system hardening

Mozilla provides a reference implementation and recommendations for operating system security controls.

  • File system privileges are enforced by Linux's access control lists (ACLs).
    • The Firefox OS core process runs as root, and has CAP_DAC_READ_SEARCH (among other capabilities). Because of this, ACLs are not a security measure for this process.
    • Content processes are run as a regular user, with very restricted access.
  • Review of system daemon (wpa_supplicant, gpsd, and so forth) configurations.
  • Compilation of the software with full address space layout randomization (ASLR) support (including the linker), as well as using SSP/PIE binaries has been found to have a significant impact on runtime performance.

Mount point configurations

The mount points are configured as follows (more options may be set, but will be similar to the below):

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

If any additional mount points are present, the rational is that only areas containing user content may be read-write, unless the operating system itself requires the addition of a new read-write area in the future. These mount points must include the nodev, nosuid, and noexec options.

Note: The exact mount points may vary.

Future plans

A few of the things we're considering investigating in the future:

OS updates

Operating system updates include everything except the Gecko layer, which has its own update process; see {{anch("Gecko updates")}}. Operating system updates are issued when a user-impacting bug or security bug is fixed, or when required for a major Firefox OS upgrade.

OS updates can be performed in two ways:

Over the air (OTA)
OTA updates can be performed wirelessly; however, this mechanism hasn't been functionally defined yet for Firefox OS. It will be similar to the mechanism used by Android, however.
Using a firmware image
If an OTA upgrade fails (due to a power issue, hardware failure, or the like), the device may become "bricked"; that is, it may no longer be able to run the operating system so that an OTA update can be performed. In that scenario, you can connect the device to a computer using a USB cable and use the fast bootloader to install a firmware image.

Note: A firmware image can be used to replace Firefox OS with another operating system, as well as to upgrade Firefox OS.

There are several security measures taken during the update process:

  • Strong cryptography 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 apps running.
  • The keys must be stored in a secure location on the device.

Gecko updates

Gecko updates itself using the same mechanism used by Firefox on desktop computers:

  • The updates are fetched over an SSL connection.
  • SSL certificates' issuer names are pinned in Firefox OS.
  • Updates are signed in their update files, which are in MAR format.

The Gecko updater is not yet implemented; see {{bug(715816)}} to track its progress.

Protecting user data

The boot loader, fastboot, enforces erasure of user data when the boot loader is unlocked (fastboot oem unlock). This makes extracting user data more difficult.

However, if an untrusted party gains physical access to an unlocked device, user data is unprotected.

Future plans

In the future, we plan to implement full disk encryption. There are some issues being considered, however:

  • Encryption depends on the device's password; this can be a usability issue.
  • We will investigate the option of unlocking at boot time only; this is less secure but not terribly so. This might be done using a configuration option, so that it this less secure mode can be selected depending on the user's preference.
  • There is the risk of users forgetting their encryption password; if this happens, they lose access to the data on their device.

Revision Source

<p>{{draft()}}</p>
<p>This article provides an overview of the Firefox OS 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 security model, here are a few key terms you need to understand.</p>
<dl>
  <dt>
    Web application</dt>
  <dd>
    A <strong>web application</strong> or <strong>web app</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. 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>
    Core process</dt>
  <dd>
    The Firefox OS <strong>core process</strong> is typically referred to as "b2g". This is, essentially, an application that runs with highly elevated privileges and controls the access that any Web application has to all resources and devices.</dd>
  <dt>
    Content process</dt>
  <dd>
    The Firefox OS <strong>content process</strong> is often referred to by the name <strong>content</strong>. This is the process in which Web apps are running. It communicates with the Firefox OS core process using inter-process communication (IPC).</dd>
</dl>
<h2 id="Goals_of_the_runtime_security_model">Goals of the runtime security model</h2>
<p>The Firefox OS runtime security model is designed to:</p>
<ul>
  <li>Enforce the permissions granted to Web apps.</li>
  <li>Protect the Firefox OS core and content processes from attack by malicious content.</li>
  <li>Ensure that communication channels between the content process and the core process are not used in unintended ways.</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">Web app permissions</a> model describes how users grant permissions to applications, either directly or through a trusted third party. Ensuring that these permissions are enforced correctly is key to ensuring the security of user data and the integrity of the application platform provided by Firefox OS. With this in mind, Web app permissions are enforced at multiple layers within Firefox OS; this reduces the risk of the permission model being compromised.</p>
<p>The permission controls outlined below are based on the architecture outlined in the <a href="/en-US/docs/Mozilla/Firefox_OS/Architecture" title="/en-US/docs/Mozilla/Firefox_OS/Architecture">Firefox OS architecture overview</a>, as follows:</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 apps 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>Each Web API has an associated IPDL interface.</li>
  <li>Firefox OS maintains a central permissions database that stores the <a href="https://developer.mozilla.org/en-US/docs/Mozilla/Firefox_OS/Security/Software_permissions" title="https://developer.mozilla.org/en-US/docs/Mozilla/Firefox_OS/Security/Software_permissions">permissions granted to each Web app</a>. Permissions are added at installation time, and can only be modified by the permissions manager application.</li>
</ul>
<h3 id="Web_app_layer">Web app layer</h3>
<p>Web applications have, by default, the lowest access to system resources, unless expressly granted access to them by the permissions manager.</p>
<p>Web apps are loaded inside a special type of {{HTMLElement("iframe")}}, using the {{HTMLAttrXRef("mozapp", "iframe")}} attribute; this separates Web apps from other content, and is closely associated with a <a href="/en-US/docs/Apps/Manifest" title="/en-US/docs/Apps/Manifest">Web app manifest</a>. This manifest describes the Web app.</p>
<p>In order to know what each Web app is allowed to do, each Web app has an associated set of permissions. When the Web app attempts to call certain sensitive APIs, the Firefox OS permission database is checked to ensure that the app has the requisite permission. If it doesn't, the call will not succeed.</p>
<p>To prevent Web apps from interfering with one another, each one is hosted on a separate domain, and therefore may only access the resources associated with its domain. These resources include things such as IndexedDB databases, cookies, offline storage, and so forth. The only exception is if the Web app has permission to access APIs that utilize shared resources such as contacts, the photo gallery, media storage, USB devices, and so forth.</p>
<div class="note">
  <p><strong>Note:</strong> That last bullet point is not necessarily final; you should assume that your app has access to nothing outside its own domain at all.</p>
</div>
<h3 id="Content_processes"><a name="Content_processes">Content processes</a></h3>
<p>It's important to understand what privileges content has, and what privileges are reserved for the core process.</p>
<div class="note">
  <p><strong>Note:</strong> The Firefox OS core and content process separation is not enabled yet.</p>
</div>
<p>All Web apps 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 using <code>fork()</code> and <code>execve()</code>. File descriptors are handled using FileMap, which closes them on object destruction, and before the fork. Only a few select file descriptors are kept open in order to enable communication between the two processes.</p>
<p>The content processes are sandboxed; this prevents the content process from accessing the operating system level. 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.</p>
<p>Each Web app is loaded into separate content processes; this provides additional protection by reducing the number of attack vectors each individual app has. Under ideal conditions, each app is loaded into its own process; however, resource constraints may require multiple apps to share a content process. When this happens, Firefox OS only groups apps with similar trust levels and similar access levels to system resources.</p>
<p>Each Firefox OS content process has access to a record indicating the privileges associated with the applications running in it. The content processes enforce these privileges at a Web API level; as such, they will never send IPDL messages for APIs to which the Web apps within them do not have access, unless they have been compromised in some way. In the case of compromise, the core process will enforce the permissions. By having multiple layers of protection, security can be better assured.</p>
<p>Through all of this, each Firefox OS content process is associated with a set of permissions. This set of permissions is the union of all permissions required by each app running inside it. The Firefox OS core process validates the IPDL messages from each content process; if a message is detected which requests access to an API that is outside that set of permissions, the core process denies the request. This should never happen under normal circumstances, since the content process has already checked for this and enforced permissions on its apps.</p>
<div class="note">
  <p><strong>Note:</strong> If the core process detects an attempt to use an API without permission, the content process will be terminated and respawned.</p>
</div>
<h2 id="Protecting_the_operating_system">Protecting the operating system</h2>
<p>There is an inherent degree of security offered by the fact that in Firefox OS, all applications are Web apps. There are no strictly binary ("native") applications installed by the user, and all system access is mediated through the Web APIs. In addition, there's no direct access to the file system; files stored on the SD card are exposed using Web APIs as well. Because of this, the key potential threats to the underlying operating system are:</p>
<ul>
  <li>Memory corruption or logical errors in Gecko that lead to arbitrary code execution.</li>
  <li>Similar faults in the operating system itself (the kernel and daemons) that lead to arbitrary code execution.</li>
  <li>A compromise of the software update mechanism.</li>
  <li>Hijacking of a Web application using XSS or memory corruption (for example).</li>
  <li>A vulnerability in <a href="/en-US/docs/IPDL" title="/en-US/docs/IPDL">IPDL</a>.</li>
</ul>
<p>Mitigation of code execution threats is introduced by taking the following steps:</p>
<ul>
  <li>Gecko is hardened against attack (just like it is in Firefox).</li>
  <li>Web content is run in lower-rights child processes in order to reduce the impact a process compromise introduces. This is the Firefox OS <a href="#Content_processes" title="#Content_processes">content process</a>.</li>
  <li>The underlying operating system is hardened to make post-exploitation more difficult.</li>
  <li>When available, hardening features of the compiler are used.</li>
</ul>
<h3 id="Process_model_and_separation">Process model and separation</h3>
<p>As previously explained, the Firefox OS process model is based on the concept of a single core process (the parent process), which has access to all hardware, services, and so forth, and one or more content processes (the children), each of which has only enough access to the system to communicate with the parent process.</p>
<p>In case of a vulnerability in a content process, the operating system limits the impact by denying system level resource access to the low-privilege content process. Compromising the core process is equivalent to complete compromise of the operating system.</p>
<p>If a content process is compromised, this can lead to the access of resources available to other applications running in the same content process.</p>
<div class="note">
  <p><strong>Note</strong><strong>:</strong> The Firefox OS development team is investigating seccomp mode 2 (which requires a kernel patch for versions below 3.5). This would allow content processes to call <code>recv()</code>, <code>send()</code>, <code>exit()</code>, and any other system call that's whitelisted to support <a href="/en-US/docs/WebGL" title="/en-US/docs/WebGL">WebGL</a>, such as <code>mmap()</code>.</p>
</div>
<p>Calls to any other system routines are denied by the kernel for all content processes.</p>
<p>Of course, the effectiveness of using low-rights content processes as a mitigation technique is also dependent upon the control of communication between children (that is, content processes) and the parent process (the Firefox OS core process).</p>
<p><a href="/en-US/docs/IPDL" title="/en-US/docs/IPDL">IPDL</a> is used as an IPC mechanism via UNIXSOCK and shared memory (SHM). Access requests are performed using IPDL requests, and are authorized given a certain application ID. The primary risk in IPDL is the serialization and deserialization of data types. IPDL has built-in types which are well-known and tested; these are used whenever possible. However, when deserialization must be done by Firefox OS code, a security review is required. In addition, any time a deserialization error occurs, the responsible child process is terminated.</p>
<h4 id="Future_improvements">Future improvements</h4>
<p>There are future improvements planned to this model, including:</p>
<ul>
  <li>The ultimate goal is to have a finer level of separation between various software components, such as the core processes components. For example, segregating the WebGL graphics pipeline would allow tighter sandboxing of the Firefox OS content processes.</li>
  <li>We plan to investigate running the Firefox OS core process and the content processes in separate ARM <a href="http://www.arm.com/products/processors/technologies/trustzone.php" title="http://www.arm.com/products/processors/technologies/trustzone.php">TrustZones</a>.</li>
  <li>In addition, we plan to investigate Role Based Access Control, enforced at the kernel level. This is done in RSBAC, SELinux, and other operating systems. There is a <a href="http://selinuxproject.org/page/SEAndroid" title="http://selinuxproject.org/page/SEAndroid">similar project for Android</a>; in particular, see the <a href="http://selinuxproject.org/~seandroid/git/selinux/sepolicy/" title="http://selinuxproject.org/~seandroid/git/selinux/sepolicy/">security policy document</a>.</li>
</ul>
<h3 id="Operating_system_hardening">Operating system hardening</h3>
<p>Mozilla provides a reference implementation and recommendations for operating system security controls.</p>
<ul>
  <li>File system privileges are enforced by Linux's access control lists (ACLs).
    <ul>
      <li>The Firefox OS core process runs as root, and has <code>CAP_DAC_READ_SEARCH</code> (among other capabilities). Because of this, ACLs are not a security measure for this process.</li>
      <li>Content processes are run as a regular user, with very restricted access.</li>
    </ul>
  </li>
  <li>Review of system daemon (<code>wpa_supplicant</code>, <code>gpsd</code>, and so forth) configurations.</li>
  <li>Compilation of the software with full address space layout randomization (ASLR) support (including the linker), as well as using SSP/PIE binaries has been found to have a significant impact on runtime performance.</li>
</ul>
<h4 id="Mount_point_configurations">Mount point configurations</h4>
<p>The mount points are configured as follows (more options may be set, but will be similar to the below):</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>
<p>If any additional mount points are present, the rational is that only areas containing user content may be read-write, unless the operating system itself requires the addition of a new read-write area in the future. These mount points <strong>must </strong>include the nodev, nosuid, and noexec options.</p>
<div class="note">
  <p><strong>Note:</strong> The exact mount points may vary.</p>
</div>
<h4 id="Future_plans">Future plans</h4>
<p>A few of the things we're considering investigating in the future:</p>
<ul>
  <li><a href="http://review.coreboot.org/gitweb?p=coreboot.git;a=commit;h=9aea04aa892903009e487ada7f7b911691e68630" title="http://review.coreboot.org/gitweb?p=coreboot.git;a=commit;h=9aea04aa892903009e487ada7f7b911691e68630">CoreBoot</a> secure booting support, like in Chrome OS., or enhancements to fastboot.</li>
  <li>See also the <a href="http://www.chromium.org/chromium-os/chromiumos-design-docs/system-hardening" title="http://www.chromium.org/chromium-os/chromiumos-design-docs/system-hardening">Chrome OS system hardening documentation</a>.</li>
  <li>Investigate getting full ASLR turned on, with improved performance.</li>
</ul>
<h3 id="OS_updates">OS updates</h3>
<p>Operating system updates include everything except the Gecko layer, which has its own update process; see {{anch("Gecko updates")}}. Operating system updates are issued when a user-impacting bug or security bug is fixed, or when required for a major Firefox OS upgrade.</p>
<p>OS updates can be performed in two ways:</p>
<dl>
  <dt>
    Over the air (OTA)</dt>
  <dd>
    OTA updates can be performed wirelessly; however, this mechanism hasn't been functionally defined yet for Firefox OS. It will be similar to the mechanism used by Android, however.</dd>
  <dt>
    Using a firmware image</dt>
  <dd>
    If an OTA upgrade fails (due to a power issue, hardware failure, or the like), the device may become "bricked"; that is, it may no longer be able to run the operating system so that an OTA update can be performed. In that scenario, you can connect the device to a computer using a USB cable and use the fast bootloader to install a firmware image.</dd>
</dl>
<div class="note">
  <p><strong>Note:</strong> A firmware image can be used to replace Firefox OS with another operating system, as well as to upgrade Firefox OS.</p>
</div>
<p>There are several security measures taken during the update process:</p>
<ul>
  <li>Strong cryptography 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 apps running.</li>
  <li>The keys must be stored in a secure location on the device.</li>
</ul>
<h3 id="Gecko_updates">Gecko updates</h3>
<p>Gecko updates itself using the same mechanism used by Firefox on desktop computers:</p>
<ul>
  <li>The updates are fetched over an SSL connection.</li>
  <li>SSL certificates' issuer names are pinned in Firefox OS.</li>
  <li>Updates are signed in their update files, which are in <a href="https://wiki.mozilla.org/Software_Update:MAR" title="https://wiki.mozilla.org/Software_Update:MAR">MAR format</a>.</li>
</ul>
<p>The Gecko updater is not yet implemented; see {{bug(715816)}} to track its progress.</p>
<h2 id="Protecting_user_data">Protecting user data</h2>
<p>The boot loader, fastboot, enforces erasure of user data when the boot loader is unlocked (<code>fastboot oem unlock</code>). This makes extracting user data more difficult.</p>
<p>However, if an untrusted party gains physical access to an unlocked device, user data is unprotected.</p>
<h3 id="Future_plans">Future plans</h3>
<p>In the future, we plan to implement full disk encryption. There are some issues being considered, however:</p>
<ul>
  <li>Encryption depends on the device's password; this can be a usability issue.</li>
  <li>We will investigate the option of unlocking at boot time only; this is less secure but not terribly so. This might be done using a configuration option, so that it this less secure mode can be selected depending on the user's preference.</li>
  <li>There is the risk of users forgetting their encryption password; if this happens, they lose access to the data on their device.</li>
</ul>
Revert to this revision