Compare Revisions

System security

Change Revisions

Revision 363619:

Revision 363619 by kangster on

Revision 364619:

Revision 364619 by kangster on

System Security
System Security
"Moved out of security model into this page. Still need to trim content from this page which is dupli"
Moved out of security model into this page. Still need to trim content from this page which is dupli,

Revision 363619
Revision 364619
n24        A <strong>web application</strong>, <strong>web app</stron24        A <strong>web application</strong>, <strong>web app</stro
>ng>, or <strong>application</strong> is a program written using <>ng>, <strong>moz app</strong>, or <strong>application</strong> is
>a href="/en-US/docs/HTML" title="/en-US/docs/HTML">HTML</a>, <a h> a program written using <a href="/en-US/docs/HTML" title="/en-US
>ref="/en-US/docs/JavaScript" title="/en-US/docs/JavaScript">JavaS>/docs/HTML">HTML</a>, <a href="/en-US/docs/JavaScript" title="/en
>cript</a>, and other open Web technologies, running on Firefox OS>-US/docs/JavaScript">JavaScript</a>, and other open Web technolog
>. For example, the Dialer is a Web app in Firefox OS. Pages runni>ies, running on Firefox OS. All user-facing applications on B2G a
>ng within the browser are not referred to as Web apps in this con>re web applications. For example, the Dialer is a Web app in Fire
>text.>fox OS. Pages running within the browser are not referred to as W
 >eb apps in this context.
25      </dd>
26      <dt>
27        Core process
28      </dt>
29      <dd>25      </dd>
30        The Firefox OS <strong>core process</strong> is typically26      <dt>
> referred to as "<strong>b2g</strong>" or "Gecko". This is, essen 
>tially, an application that runs with highly elevated privileges  
>and controls the access that any Web application has to all resou 
>rces and devices. 
27        b2g process
28      </dt>
29      <dd>
30        The Firefox OS <strong>b2g process</strong> is typically 
 >referred to as "<strong>b2g</strong>" or "Gecko". This is, essent
 >ially, an application that runs with highly elevated privileges (
 >i.e., runs as root) and controls the access that any web applicat
 >ion has to all resources and devices.
n36        The Firefox OS <strong>content process</strong> is often n36        This is a child process spawned by the <strong>b2g proces
>referred to by the name <strong>content</strong> or <strong>appli>s</strong>, and which communicates with the b2g process. It repre
>cation process</strong>. This is the process in which Web apps ar>sents a web application. This is a low-privileged process (i.e., 
>e running. This process runs with low privileges. It communicates>run as regular user and has a very limited access and view of/to 
> with the Firefox OS core process using inter-process communicati>the operating system). It communicates with the Firefox OS core p
>on (IPC).>rocess using inter-process communication (IPC).
37      </dd>
38      <dt>
39        IPDL
40      </dt>
41      <dd>
42        Intercommunication Protocol Definition Language, see also
 > <a href="/en-US/docs/IPDL" title="/en-US/docs/">IPDL</a>.
43      </dd>
44      <dt>
45        AOSP
46      </dt>
47      <dd>
48        Android Open Source Project.
49      </dd>
50      <dt>
51        System call
52      </dt>
53      <dd>
54        An interface to talk between the user-space (processes) a
 >nd the kernel. There is no other direct way for a user-space proc
 >ess to talk to the kernel.
55      </dd>
56      <dt>
57        DAC, MAC
58      </dt>
59      <dd>
60        Discretionary Access Control (configured by the user) and
 > Mandatory Access Control (enforced by the kernel).
61      </dd>
62      <dt>
63        FOTA
64      </dt>
65      <dd>
66        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.
67      </dd>
68      <dt>
69        MSU, MAR
70      </dt>
71      <dd>
72        Mozilla System Updater, Mozilla ARchive. Term used to des
 >cribe Gecko updates, using the same updater mechanism and archive
 > format as Firefox Desktop.
n39    <h2 id="Goals_of_the_runtime_security_model">n75    <h2 id="Goals_of_the_Firefox_OS_system_security_model">
40      Goals of the Firefox OS system security model76      Goals and scope of the Firefox OS system security model
n46      <li>Limit and enforce the scope of resources that may be acn82      <li>Limit and enforce the scope of resources that can be ac
>cessed or used by a Web application.>cessed or used by a web application.
n48      <li>Ensure that several layers of security are being correcn84      <li>Ensure several layers of security are being correctly u
>tly used within the operating system.>sed in the operating system.
n50      <li>Protect the Firefox OS core and content processes from n
>attack by malicious content. 
51      </li>
52      <li>Limit and contain the impact of vulnerabilities caused 86      <li>Limit and contain the impact of vulnerabilities caused 
>by security bugs within the Gonk layer.>by security bugs, from the Gonk layer.
87      </li>
88      <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/Moz
 >illa/Firefox_OS/Security/Application_security">Application Securi
 >ty</a> model.
n62      The <a href="/en-US/docs/Mozilla/Firefox_OS/Security/Applicn98      The <a href="/en-US/docs/Mozilla/Firefox_OS/Security/Applic
>ation_security" title="/en-US/docs/Mozilla/Firefox_OS/Security/Ap>ation_security" title="/en-US/docs/Mozilla/Firefox_OS/Security/Ap
>plication_security">Application Security</a> model describes how >plication_security">Application Security</a> model describes how 
>users grant permissions to applications, either directly or throu>users grant permissions to applications, either directly or throu
>gh a trusted third party. Ensuring that these permissions are enf>gh a trusted third party.&nbsp; These permissions are enforced up
>orced correctly is key to ensuring the security of user data and >on the <strong>content process</strong> by enforcing any access t
>the integrity of the application platform provided by Firefox OS.>o resource is realized via an IPC call to the <strong>core proces
> With this in mind, Web app permissions are enforced at multiple >s</strong>.
>layers within Firefox OS; this reduces the risk of the permission 
> model being compromised. 
63    </p>
64    <p>
65      The permission controls outlined below are based on the arc
>hitecture outlined in the&nbsp;<a href="/en-US/docs/Mozilla/Firef 
>ox_OS/Security/Security_model" title="/en-US/docs/Mozilla/Firefox 
>_OS/Security/Security_model">Security Model</a>, as follows: 
n70      <li>Web apps run in a low-privileged content process and onn103      <li>Web applications run in a low-privileged content proces
>ly communicate with the <code>b2g</code> core process using IPC, >s and only communicate with the <code>b2g</code> core process usi
>which is implemented using <a href="/en-US/docs/IPDL" title="/en->ng IPC, which is implemented using <a href="/en-US/docs/IPDL" tit
104      </li>
105      <li>The content process has no operating system level acces
 >s to resources
n74      <li>Firefox OS maintains a central permissions database than109      <li>Firefox OS content processes can only communicate throu
>t stores the <a href=">gh the <a href="/en-US/docs/IPDL" title="/en-US/docs/IPDL">IPDL</
>zilla/Firefox_OS/Security/Software_permissions" title="https://de>a> mechanism back to the core process, which will perform actions
>> on behalf of content.
>re_permissions">permissions granted to each Web application</a>.  
>Permissions are added at installation time, and can only be modif 
>ied by the permissions manager application. 
75      </li>
76    </ul>
77    <h3 id="Web_app_layer">
78      Web application layer
79    </h3>
80    <p>
81      Web applications have, by default, the lowest access to sys
>tem resources, unless expressly granted access to them by the per 
>missions manager. 
82    </p>
83    <p>
84      Web apps are loaded inside a special type of {{HTMLElement(
>"iframe")}}, using the {{HTMLAttrXRef("mozapp", "iframe")}} attri 
>bute; 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 descri 
>bes the Web app. 
85    </p>
86    <p>
87      In order to know what each Web app is allowed to do, each W
>eb app has an associated set of permissions. When the Web app att 
>empts to call certain sensitive APIs, the Firefox OS permission d 
>atabase is checked to ensure that the app has the requisite permi 
>ssion. If it doesn't, the call will not succeed. 
88    </p>
89    <p>
90      To prevent Web apps from interfering with one another, each
> one is hosted on a separate domain, and therefore may only acces 
>s the resources associated with its domain. These resources inclu 
>de 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, t 
>he photo gallery, media storage, USB devices, and so forth. 
91    </p>
92    <div class="note">
93      <p>
94        <strong>Note:</strong> That last bullet point is not nece
>ssarily final; you should assume that your app has access to noth 
>ing outside its own domain at all. 
95      </p>110      </li>
96    </div>111    </ul>
97    <h3 id="Content_processes">112    <h2 id="Content_processes">
98      <a name="Content_processes" id="Content_processes">Content 113      <a name="Content_processes" id="Content_processes">Content 
>processes</a>>process initialization</a>
114    </h2>
115    <p>
116      All web appplications run in a low-rights, separate process
 >: the Firefox OS <strong>content process</strong>. This process i
 >s launched by the <code>b2g</code> core process when it reaches a
 > special iframe type: <em>&lt;iframe mozapp&gt;</em>. This separa
 >tes the web application from the rest of the content and is stron
 >gly associated to a manifest (see the <a href="/en-US/docs/Mozill
 >a/Firefox_OS/Security/Application_security" title="/en-US/docs/Mo
 >zilla/Firefox_OS/Security/Application_security">Application Secur
 >ity</a> model for more information). The content processes are st
 >arted in the container called an "out of process" container, or a
 >n OOP. It is represented by the plugin-container process and uses
 > similar code to the plugin-container used by the desktop Firefox
117    </p>
99    </h3>118    <h3>
100    <p>119      Risks
101      It's important to understand what privileges content has, a
>nd what privileges are reserved for the core process. 
102    </p>
103    <div class="note">
104      <p>
105        <strong>Note:</strong> The Firefox OS core and content pr
>ocess separation is not enabled yet. 
106      </p>
107    </div>
108    <p>
109      All Web apps run in a low-rights, separate process: the Fir
>efox OS <strong>content process</strong>. This process is launche 
>d by the <code>b2g</code> core process using <code>fork()</code>  
>and <code>execve()</code>. File descriptors are handled using Fil 
>eMap, which closes them on object destruction, and before the for 
>k. Only a few select file descriptors are kept open in order to e 
>nable communication between the two processes. 
110    </p>
111    <p>
112      The content processes are sandboxed; this prevents the cont
>ent 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 conten 
113    </p>
114    <p>
115      Each Web app is loaded into separate content processes; thi
>s provides additional protection by reducing the number of attack 
> vectors each individual app has. Under ideal conditions, each ap 
>p is loaded into its own process; however, resource constraints m 
>ay require multiple apps to share a content process. When this ha 
>ppens, Firefox OS only groups apps with similar trust levels and  
>similar access levels to system resources. 
116    </p>
117    <p>
118      Each Firefox OS content process has access to a record indi
>cating 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 wh 
>ich the Web apps within them do not have access, unless they have 
> been compromised in some way. In the case of compromise, the cor 
>e process will enforce the permissions. By having multiple layers 
> of protection, security can be better assured. 
119    </p>
120    <p>
121      Through all of this, each Firefox OS content process is ass
>ociated 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 eac 
>h content process; if a message is detected which requests access 
> to an API that is outside that set of permissions, the core proc 
>ess denies the request. This should never happen under normal cir 
>cumstances, since the content process has already checked for thi 
>s and enforced permissions on its apps. 
122    </p>
123    <div class="note">
124      <p>
125        <strong>Note:</strong> If the core process detects an att
>empt to use an API without permission, the content process will b 
>e terminated and respawned. 
126      </p>
127    </div>
128    <h2 id="Protecting_the_operating_system">
129      Protecting the operating system
130    </h2>120    </h3>
131    <p>
132      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, an 
>d all system access is mediated through the Web APIs. In addition 
>, there's no direct access to the file system; files stored on th 
>e SD card are exposed using Web APIs as well. Because of this, th 
>e key potential threats to the underlying operating system are: 
133    </p>
134    <ul>
135      <li>Memory corruption or logical errors in Gecko that lead 
>to arbitrary code execution. 
136      </li>
137      <li>Similar faults in the operating system itself (the kern
>el and daemons) that lead to arbitrary code execution. 
138      </li>
139      <li>A compromise of the software update mechanism.
140      </li>
141      <li>Hijacking of a Web application using XSS or memory corr
>uption (for example). 
142      </li>
143      <li>A vulnerability in <a href="/en-US/docs/IPDL" title="/e
144      </li>
145    </ul>121    <ul>
146    <p>122      <li>Leak of information when spawning the web application's
 > content process
147      Mitigation of code execution threats is introduced by takin123      </li>
>g the following steps: 
148    </p>124      <li>Possibility to access operating system resources, escal
 >ate to the same level of privileges as the b2g process
125      </li>
126      <li>Bypassing the content process initialization
127      </li>
149    <ul>128    </ul>
150      <li>Gecko is hardened against attack (just like it is in Fi
151      </li>
152      <li>Web content is run in lower-rights child processes in o
>rder to reduce the impact a process compromise introduces. This i 
>s the Firefox OS <a href="#Content_processes" title="#Content_pro 
>cesses">content process</a>. 
153      </li>
154      <li>The underlying operating system is hardened to make pos
>t-exploitation more difficult. 
155      </li>
156      <li>When available, hardening features of the compiler are 
157      </li>
158    </ul>
159    <h3 id="Process_model_and_separation">
160      Process model and separation
161    </h3>129    <h3>
162    <p>130      Implementation
163      As previously explained, the Firefox OS process model is ba
>sed on the concept of a single core process (the parent process), 
> which has access to all hardware, services, and so forth, and on 
>e or more content processes (the children), each of which has onl 
>y enough access to the system to communicate with the parent proc 
164    </p>131    </h3>
165    <p>132    <h4>
166      In case of a vulnerability in a content process, the operat133      Initialization within the b2g process
>ing system limits the impact by denying system level resource acc 
>ess to the low-privilege content process. Compromising the core p 
>rocess is equivalent to complete compromise of the operating syst 
167    </p>
168    <p>
169      If a content process is compromised, this can lead to the a
>ccess of resources available to other applications running in the 
> same content process. 
170    </p>
171    <div class="note">
172      <p>
173        <strong>Note</strong><strong>:</strong> The Firefox OS de
>velopment team is investigating seccomp mode 2 (which requires a  
>kernel patch for versions below 3.5). This would allow content pr 
>ocesses to call <code>recv()</code>, <code>send()</code>, <code>e 
>xit()</code>, and any other system call that's whitelisted to sup 
>port <a href="/en-US/docs/WebGL" title="/en-US/docs/WebGL">WebGL< 
>/a>, such as <code>mmap()</code>. 
174      </p>
175    </div>
176    <p>
177      Calls to any other system routines are denied by the kernel
> for all content processes. 
178    </p>
179    <p>
180      Of course, the effectiveness of using low-rights content pr
>ocesses as a mitigation technique is also dependent upon the cont 
>rol of communication between children (that is, content processes 
>) and the parent process (the Firefox OS core process). 
181    </p>
182    <p>
183      <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 aut 
>horized 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 wh 
>enever possible. However, when deserialization must be done by Fi 
>refox OS code, a security review is required. In addition, any ti 
>me a deserialization error occurs, the responsible child process  
>is terminated. 
184    </p>
185    <h4 id="Future_improvements">
186      Future improvements
n189      There are future improvements planned to this model, includn136      In this order:
190    </p>
191    <ul>
192      <li>The ultimate goal is to have a finer level of separatio
>n 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 process 
193      </li>
194      <li>We plan to investigate running the Firefox OS core proc
>ess and the content processes in separate ARM <a href="http://www 
>" title="h 
195      </li>
196      <li>In addition, we plan to investigate Role Based Access C
>ontrol, enforced at the kernel level. This is done in RSBAC, SELi 
>nux, and other operating systems. There is a <a href="http://seli 
>" title=" 
>age/SEAndroid">similar project for Android</a>; in particular, se 
>e the <a href=" 
>epolicy/" title=" 
>/sepolicy/">security policy document</a>. 
197      </li>
198    </ul>
199    <h3 id="Operating_system_hardening">
200      Operating system hardening
201    </h3>
202    <p>137    </p>
203      Mozilla provides a reference implementation and recommendat138    <ol>
>ions for operating system security controls. 
139      <li>fork()
140      </li>
141      <li>setuid(new, different, unused user id|nobody) (which is
 > an unprivileged user)
142      </li>
143      <li>chrdir('/')
144      </li>
145      <li>execve('plugin-container')
146      </li>
147    </ol>
204    </p>148    <p>
205    <ul>149      This ensures the OOP process runs in a separate memory spac
 >e (new process) and as a low rights user that cannot elevate its 
 >privileges to the level of the b2g process.
206      <li>File system privileges are enforced by Linux's access c
>ontrol lists (ACLs). 
207        <ul>
208          <li>The Firefox OS core process runs as root, and has <
>code>CAP_DAC_READ_SEARCH</code> (among other capabilities). Becau 
>se of this, ACLs are not a security measure for this process. 
209          </li>
210          <li>Content processes are run as a regular user, with v
>ery restricted access. 
211          </li>
212        </ul>
213      </li>
214      <li>Review of system daemon (<code>wpa_supplicant</code>, <
>code>gpsd</code>, and so forth) configurations. 
215      </li>
216      <li>Compilation of the software with full address space lay
>out randomization (ASLR) support (including the linker), as well  
>as using SSP/PIE binaries has been found to have a significant im 
>pact on runtime performance. 
217      </li>
218    </ul>150    </p>
219    <h4 id="Mount_point_configurations">151    <h4>
220      Mount point configurations152      File Descriptor handling
nn154    <ul>
155      <li>White list method - a list of permitted file descriptor
 >s (FD) is created and stored in the mFileMap object
156      </li>
157      <li>All unlisted FDs are forcefully closed in LaunchApp(), 
 >after fork() (where FDs are copied), and before execve()
158      </li>
159    </ul>
160    <p>
161      Unlike the more traditional method which uses a blacklist (
 >Close-on-exec flag: CLOEXEC), this ensures not FD is left open, a
 >nd is therefore more reliable.
222    <p>162    </p>
223      The mount points are configured as follows (more options ma163    <h2>
>y be set, but will be similar to the below): 
164      <a name="File_system_hardening" id="File_system_hardening">
 ></a>File system hardening
165    </h2>
166    <h3>
167      Risks
168    </h3>
169    <ul>
170      <li>Writing, deleting or reading files belonging to another
 > user - this could result in an information leak or unexpected be
 >havior, eg. privilege escalation etc.
171      </li>
172      <li>Execution of native code via an application vulnerabili
173      </li>
174      <li>Vulnerabilities in setuid programs (and thus, privilege
 > escalation)
175      </li>
176    </ul>
177    <h3>
178      Implementation
179    </h3>
180    <p>
181      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 opti
 >ons. The filesystem mounts are restricted as follow:
n382    <h4 id="Future_plans">n
383      Future plans
384    </h4>
385    <p>
386      A few of the things we're considering investigating in the 
387    </p>
388    <ul>
389      <li>
390        <a href="
>;a=commit;h=9aea04aa892903009e487ada7f7b911691e68630" title="http 
>92903009e487ada7f7b911691e68630">CoreBoot</a> secure booting supp 
>ort, like in Chrome OS., or enhancements to fastboot. 
391      </li>
392      <li>See also the <a href="
>os/chromiumos-design-docs/system-hardening" title="http://www.chr 
>rome OS system hardening documentation</a>. 
393      </li>
394      <li>Investigate getting full ASLR turned on, with improved 
395      </li>
396    </ul>
397    <h3 id="OS_updates">
398      OS updates
399    </h3>340    <h3>
341      <span class="mw-headline" id="Linux_DAC">Linux DAC</span>
400    <p>342    </h3>
401      Operating system updates include everything except the Geck
>o layer, which has its own update process; see {{anch("Gecko upda 
>tes")}}. Operating system updates are issued when a user-impactin 
>g bug or security bug is fixed, or when required for a major Fire 
>fox OS upgrade. 
402    </p>343    <p>
344      The Linux DAC represents the well-known Linux filesystem pe
 >rmission model.
403    <p>345    </p>
404      OS updates can be performed in two ways:
405    </p>
406    <dl>
407      <dt>
408        Over the air (OTA)
409      </dt>
410      <dd>
411        OTA updates can be performed wirelessly; however, this me
>chanism hasn't been functionally defined yet for Firefox OS. It w 
>ill be similar to the mechanism used by Android, however. 
412      </dd>
413      <dt>
414        Using a firmware image
415      </dt>
416      <dd>
417        If an OTA upgrade fails (due to a power issue, hardware f
>ailure, or the like), the device may become "bricked"; that is, i 
>t may no longer be able to run the operating system so that an OT 
>A update can be performed. In that scenario, you can connect the  
>device to a computer using a USB cable and use the fast bootloade 
>r to install a firmware image. 
418      </dd>
419    </dl>
n422        <strong>Note:</strong> A firmware image can be used to ren348        <strong>Note:</strong> This is the traditional User/group
>place Firefox OS with another operating system, as well as to upg>/others - and NOT the Linux POSIX 1.e ACLs
>rade Firefox OS. 
n425    <p>n351    <ul>
426      There are several security measures taken during the update352      <li>The web application system user has no write access to 
> process:>any file
427    </p>353      </li>
354      <li>The usage of setuid binaries is limited to where necess
355      </li>
356      <li>New content processes are started with a sane umask
357      </li>
428    <ul>358    </ul>
359    <h2>
360      <a name="System_updates" id="System_updates"></a>Secure Sys
 >tem Updates
361    </h2>
362    <h3>
363      Risks
364    </h3>
365    <ul>
366      <li>Compromised update package data, resulting in an untrus
 >ted update package being installed
367      </li>
368      <li>Compromised update check
369        <ul>
370          <li>User does not see new updates are available
371          </li>
372          <li>User is gets an out of date package as update, whic
 >h effectively downgrade the software on his device
373          </li>
374        </ul>
375      </li>
376      <li>System state compromised or unknown during the installa
 >tion of the update, for example, this may lead to:
377        <ul>
378          <li>Missing elements during the installation, some of w
 >hich may be security fixes
379          </li>
380          <li>Security fixes reverted by the compromised system a
 >fter upgrade
381          </li>
382        </ul>
383      </li>
384      <li>Vulnerabilities in the update checking mechanism runnin
 >g on the device
385      </li>
386      <li>Lack of updates or tracking for a software component wi
 >th a known vulnerability
387      </li>
388    </ul>
389    <h2 id="Secure_System_Updates">
390      Implementation
391    </h2>
392    <p>
393      Subsequent upgrades and patches to the Firefox OS platform 
 >are deployed using a secure Mozilla process that ensures the ongo
 >ing 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 digit
 >ally signing the update package.
394    </p>
395    <h3>
396      FOTA updates
397    </h3>
398    <p>
399      System updates can involve all or a portion of the Firefox 
 >OS stack. If changes to Gonk are included in the update, then FOT
 >A (Firmware Over the Air) is the install process used. FOTA updat
 >es can also include any other part of the Firefox OS stack, inclu
 >ding device management (FOTA, firmware / drivers), settings manag
 >ement (Firefox OS settings), security updates, Gaia, Gecko, and o
 >ther patches.
400    </p>
401    <h3>
402      MSU/MAR updates
403    </h3>
404    <p>
405      Updates that do not involve Gonk can be done using the Mozi
 >lla System Update Utility. Firefox OS uses the same update framew
 >ork, processes, and Mozilla ARchive (MAR) format (used for update
 > packages) as the Firefox Desktop product. For more information, 
 >see <a class="external" href="
406    </p>
407    <h3>
408      Update service
409    </h3>
410    <div class="note">
411      <p>
412        <strong>Note:</strong> The update service may be provided
 > by the OEM
413      </p>
414    </div>
415    <p>
416      A built-in update service on the mobile phone periodically 
 >checks for system updates. Once a system package becomes availabl
 >e 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 app
 >ly the update, and the distribution is verified for:
417    </p>
418    <ul>
419      <li>update origin (verify the source location protocol:doma
 >in:port of the system update and manifest)
420      </li>
421      <li>file integrity (cryptographic hash checksums)
422      </li>
423      <li>code signature (certificate check against a trusted roo
424      </li>
425    </ul>
426    <p>
427      The following security measures are used during the update 
428    </p>
429    <ul>
430      <li>Mozilla recommends and expects that updates are fetched
 > over an SSL connection with a trusted certificate.
431      </li>
429      <li>Strong cryptography verification is required before ins432      <li>Strong cryptographic verification is required before in
>talling a firmware package.>stalling a firmware package.
n433      <li>The system must be in a secure state when the update prn436      <li>The system must be in a secure state when the update pr
>ocess starts, with no Web apps running.>ocess starts, with no web applications running.
t438    <h3 id="Gecko_updates">t
439      Gecko updates
440    </h3>
441    <p>
442      Gecko updates itself using the same mechanism used by Firef
>ox on desktop computers: 
443    </p>441    <p>
444    <ul>442      Rigorous checks are in place to ensure that the update is a
 >pplied properly to the mobile phone.
445      <li>The updates are fetched over an SSL connection.
446      </li>
447      <li>SSL certificates' issuer names are pinned in Firefox OS
448      </li>
449      <li>Updates are signed in their update files, which are in 
><a href="" title="htt 
>ps://">MAR format</a>. 
450      </li>
451    </ul>
452    <p>443    </p>
453      The Gecko updater is not yet implemented; see {{bug(715816)
>}} to track its progress. 
454    </p>
455    <h2 id="Protecting_user_data">
456      Protecting user data
457    </h2>
458    <p>
459      The boot loader, fastboot, enforces erasure of user data wh
>en the boot loader is unlocked (<code>fastboot oem unlock</code>) 
>. This makes extracting user data more difficult. 
460    </p>
461    <p>
462      However, if an untrusted party gains physical access to an 
>unlocked device, user data is unprotected. 
463    </p>
464    <h3 id="Future_plans">
465      Future plans
466    </h3>
467    <p>
468      In the future, we plan to implement full disk encryption. T
>here are some issues being considered, however: 
469    </p>
470    <ul>
471      <li>Encryption depends on the device's password; this can b
>e a usability issue. 
472      </li>
473      <li>We will investigate the option of unlocking at boot tim
>e only; this is less secure but not terribly so. This might be do 
>ne using a configuration option, so that it this less secure mode 
> can be selected depending on the user's preference. 
474      </li>
475      <li>There is the risk of users forgetting their encryption 
>password; if this happens, they lose access to the data on their  
476      </li>
477    </ul>

Back to History