diff options
Diffstat (limited to 'files/zh-cn/archive/b2g_os/security')
3 files changed, 481 insertions, 0 deletions
diff --git a/files/zh-cn/archive/b2g_os/security/application_security/index.html b/files/zh-cn/archive/b2g_os/security/application_security/index.html new file mode 100644 index 0000000000..cb986bfc9d --- /dev/null +++ b/files/zh-cn/archive/b2g_os/security/application_security/index.html @@ -0,0 +1,126 @@ +--- +title: 应用安全 +slug: Archive/B2G_OS/Security/Application_security +translation_of: Archive/B2G_OS/Security/Application_security +--- +<div class="summary"> + <p>本文对Firefox OS 应用安全进行了详细阐述。</p> +</div> +<p>由Firefox OS 引入的关键性Web应用控制包含如下几个方面： </p> +<ul> + <li>Web应用需要真正的安装和启动，而不是在浏览器中随意的导航而转到对应页面。应用在使用之前必须预安装到手机上，安全控制系统会对应用的更新和删除进行管理以保护用户的安全。</li> + <li>是否允许访问新的web API 是由权限系统控制的，即应用程序必须声明它打算使用之前安装的权限。为了获取对功能更强的API的使用权限，这些应用需要满足一定的要求，还要被Marketplace审查，批准，并签名通过。</li> + <li>Web应用是一个沙箱，在其中只能看到它们自己的资源（包括cookies, 离线存储IndexedDB 数据库等).即便两个应用从相同的URL装载页面，这两个页面也不会看作是同源的，因为它们是运行在单独的应用中的。</li> +</ul> +<h3 id="应用安全">应用安全</h3> +<p>FirefoxOS 支持三种类型的web应用: "<strong>web</strong>", "<strong>privileged</strong>" 以及 "<strong>certified</strong>".一个应用的类型是在它的 <a href="/en-US/docs/Apps/Manifest" title="/en-US/docs/Apps/Manifest">manifest</a> 中声明的,同时也就决定了它能请求的权限列表。 </p> +<ul> + <li><strong>Web Apps:</strong> 绝大多数第三方应用程序都是 "web" apps, 而且它也是一种默认类型。除了已经暴露给Web的权限外，它不会授予应用程序任何其他的权限。Web应用可以从任何网站上安装，而且不会进行任何进一步的验证。它们也可以被<a href="/en-US/docs/Web/Apps/Packaged_apps">打包</a>，但打包时不会允许应用具有任何其他的权限。</li> + <li><strong>Privileged Apps</strong>: 这些应用会被允许增加权限，而且它们必须要被Marketplace认证通过。</li> + <li><strong>Certified Apps: </strong>Certified apps 是指由OEM选定并预安装在设备上的应用。</li> +</ul> +<div class="note"> + <p><b>注意</b>: 要进一步的了解这三种类型，可以参考 <a href="/en-US/docs/Apps/Manifest#type" title="/en-US/docs/Apps/Manifest#type">App Manifest</a> 文档。</p> +</div> +<h3 id="应用交付">应用交付</h3> +<p>在Firefox OS 中，应用可以通过托管和打包这两种不同的机制交付。常规的web应用可以使用任何一种方式交付，而 privileged 和 certified 应用则必须要打包才能交付。</p> +<h4 id="托管的应用">托管的应用</h4> +<p>托管的应用程序中在开发者web服务器中只包含一个<a href="/en-US/docs/Apps/Manifest">应用程序manifest</a>文件,而这个文件会指向应用的index文件(通常会被称作安装路径)。通常manifest文件也会指向一个appcache manifest文件：这个文件会将应用的信息缓存起来，从而使应用启动时更加快速而且能够离线使用；同时这个文件在其他方面则不会对应用造成任何影响。 从安全的角度来看，托管的应用更像是通常的web站点。当托管应用加载时，加载页面的URL其实就是这些页面在它们web服务器的一般的URL地址。因此要链接应用中一个特定的页面或资源， 使用的URL地址与在web站点链接到那个页面的URL地址是相同的。</p> +<h4 id="打包的应用">打包的应用</h4> +<p><b>一个打包的应用</b> 是一个开放的Web应用，会在本地zip文件中存放有关应用的所有资源（包括 HTML, CSS, JavaScript, app manifest 等) contained in a zip file, 而不是将资源存放在web服务器上。要了解更多的细节，可参考<a href="/en-US/docs/Apps/Packaged_apps" title="Apps/Packaged_apps"> Packaged apps</a>. </p> +<h3 id="应用安装"><b>应用安装</b></h3> +<p>应用是通过 <a href="/en-US/docs/JavaScript_API" title="/en-US/docs/JavaScript_API">Apps Javascript API</a> 来安装的:</p> +<ul> + <li>托管的应用 : 托管的应用是通过调用 <code>navigator.mozApps.<a href="/en-US/docs/Web/API/Apps.install" title="/en-US/docs/Web/API/Apps.install">install</a>(manifestURL)方法来安装的</code>, 其中 manifestURL 是一个URL用来指定应用位置的。要了解更多的细节，可参考 <a href="/en-US/docs/DOM/Apps.install">Installing Apps</a>.</li> + <li>打包的应用: 打包的应用是用过调用<code>navigator.mozApps.<a href="/en-US/docs/Web/API/Apps.installPackage" title="/en-US/docs/Web/API/Apps.installPackage">installPackage</a>(packageURL)方法来安装的。对打包的应用而言，应用程序的manifest文件存放在它自身的包内，因此是已经认证过的。</code> 还有第二个"mini-manifest"用来启动和安装应用。可参考 <a href="/en-US/docs/DOM/Apps.installPackage">Installing Packaged Apps</a> 和<a href="/en-US/docs/Apps/Packaged_apps" title="Apps/Packaged_apps"> Packaged apps</a> 来获取更多的信息。</li> +</ul> +<p>为了能保证一个应用能够想要作为一个web应用来安装，我们必须确保不能使一个网站假冒托管的应用程序清单。 我们会要求manifest要提供一个具体的mime-type <code>application/x-web-app-manifest+json。当manifest应用和和应用 manifest请求的页面相同，都是请求应用安装的页面时，这种限制才是放开的。</code></p> +<h3 id="更新">更新</h3> +<p>有关应用更新的过程是在 <a href="/en-US/docs/Apps/Updating_apps" title="Apps/Updating_apps">Updating apps</a> 有详细描述。</p> +<h2 id="权限">权限</h2> +<p>应用可以被授予在正常的网页最高权限之外的权限。默认情况下，应用会和正常的web页面拥有同样的权限，为了能够得到额外的权限，第一步就是在应用程序maifest文件中列出它想要的额外权限。 </p> +<h3 id="Manifest_声明">Manifest 声明</h3> +<p>对每一个应用需要的额外权限，manifest文件必须要在manifest中列出该权限，并且以人类可阅读的描述解释为什么应用需要访问这个权限。例如，如果应用需要使用 <a href="/en-US/docs/Web/API/window.navigator.geolocation" title="/en-US/docs/Web/API/window.navigator.geolocation">navigator.geolocation</a> API, 它就必须在manifest中如下声明：</p> +<pre class="brush: html">"permissions": { + "geolocation":{ +<code class="language-js"><span class="token string"> "description"</span><span class="token punctuation">:</span> <span class="token string">"Required for autocompletion in the share screen"</span><span class="token punctuation">,</span></code> + } +}, +</pre> +<p>This allows the app to then prompt for the geolocation permission, in the same way that a web page normally would. For further detail on manifests, see <a href="/en-US/docs/Apps/Manifest" title="Apps/Manifest">App manifest</a>.</p> +<div class="note"> + <p><strong>Note</strong>: Currently permissions usage intentions are not exposed to the user — see <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=823385" title="https://bugzilla.mozilla.org/show_bug.cgi?id=823385">bug 823385</a>.</p> +</div> +<h3 id="授予权限">授予权限</h3> +<p>When permissions are requested in the manifest, the permission is either set to <em>allow</em> or <em>prompt</em>, depending on the permissions. Allow permissions are granted by virtue of being declared in the manifest with no further approval needed. For prompt permissions, the user is prompted the first time the user accesses the related API, and has to make a choice prior to the API being granted. In general, Firefox OS only prompts users for permissions that have a privacy impact, and it is reasonable for the user to understand what they are being asked. For example, access to contacts is prompted, but access to make a raw TCP connection is implicitly granted since it is not reasonable for a user to understand the security implications of allowing this permission. Use of allow permissions is reviewed as part of Marketplace security review processes to ensure users are protected.</p> +<h3 id="撤销权限">撤销权限</h3> +<p>Users are allowed to change their mind about prompt permissions at any time, and can revoke these permissions via the Firefox OS settings app. Allow permissions are not user configurable, however.</p> +<h2 id="Web_应用沙箱">Web 应用沙箱</h2> +<h3 id="Data_stored_per_app_2"><span class="mw-headline" id="Data_stored_per_app">Data stored per app </span></h3> +<p>Each app runs in as a separate sandbox, meaning that all data stored by an app is separate from all data stored by another app. This includes things like cookie data, localStorage data, indexedDB data, and site permissions.</p> +<p><img alt="A diagram showing three Firefox OS apps all open is separate sandboxes, so none of them can affect each other." src="https://mdn.mozillademos.org/files/7091/sandbox.png" style="width: 1040px; height: 437px; display: block; margin: 0px auto;"></p> +<p>This means that if the user has two apps installed, App A and App B, these apps will have a completely different set of cookies, different local data, and different permissions. This even applies if both of these apps open an <a href="/zh-CN/docs/Web/HTML/Element/iframe" title="HTML内联框架元素 <iframe> 表示嵌套的浏览上下文，有效地将另一个HTML页面嵌入到当前页面中。在HTML 4.01中，文档可能包含头部和正文，或头部和框架集，但不能包含正文和框架集。但是，<iframe>可以在正常的文档主体中使用。每个浏览上下文都有自己的会话历史记录和活动文档。包含嵌入内容的浏览上下文称为父浏览上下文。顶级浏览上下文（没有父级）通常是浏览器窗口。"><code><iframe></code></a> that points to the same origin. i.e. if both App A and App B open an <code><iframe></code> pointing to "<a class="external free" href="http://www.mozilla.org" rel="nofollow">http://www.mozilla.org</a>", they will both render the website, however the website will be fetched and rendered with different cookies in the two apps.</p> +<p>A result of this is that if the user logs in to, for example, Facebook while using App A, this in no way affects App B's ability to interact with the user's account on Facebook. The login cookie that Facebook sets when the user logs in using App A is only available in App A. If App B opens an <code><iframe></code> to Facebook, the cookie wouldn't be there and so when App B opens Facebook, it receives the Facebook login page rather than the user's account.</p> +<h3 id="Apps_can't_open_each_other"><span class="mw-headline" id="Apps_can.27t_open_each_other">Apps can't open each other </span></h3> +<p>This means that apps can't open other apps by using iframes. If App A creates an <code><iframe></code> with the <code>src</code> set to the URL of App B, this won't actually open App B in the <code><iframe></code>. It will simply open the website located at that URL. It will not use any of App B's cookies and so it will behave no differently than if App B wasn't installed on the user's device.</p> +<p>This applies even for packaged apps (more about them below). If App A tries to open the packaged App B using an <code><iframe></code> pointing to the <code>app://</code> URL of App B, this will simply fail to load. If this results in a 404 or some other type of error is still to be determined, but it will definitely fail to load. And it will fail in the same way no matter if App B is installed on the user's device or not, as to make it impossible for App A to determine if App B is installed.</p> +<p>The same thing happens if the top-level frame of App A is navigated to a URL for App B. We always know for a given frame which app is opened in it, therefore when attempting to load the App B URL in the App A frame, this will behave exactly like the two situations described above, i.e. in no way will App B's resources, like cookies or other local data, be used.</p> +<h3 id="Motivation_2"><span class="mw-headline" id="Motivation">Motivation</span></h3> +<p>There are both benefits and downsides to this approach. The downside is that if the user interacts with the same web site through several apps, he/she will have to log in to every app. Likewise, if a web site wants to store data locally, and the user interacts with this web site in several apps, the data will end up getting duplicated in each app, which could be a problem if it's a large amount of data.</p> +<p>The main benefit of this approach is that it's a more stable model. There is no way that several apps could interact with each other through a third-party website in unexpected ways such that installing an app causes another app to stop working. When an app is uninstalled there is no way that data for another app could be lost, or that another app will stop working due to functional dependence on the uninstalled app.</p> +<p>There are also large security benefits. A user can safely use his AwesomeSocial app to log in to Facebook without having to worry that the SketchGame app can mount any type of attack for getting at the user's Facebook data by exploiting bugs or other shortcomings in the Facebook web site.</p> +<p>There are also good privacy benefits. The user can safely install the PoliticalPartyPlus app without having to worry that MegaCorpEmployeeApp will be able to detect that the app was installed or what data it has created.</p> +<h3 id="Sandboxed_权限"><span class="mw-headline" id="Sandboxed_Permissions">Sandboxed 权限</span></h3> +<p>In the same way that web site data is sandboxed per app, so is permission data. If App A loads a page from <a class="external free" href="http://maps.google.com" rel="nofollow">http://maps.google.com</a> and that page requests to use geolocation and the user says "yes, and remember this decision for all times", this only means that <a class="external free" href="http://maps.google.com" rel="nofollow">http://maps.google.com</a> has access to geolocation within App A. If App B then opens <a class="external free" href="http://maps.google.com" rel="nofollow">http://maps.google.com</a>, that page won't have access to geolocation unless the user grants that permission again.</p> +<p>And just like in the normal browser, permissions are separated by origin. If App A is granted permission to use Geolocation, this does not mean that all origins running in App A have the permission to use Geolocation. If App A opens an <code><iframe></code> to <a class="external free" href="http://maps.google.com" rel="nofollow">http://maps.google.com</a>, then <a href="http://docs.google.com"><span class="external free">http://docs.google.com</span></a> still has to ask the user for permission before geolocation access is granted.</p> +<h3 id="浏览器_API_沙箱">浏览器 API 沙箱</h3> +<p>To additionally secure applications that open a large set of URLs, such as browsers, we have added a <em>browserContent flag</em>. The browserContent flag allows each app to have not one, but two sandboxes: one for the app itself, and one for any "web content" that it opens. For example:</p> +<p>Say that the MyBrowser app is loaded from the <a class="external free" href="https://mybrowser.com" rel="nofollow">https://mybrowser.com</a> domain. This is the domain the scripts and resources are loaded within. The scripts and resources + <i> + belong</i> + to this domain.</p> +<p>Now, if a page in this app creates an <code><iframe mozbrowser></code>, a different sandbox is created and used for this <code><iframe></code>, which is different from the sandbox used by the app. So for example if this <code><iframe></code> is navigated to <a class="external free" href="https://mybrowser.com" rel="nofollow">https://mybrowser.com</a>, it will result in different cookies being used inside the <code><iframe mozbrowser></code>. Likewise, the contents inside the <code><iframe mozbrowser></code> will see different IndexedDB and localStorage databases from the ones opened by the app.</p> +<p>This also applies if the MyBrowser app wants to create integration with, for example, Google Maps to implement location-based browsing. If the app opens an <code><iframe></code> to <a class="external free" href="http://maps.google.com" rel="nofollow">http://maps.google.com</a>, it will receive a set of cookies for the <a class="external free" href="http://maps.google.com" rel="nofollow">http://maps.google.com</a> website. If the user then navigates inside the <code><iframe mozbrowser></code> containing <a class="external free" href="http://maps.google.com" rel="nofollow">http://maps.google.com</a>, this will use different cookies and different permissions to the top level app.</p> +<p>Another example where this is useful is in a Yelp-like app. Yelp has the ability to visit a restaurant's website directly in the app. By using <code><iframe mozbrowser></code> to open the restaurant website, the Yelp app ensures that the restaurant website can't contain an <code><iframe></code> pointing back to Yelp's app (which points to <a class="external free" href="http://yelp.com" rel="nofollow">http://yelp.com</a>). If it does, the website will only receive the Yelp website, rather than the Yelp app. So there is no way that the restaurant website can mount an attack against the app since the contained Yelp website won't share any permissions or data with the Yelp app.</p> +<h2 id="应用安全小结">应用安全小结</h2> +<p>The table below summarizes the different types of Firefox OS apps, and describes the format, installation, and update processes for open web apps running on Firefox OS.</p> +<table> + <caption> + Web App Types</caption> + <thead> + <tr> + <th scope="col">Type</th> + <th scope="col">Delivery</th> + <th scope="col">Permission Model</th> + <th scope="col">Installation</th> + <th scope="col">Updates</th> + </tr> + </thead> + <tbody> + <tr> + <td>Web</td> + <td>Hosted or Packaged</td> + <td>Less sensitive permissions, which are not dangerous to expose to unvalidated web content.</td> + <td>Installed from anywhere</td> + <td>Can be updated transparently to user or explicitly via a marketplace, depending on where the app was installed from, and the delivery mechanism.</td> + </tr> + <tr> + <td>Privileged</td> + <td>Packaged & Signed</td> + <td>Privileged APIs requiring validation and authentication of the app.</td> + <td>Installed from a trusted marketplace</td> + <td>Updated via a trusted marketplace, user prompted to approve download and installation of updates.</td> + </tr> + <tr> + <td>Certified</td> + <td>Packaged</td> + <td>Powerful and dangerous APIs not available to third-party apps.</td> + <td>Pre-installed on the device</td> + <td>Updated only as part of system level updates.</td> + </tr> + </tbody> +</table> +<div class="note"> + <p><strong>Note</strong>: For version 1.0 of Firefox OS, although web apps can be installed from any website/marketplace, privileged apps can only be installed from the Mozilla Marketplace, as support for multiple trusted marketplaces is not yet complete.</p> +</div> +<p> </p> diff --git a/files/zh-cn/archive/b2g_os/security/index.html b/files/zh-cn/archive/b2g_os/security/index.html new file mode 100644 index 0000000000..18730f4b81 --- /dev/null +++ b/files/zh-cn/archive/b2g_os/security/index.html @@ -0,0 +1,70 @@ +--- +title: Firefox OS security +slug: Archive/B2G_OS/Security +tags: + - B2G + - Firefox OS + - Mobile + - NeedsTranslation + - Security + - TopicStub +translation_of: Archive/B2G_OS/Security +--- +<p>下面文章介绍了 Firefox OS 安全相关的主题。其中包括安全特征概要，应用安全以及如果使安装进程保证安全。</p> +<table class="topicpage-table"> + <tbody> + <tr> + <td> + <h2 class="Documentation" id="Documentation" name="Documentation">Firefox OS 安全文档 </h2> + <dl> + <dt> + <a href="/en-US/docs/Mozilla/Firefox_OS/Security/Security_model" title="/en-US/docs/Mozilla/Firefox_OS/Security/Security_model">Firefox OS 安全模型</a></dt> + <dd> + Firefox OS 安全模型</dd> + <dt> + <a href="/en-US/docs/Mozilla/Firefox_OS/Security/System_security" title="/en-US/docs/Mozilla/Firefox_OS/Security/Security_model">系统安全</a></dt> + <dd> + FirefoxOS 运行时内部的安全控制细节</dd> + <dt> + <a href="/en-US/docs/Mozilla/Firefox_OS/Security/Application_security" title="/en-US/docs/Mozilla/Firefox_OS/Security/Application_security">Firefox OS 中的应用安全</a></dt> + <dd> + 在 Firefox OS 如何使应用安全概要</dd> + <dt> + <a href="/en-US/docs/Mozilla/Firefox_OS/Security/Installing_and_updating_applications" title="/en-US/docs/Mozilla/Firefox_OS/Security/Installing_and_updating_applications">安全安装和更新应用</a></dt> + <dd> + Firefox OS 如何安全的安装和更新应用</dd> + <dt> + <a href="https://developer.mozilla.org/en-US/docs/Mozilla/Firefox_OS/Security/Debugging_and_security_testing" title="/en-US/docs/Mozilla/Firefox_OS/Security/Debugging_and_security_testing#Marionette.3A_A_JavaScript_debugging_shell_for_Firefox_OS">对 Firefox OS 的调试和安全测试 </a></dt> + <dd> + 本指南介绍了基本的安全测试步骤，从打开远程的 JavaScript 调试器到在Firefox OS 桌面版本中设置一个拦截 HTTP(S) 代理</dd> + </dl> + <p><span class="alllinks"><a href="/en-US/docs/tag/B2G" title="/en-US/docs/tag/B2G">查看全部...</a></span></p> + </td> + <td> + <h2 class="Community" id="Community" name="Community">从社区获得帮助</h2> + <p>如果您正在为 Firefox OS 工作或者开发一个运行在 Firefox OS 设备上的应用，这里有一些社区资源可以帮助您！</p> + <ul> + <li>咨询 Boot to Gecko 项目论坛: <ul> + <li><a href="https://lists.mozilla.org/listinfo/dev-b2g"> 邮件列表</a></li> + + + <li><a href="http://groups.google.com/group/mozilla.dev.b2g"> 新闻组</a></li> + <li><a href="http://groups.google.com/group/mozilla.dev.b2g/feeds"> Web feed</a></li> +</ul></li> + <li>在 Mozilla's Boot to Gecko IRC 上提问: <a class="link-irc" href="irc://irc.mozilla.org/b2g" title="irc://irc.mozilla.org/b2g">#b2g</a></li> + </ul> + <p><span class="alllinks"><a class="external" href="http://www.catb.org/~esr/faqs/smart-questions.html" title="http://www.catb.org/~esr/faqs/smart-questions.html">不要忘记提问的艺术...</a></span></p> + <br> + <h2 class="Related_Topics" id="Related_Topics" name="Related_Topics">相关主题</h2> + <ul> + <li><a href="/en-US/docs/Mobile" title="en-US/docs/Mobile">Mobile</a></li> + <li><a href="/en-US/docs/Security" title="/en-US/docs/Security">Security</a></li> + </ul> + </td> + </tr> + </tbody> +</table> +<p> </p> +<div id="cke_pastebin" style="position: absolute; top: 483px; width: 1px; height: 1px; overflow: hidden; left: -1000px;"> + <br> + Firefox OS</div> diff --git a/files/zh-cn/archive/b2g_os/security/security_model/index.html b/files/zh-cn/archive/b2g_os/security/security_model/index.html new file mode 100644 index 0000000000..f7c2247523 --- /dev/null +++ b/files/zh-cn/archive/b2g_os/security/security_model/index.html @@ -0,0 +1,285 @@ +--- +title: Firefox OS security overview +slug: Archive/B2G_OS/Security/Security_model +tags: + - B2G + - Firefox OS + - IPC + - IPDL + - Mobile + - 安全 + - 指南 +translation_of: Archive/B2G_OS/Security/Security_model +--- +<div class="summary"> + <p><span class="seoSummary">本文对 Mozilla Firefox OS 安全架构进行了概述，包括包括保护移动设备不受平台， apps 和 数据的威胁。在 Firefox OS 中，Mozilla 实现了完整，多层次的安全模型，为移动电话提供了绝佳的防护效果。</span></p> +</div> +<h2 id="平台安全">平台安全</h2> +<p>Firefox OS 平台使用了多层次的安全模型，可将各层级的开发风险降至最低。第一线的保护机制与深入防护策略相结合，进而为移动电话提供了完成的防护效果。</p> +<h3 id="安全架构">安全架构</h3> +<p>Firefox OS 将基于网页的应用与底层的硬件结合起来了。这个集成技术栈包括下面几个等级：</p> +<p><img alt="" src="https://mdn.mozillademos.org/files/5023/platform.png" style="width: 678px; height: 478px;"></p> +<ul> + <li>Gaia: 构建用户体验的 web apps 套件( app 中包括 HTML5, CSS, JavaScript, images, media,等)。</li> + <li>Gecko: 提供 app 运行框架以及实现用来访问移动设备功能的 Web API 的应用程序运行层级。</li> + <li>Gonk: 底层 Linux 内核(kernle)，系统库，固件以及运行在上面的设备驱动。</li> + <li>The mobile device: 运行 Firefox OS 的移动设备</li> +</ul> +<p>Gecko 扮演的是守门人的角色，为避免对移动设备的误用，它会强制执行安全策略。 Gecko 层 web apps（Gaia 层）与 手机之间的中间阶层。Gonk 则可将移动手机底层的硬件功能直接给 Gecko 层使用。 只有在 Gecko 允许访问请求时， Web apps 才可以通过 Web APIs 访问移动手机的功能 — 而不会有直接存取或走后门的情况产生。Gecko 会强制执行权限并阻止对未授权请求的访问。</p> +<h3 id="部署安全系统">部署安全系统</h3> +<p>将 Firefox OS 安装在智能手机上。原始系统的镜像文件是由已知，可信任的源所创建的 — 通常是设备 OEM — 它主要负责<span id="ouHighlight__0_9TO0_1">装配</span><span id="ouHighlight__10_10TO2_2">、</span><span id="noHighlight_0.9961474102491263"> </span><span id="ouHighlight__12_19TO4_5">构建</span><span id="ouHighlight__20_20TO6_6">、</span><span id="noHighlight_0.9553509446423349"> </span><span id="ouHighlight__22_28TO8_9">测试</span><span id="ouHighlight__31_33TO10_10">和</span><span id="ouHighlight__35_43TO11_14">对发布包进行签名。</span></p> +<p>整个技术层都需要经过安全验证。文件系统权限检查是由 Linux's 访问控制清单 (ACLs) 所强制执行的。系统应用都安装在一个只读的空间中（除了更新过程外，这是可能是短暂的可读写的）;一般而言，只有包含用户内容的区域才可能可读写。Various components within the device hardware have built-in protections that are implemented by default as standard industry practice — chipset manufacturers, for example, employ hardening techniques to reduce vulnerabilities. The core platform (Gecko and Gonk) is hardened to strengthen its defense against potential threats, and hardening features of the compiler are used where applicable. For further details see <a href="/en-US/docs/Mozilla/Firefox_OS/Security/Runtime_security" title="/en-US/docs/Mozilla/Firefox_OS/Security/Runtime_security">Runtime security</a>.</p> +<h3 id="更新安全系统">更新安全系统</h3> +<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> +<p>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.</p> +<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.</p> +<p>A built-in update service — which may be provided by the OEM — 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 (SHA-256 hash check)</li> + <li>Code signature (certificate check against a trusted root)</li> +</ul> +<p>在更新过程中会使用下面的安全措施：</p> +<ul> + <li>Mozilla recommends and expects that updates are fetched over an SSL connection.</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 apps 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> +<div class="note"> + <p><strong>Note</strong>: For more information on how thee updates work and how to create and distribute updates, read <a href="/en-US/Firefox_OS/Building_and_installing_Firefox_OS/Creating_Firefox_OS_update_packages">Creating and applying Firefox OS update packages</a>.</p> +</div> +<h2 id="App_安全">App 安全</h2> +<p>Firefox OS uses a defense-in-depth security strategy to protect the mobile phone from intrusive or malicious applications. This strategy employs a variety of mechanisms, including implicit permission levels based on an app trust model, sandboxed execution at run time, API-only access to the underlying mobile phone hardware, a robust permissions model, and secure installation and update processes. For technical details, refer to <a href="/en-US/docs/Mozilla/Firefox_OS/Security/Application_security" title="/en-US/docs/Mozilla/Firefox_OS/Security/Application_security">Application security.</a></p> +<p>In Firefox OS, all applications are web apps — programs written using HTML5, JavaScript, CSS, media, and other open web technologies (pages running within the browser are not referred to as web apps in this context). Because there are no binary ("native") applications installed by the user, all system access is mediated strictly through the Web APIs. Even access to the file system happens only through Web APIs and a back-end SQLite database — there is no direct access from apps to files stored on the SD card.</p> +<p>Firefox OS limits and enforces the scope of resources that can be accessed or used by an app, while also supporting a wide range of apps with varying permission levels. Mozilla has implemented tight control over what type of applications can access which APIs. For example, only certified apps (shipped with the phone) can have access to the Telephony API. The Dialer app has privileges to access the Telephony API in order to make phone calls, but not all certified apps can access this API.</p> +<p>This prevents a situation, for example, in which an arbitrary third-party app gets installed, dials a pay-per-use phone number (900 and 910), and racks up a large cell phone bill.</p> +<p>Other OEM apps might be selectively given access to the Telephony API, however. For example, an operator might provide a systems management application that allows a customer to manage their account, including the ability to phone the Operator’s billing or support office directly.</p> +<h3 id="受信任（Trusted）和不受信任_（Untrusted）的_App">受信任（Trusted）和不受信任 （Untrusted）的 App</h3> +<p>Firefox OS 根据下面的类型对 app 进行分类</p> +<table> + <thead> + <tr> + <th style="width: 82px;"> + <p>Type</p> + </th> + <th style="width: 102px;"> + <p>Trust Level</p> + </th> + <th style="width: 447px;"> + <p>Description</p> + </th> + </tr> + </thead> + <tbody> + <tr> + <td style="width: 82px;"> + <p>Certified</p> + </td> + <td style="width: 102px;"> + <p>Highly Trusted</p> + </td> + <td style="width: 447px;"> + <p>System apps that have been approved by the Operator or OEM (due to risk of device corruption or risk to critical functionality). System apps and services only; not intended for third-party applications.<br> + This designation is reserved for just a small number of critical applications. Examples: SMS, Bluetooth, camera, system clock, telephony, and the default dialer (to ensure that emergency services are always accessible).</p> + </td> + </tr> + <tr> + <td style="width: 82px;"> + <p>Privileged</p> + </td> + <td style="width: 102px;"> + <p>Trusted</p> + </td> + <td style="width: 447px;"> + <p>Third-party apps that have been reviewed, approved, and digitally signed by an authorized Marketplace.</p> + </td> + </tr> + <tr> + <td style="width: 82px;"> + <p>Web (everything else)</p> + </td> + <td style="width: 102px;"> + <p>Untrusted</p> + </td> + <td style="width: 447px;"> + <p>Regular web content. Includes both installed apps (stored on the mobile phone) and hosted apps (stored remotely, with only an app manifest stored on the mobile phone). The manifest for hosted apps can be obtained through a Marketplace.</p> + </td> + </tr> + </tbody> +</table> +<p>An application’s trust level determines, in part, its ability to access mobile phone functionality.</p> +<ul> + <li>Certified apps have permissions to most Web API operations.</li> + <li>Privileged apps have permissions to a subset of the Web API operations accessible to Certified apps.</li> + <li>Untrusted apps have permissions to a subset of the Web API operations accessible to Privileged apps — only those Web APIs that contain sufficient security mitigations to be exposed to untrusted web content.</li> +</ul> +<p>Some operations, such as network access, are assumed to be an implicit permission for all apps. In general, the more sensitive the operation (for example, dialing a phone number or accessing the Contacts list), the higher the app trust level required to execute it.</p> +<div class="note"> + <p><strong>注意</strong>: for more information on the APIs available and their permission levels, consult <a href="/en-US/Apps/Developing/App_permissions">App permissions</a>.</p> +</div> +<h4 id="Principle_of_Least_Permissions">Principle of Least Permissions</h4> +<p>For web apps, the Firefox OS security framework follows the <em>principle of least permissions</em>: start with the absolute minimum permissions, then selectively grant additional privileges only when required and reasonable. By default, an app starts with very low permissions, which is comparable to untrusted web content. If the app makes Web API calls that require additional permissions, it must enumerate these additional permissions in its <em>manifest</em> (described later in this document). Gecko will consider granting Web API access to an application only if the applicable privileges are explicitly requested in its manifest. Gecko will grant the requested permission only if the <em>type </em>of the Web App (certified, trusted, or web) is sufficiently qualified for access.</p> +<h4 id="Review_Process_for_Privileged_Apps_in_the_Marketplace">Review Process for Privileged Apps in the Marketplace</h4> +<p>In order for an app to become privileged, the app provider must submit it for consideration to an authorized Marketplace. The Marketplace subjects the app to a rigorous code review process: verifying its authenticity and integrity, ensuring that requested permissions are used for the purposes stated (in the permission rationale), verifying that the use of implicit permissions is appropriate, and validating that any interfaces between privileged app content and unprivileged external content have the appropriate mitigations to prevent elevation of privilege attacks. The Marketplace has the responsibility to ensure that the web app will not behave maliciously with the permissions that it is granted.</p> +<p>After an app passes this review, it is approved for use, its app manifest is digitally signed by the Marketplace, and it is made available for mobile users to download. The signature ensures that, if the web store were somehow hacked, the hacker could not get away with installing arbitrary content or malicious code on users’ phones. Due to this vetting process, Firefox OS gives privileged apps obtained from a Marketplace a higher degree of trust than everyday (untrusted) web content.</p> +<div class="note"> + <p><strong>Note</strong>: to find out more about Marketplaces including the <a href="https://marketplace.firefox.com/">Firefox Marketplace</a>, go to the <a href="/en-US/Marketplace">Marketplace zone</a>.</p> +</div> +<h3 id="封装式（Packaged）和托管式（Hosted）_Apps">封装式（Packaged）和托管式（Hosted） Apps</h3> +<p>Apps for Firefox OS can be either <em>packaged</em> (stored on the mobile phone) or <em>hosted</em> (stored on a remote web server, with just a manifest stored on the mobile phone). There are some differences in the way in which security is managed for each. Nonetheless, packaged and hosted apps are both subject to application sandboxing, which is described later in this document.</p> +<div class="note"> + <p><strong>Note</strong>: You can find out more about hosted and packaged apps at <a href="/en-US/docs/Mozilla/Marketplace/Publish_options">App publishing options</a>.</p> +</div> +<h4 id="封装式（Packaged）_Apps">封装式（Packaged） Apps</h4> +<p>A packaged app consists of a ZIP file containing application resources (HTML5, CSS, JavaScript, images, media), as well as a manifest that provides an explicit list of assets and their corresponding hashes. Certified and privileged apps must be packaged apps because the app manifest needs to be digitally signed. When a user obtains a packaged app, the ZIP file is downloaded onto the mobile phone, and the manifest is read from a known location inside the ZIP file. During the install process, app assets are verified and remain stored locally in the package. All explicit permissions are requested at runtime, showing the user the app's data usage intentions, and persisted by default.</p> +<p>To refer to app resources in a packaged app, the URL begins with app: using the following format:</p> +<p><code>app://<em>identifier</em>/<em>path_within_zipfile</em>/file.html</code></p> +<p>where app:// represents the mount point for the ZIP file, and <em>identifier</em> is a UUID that is generated when the app is installed on the mobile phone. This mechanism ensures that resources referred to with an app: URL are contained in the ZIP file. The path within an app: is relative, so relative links to resources in the ZIP file are allowed.</p> +<p>While packaged apps are primarily intended to be used for Certified or Privileged apps, regular web apps can also be packaged. However, they do not gain any increase in trust or permissions access simply because they are packaged.</p> +<h4 id="托管式（Hosted）_Apps">托管式（Hosted） Apps</h4> +<p>Hosted apps are located on a web server and loaded via HTTP. Only the app manifest is stored on the mobile phone. Everything else is stored remotely. Certain APIs are available only to privileged and certified apps, which requires the app to be packaged due to signing requirements. Therefore, a hosted app will not have access to any of the Web API operations that require privileged or certified app status.</p> +<p>From a security point of view, hosted apps work very much like normal websites. A hosted app is loaded by invoking a hard-coded, fully-qualified URL that points to the startup page in the root directory of the app on that web server. Once a hosted app is loaded, the mobile phone links to pages using the same URLs that are used when browsing the web site.</p> +<h3 id="App_Manifest">App Manifest</h3> +<p>An Open Web App manifest contains information that a Web browser needs in order to interact with an app. A manifest is a JSON file with (at a minimum) a name and description for the app. For further details, refer to <a href="/en-US/docs/Apps/FAQs/About_app_manifests" title="/en-US/docs/Apps/FAQs/About_app_manifests">FAQs about app manifests</a>.</p> +<h4 id="Manifest_示例">Manifest 示例</h4> +<p>The following code listing shows an example manifest with just basic settings:</p> +<pre class="brush:text">{ + "name": "My App", + "description": "My elevator pitch goes here", + "launch_path": "/", + "icons": { + "128": "/img/icon-128.png" + }, + "developer": { + "name": "Your name or organization", + "url": "http://your-homepage-here.org" + }, + "default_locale": "en" +}</pre> +<h3 id="App_Manifest_的安全设置">App Manifest 的安全设置</h3> +<p>The manifest can also contain other settings, including the following security settings:</p> +<table> + <thead> + <tr> + <th style="width: 152px;"> + <p>Field</p> + </th> + <th style="width: 479px;"> + <p>Description</p> + </th> + </tr> + </thead> + <tbody> + <tr> + <td style="width: 152px;"> + <p>permissions</p> + </td> + <td style="width: 479px;"> + <p>Permissions required by the app. An app must list every Web API it intends to use that requires user permission. Most permissions make sense for privileged apps or certified apps, but not for hosted apps. Properties per API:</p> + <ul> + <li><strong>description</strong>: A string specifying the intent behind requesting use of this API. Required.</li> + <li><strong>access</strong>: A string specifying the type of access required for the permission. Implicit permissions are granted at install time. Required for only a few APIs. Accepted values: <strong>read</strong>, <strong>readwrite</strong>, <strong>readcreate</strong>, and <strong>createonly</strong>.</li> + </ul> + </td> + </tr> + <tr> + <td style="width: 152px;"> + <p>installs_allowed_from</p> + </td> + <td style="width: 479px;"> + <p>The Origin of the app; can be singular or an array of origins (scheme+unique hostname) that are allowed to trigger installation of this app. Allows app providers to restrict installs from only an authorized Marketplace (such as <a href="https://marketplace.firefox.com/">https://marketplace.firefox.com/</a>).</p> + </td> + </tr> + <tr> + <td style="width: 152px;"> + <p>csp</p> + </td> + <td style="width: 479px;"> + <p>Content Security Policy (CSP). Applied to all pages loaded in the app. Used to harden the app against bugs that would allow an attacker to inject code into the app. If unspecified, privileged and certified apps have system-defined defaults. Syntax:<br> + <a href="https://developer.mozilla.org/en-US/docs/Apps/Manifest#csp">https://developer.mozilla.org/en-US/docs/Apps/Manifest#csp</a></p> + <p><em>Note that this directive can only increase the CSP applied. You cannot use it, for example, to reduce the CSP applied to a privileged App.</em></p> + </td> + </tr> + <tr> + <td style="width: 152px;"> + <p>type</p> + </td> + <td style="width: 479px;"> + <p>Type of application (web, privileged, or certified).</p> + </td> + </tr> + </tbody> +</table> +<p>Firefox OS requires that the manifest be served with a specific mime-type (<code>application/x-web-app-manifest+json</code>) and from the same fully-qualified host name (origin) from which the app is served. This restriction is relaxed when the manifest app (and thus the app manifest) is same-origin with the page that requested the app to be installed. This mechanism is used to ensure that it's not possible to trick a website into hosting an application manifest.</p> +<h3 id="沙盒技术_Sandboxed_Execution">沙盒技术 Sandboxed Execution</h3> +<p>This section describes application and execution sandboxes.</p> +<h4 id="Application_Sandbox">Application Sandbox</h4> +<p>The Firefox OS security framework uses sandboxing as a defense-in-depth strategy to mitigate risks and protect the mobile phone, platform, and data. Sandboxing is a way of putting boundaries and restrictions around an app during run-time execution. Each app runs in its own worker space and it has access only to the Web APIs and the data it is permitted to access, as well as the resources associated with that worker space (IndexedDB databases, cookies, offline storage, and so on).</p> +<p>The following figure provides an overview of this security model.</p> +<p><img alt="" src="https://mdn.mozillademos.org/files/5025/sandbox.png"></p> +<p>By isolating each app, its impact is contained within its own worker space and it cannot interfere with anything (such as other apps or their data) outside of that worker space.</p> +<h4 id="Execution_Sandbox">Execution Sandbox</h4> +<p>B2G (Gecko) runs in a highly-privileged system process that has access to hardware features in the mobile phone. At runtime, each app runs inside an execution environment that is a child process of the B2G system process. Each child process has a restricted set of OS privileges — for example, a child process cannot directly read or write arbitrary files on the file system. Privileged access is provided through Web APIs, which are mediated by the parent B2G process. The parent ensures that, when a child process requests a privileged API, it has the necessary permission to perform this action.</p> +<p>Apps communicate only with the B2G core process, not with other processes or apps. Apps do not run independently of B2G, nor can apps open each other. The only “communication” between apps is indirect (for example, when one app sets a system alarm and another app triggers a system notification as a result of it), and is mediated through the B2G process.</p> +<h4 id="仅通过_Web_API_才能硬件访问">仅通过 Web API 才能硬件访问</h4> +<p>Web apps have only one entry point to access mobile phone functionality: the Firefox OS Web APIs, which are implemented in Gecko. Gecko provides the sole gateway to the mobile device and underlying services. The only way to access device hardware functionality is to make a Web API call. There is no “native” API and there are no other routes (no “back doors”) to bypass this mechanism and interact directly with the hardware or penetrate into low-level software layer.</p> +<h2 id="安全基础架构">安全基础架构</h2> +<p>The following figure shows the components of the Firefox OS security framework:</p> +<p><img alt="" src="https://mdn.mozillademos.org/files/5027/securityframework.png" style="width: 979px; height: 591px;"></p> +<ul> + <li><strong>Permission Manager</strong>: Gateway to accessing functionality in the Web API, which is the only access to the underlying hardware.</li> + <li><strong>Access Control List</strong>: Matrix of roles and permissions required to access Web API functionality.</li> + <li><strong>Credential Validation</strong>: Authentication of apps/users.</li> + <li><strong>Permissions Store</strong>: Set of privileges required to access Web API functionality.</li> +</ul> +<h3 id="权限管理与执行">权限管理与执行</h3> +<p>Firefox OS security is designed to verify and enforce the permissions granted to web apps.</p> +<p>The system grants a particular permission to an app only if the content requests it, and only if it has the appropriate permissions requested in the app’s manifest. Some permissions require further authorization from the user, who is prompted to grant permission (as in the case of an app requesting access to the user’s current location). This app-centric framework provides more granular control over permissions than traditional role-centric approaches (in which individual roles are each assigned a set of permissions).</p> +<p>A given Web API has a set of actions and listeners. Each Web API has a required level of permission. Every time a Web API is called, Gecko checks permission requirements (role lookup) based on:</p> +<ul> + <li>Permissions associated with calling app (as specified in the manifest and based on the app type.)</li> + <li>Permissions required to execute the requested operation (Web API call.)</li> +</ul> +<p>If the request does not meet the permission criteria, then Gecko rejects the request. For example, untrusted apps cannot execute any Web APIs that are reserved for trusted apps.</p> +<h3 id="要求用户权限许可">要求用户权限许可</h3> +<p>In addition to permissions that are implicitly associated with the web apps, certain operations require explicit permission from the user before they can be executed (for example, "can the web app access your camera?"). For these operations, web apps are required to specify, in their manifest, their justification for requiring this permission. This <em>data usage intention</em> informs users about what the web app intends to do with this data if permission is granted, as well as any risk involved. This allows users to make informed decisions and maintain control over their data.</p> +<h3 id="安全_App_更新过程">安全 App 更新过程</h3> +<p><img alt="" src="https://mdn.mozillademos.org/files/5029/updateprocess.png" style="width: 979px; height: 102px;"></p> +<p>For app upgrades and patches to a <em>privileged</em> app, app providers submit the updated package to an authorized Marketplace, where it is reviewed and, if approved, signed and made available to users. On Firefox OS devices, an App Update Utility periodically checks for app updates. If an update is available, then the user is asked whether they want to install it. Before a update is installed on the mobile device, the package is verified for:</p> +<ul> + <li>Update origin (verify the source location protocol:domain:port of the update and manifest)</li> + <li>File integrity (SHA-256 hash check)</li> + <li>Code signature (certificate check against a trusted root)</li> +</ul> +<p>Rigorous checks are in place to ensure that the update is applied properly to the mobile phone. The complete update package must be downloaded in a specific and secure location before the update process begins. Installation does not overwrite any user data.</p> +<div class="note"> + <p><strong>Note</strong>: For more information on app updates, read <a href="/en-US/Apps/Developing/Updating_apps">Updating apps</a>.</p> +</div> +<h2 id="设备安全_(硬件)">设备安全 (硬件)</h2> +<p>Security mechanisms for the mobile device hardware are typically handled by the OEM. For example, an OEM might offer SIM (Subscriber Identity Module) card locks, along with PUK (PIN Unlock Key) codes to unlock SIM cards that have become locked following incorrect PIN entries. Contact your OEM for details. Firefox OS does allow users to configure passcodes and timeout screens, which are described in the next section.</p> +<h2 id="数据安全">数据安全</h2> +<p>Users can store personal data on their phone that they want to keep private, including contacts, financial information (bank & credit card details), passwords, calendars, and so on. Firefox OS is designed to protect against malicious apps that could steal, exploit, or destroy sensitive data.</p> +<h3 id="密码和超时锁屏">密码和超时锁屏</h3> +<p>Firefox OS allows users to set a passcode to their mobile phone so only those who supply the passcode can use the phone. Firefox OS also provides a timeout screen that is displayed after a configurable period of phone inactivity, requiring passcode authentication before resuming use of the phone.</p> +<h3 id="沙盒数据_Sandboxed_Data">沙盒数据 Sandboxed Data</h3> +<p>As described earlier, apps are sandboxed at runtime. This prevents apps from accessing data that belongs to other apps <em>unless</em> that data is explicitly shared, and the app has sufficient permissions to access it.</p> +<h3 id="串行数据_Serialized_Data">串行数据 Serialized Data</h3> +<p>Web apps do not have direct read and write access to the file system. Instead, all access to storage occurs only through Web APIs. Web APIs read from, and write to, storage via an intermediary SQLite database. There is no direct I/O access. Each app has its own data store, which is serialized to disk by the database.</p> +<h3 id="数据破坏">数据破坏</h3> +<p>When a user uninstalls an app, all of the data (cookies, localStorage, IndexedDB, and so on) associated with that application is deleted.</p> +<h3 id="隐私">隐私</h3> +<p>Mozilla is committed to protecting user privacy and user data according to its privacy principles (<a href="https://www.mozilla.org/privacy/">https://www.mozilla.org/privacy/</a>), which stem from the Mozilla Manifesto (<a href="https://www.mozilla.org/about/manifesto.html">https://www.mozilla.org/about/manifesto.html</a>). The Mozilla Firefox Privacy Policy describes how Mozilla collects and uses information about users of the Mozilla Firefox web browser, including what Firefox sends to websites, what Mozilla does to secure data, Mozilla data practices, and so on. For more information, see:</p> +<ul> + <li><a href="http://www.mozilla.org/en-US/legal/privacy/firefox.html">http://www.mozilla.org/en-US/legal/privacy/firefox.html</a></li> + <li><a href="https://blog.mozilla.org/privacy/">https://blog.mozilla.org/privacy/</a></li> + <li><a href="http://support.mozilla.org/en-US/kb/privacy-and-security-settings-firefox-os-phones">http://support.mozilla.org/en-US/kb/privacy-and-security-settings-firefox-os-phones</a></li> +</ul> +<p>Firefox OS implements these principles by putting the control of the user data in the hands of the user, who gets to decide where this personal information goes. Firefox OS provides the following features:</p> +<ul> + <li>Do Not Track option</li> + <li>ability to disable Firefox browser cookies</li> + <li>ability to delete the Firefox OS browsing history</li> +</ul> |