Please note, this is a STATIC archive of website developer.mozilla.org from 03 Nov 2016, cach3.com does not collect or store any user information, there is no "phishing" involved.
B2G OS
您的搜尋結果

    Firefox OS 安全性概述

    此篇文章將概述 Firefox OS 的安全架構，可阻絕 App、平台、資料所挾帶的惡意威脅，進而保護行動裝置。Mozilla 建構了完整且多層次的安全模式，為行動電話提供絕佳的防護效果。

     

    平台安全性

    Firefox OS 平台具備多層次安全模式，可將各層次的開發風險降至最低。第一線的保護機制更整合了深度防禦 (Defense-in-depth) 策略，進而達到完整的防護機制。

     

    安全架構

    Firefox OS 將銜接網路架構的應用與其底層硬體，而其整合式技術囊括了下列層級：

    行動裝置 (Mobile device) 即是執行 Firefox OS 的智慧型手機。Gonk 則包含 Linux kernel、韌體、系統函式庫、裝置驅動程式。Gecko 屬於應用程式的執行時間層，為 App提供執行框架，另建構 Web API 以存取行動裝置的功能。Gaia 則是網頁 App (包含 HTML5、CSS、JavaScript、圖片、媒體等) 套件，可隨時改善使用者經驗。

    Gecko 扮演守門人的角色，可強制執行安全策略，避免行動裝置遭到誤用；並可作為網頁 App (位於 Gaia) 之間的中介層 (Intermediary)。Gonk 則可將行動電話底層的硬體功能，直接提供予 Gecko 使用。只有在 Gecko 放行存取請求時，網頁 App 才能透過 Web API 而存取行動電話的功能；而不會有直接存取或「走後門」的情況發生。Gecko 將強制執行許可，並阻擋未經授權的請求。

     

    佈署安全系統

    手機上的 Firefox OS 系統映像檔 (System image) 是由受信任的來源 (一般為該裝置的 OEM 廠商) 所提供，這些受信任的系統映像檔提供者負責發布檔案的組建、建置、測試以及數位簽章作業。

    整個技術層均需經過安全驗證。由Linux 的存取控制清單 (ACL) 執行檔案系統的權限控制。系統 App 則安裝於唯讀 (僅於更新期間才暫時轉為可讀寫) 媒體之中；若是使用者相關內容的區域，則可能為讀寫性質。裝置硬體中的不同元件，均已內建了業界標準的防護機制。舉例來說，晶片製造商會加入安全防護技巧來提高安全性，我們同樣強化了核心平台 (Gecko 與 Gonk)，以阻絕潛在的可能威脅，亦提升了相關編譯器的功能。可參閱執行期間的安全性進一步了解細節。

     

    更新安全系統

    Firefox OS 平台的後續升級與修正，將透過安全的 Mozilla 程序完成佈署，並確保行動電話上的系統映像保有其完整性。同樣由已知且受信任的來源 (一般為該裝置的 OEM 廠商) 提供更新作業，並負責更新封裝的組裝、建構、測試、數位簽章等作業。

    系統更新可能牽涉 Firefox OS 部分或所有的層級。若更新作業必須變更 Gonk，則安裝作業將使用 FOTA (Firmware Over the Air)。FOTA 更新作業亦可能包含 Firefox OS 的其他層級，如 Gaia、Gecko、安全更新、裝置管理 (FOTA/韌體/驅動程式)、設定管理 (Firefox OS 的設定)，還有更多修正檔。

    若更新作業並未牽涉 Gonk，則僅需 Mozilla 系統更新公用程式 (System Update Utility) 即可完成。Firefox OS 所使用之更新架構、程序、Mozilla ARchive (MAR) 格式 (用於更新封裝)，與 Firefox 桌面版產品完全相同。可參閱 https://wiki.mozilla.org/Software_Update 以進一步了解。

    而行動電話所內建的更新服務 (亦可能由 OEM 廠商提供)，將定期檢查是否有系統更新。一旦發佈系統封裝，更新服務隨即將偵測到該封裝，並提醒使用者完成安裝作業。在行動裝置安裝更新檔案之前，另將檢查裝置的儲存容量是否足夠，且將驗證下列分配空間：

    • 更新檔案來源 (驗證系統更新與 manifest 檔案的來源位置 protocol:domain:port)
    • 檔案完整性 (SHA-256 雜湊檢查)
    • 程式碼簽章 ─ 針對憑證簽發源頭 (Trusted Root) 進行憑證檢查

    更新期間應注意下列要點：

    • Mozilla 建議透過 SSL 連線進行更新。
    • 安裝韌體封裝之前，需要高強度的加密驗證作業。
    • 開始更新程序之前，必須將完整更新檔案下載至特定且安全位置。
    • 開始更新程序時，系統必須處於安全狀態且不執行任何 Web App。
    • 必須將金鑰儲存於裝置中的安全位置。

    請確實完成相關檢查，讓行動電話確實完成更新作業。

     

    App 的安全性

    Firefox OS 使用深度防禦 (Defense-in-depth) 策略，可保護行動電話免受惡意應用程式的攻擊。此策略必須佈署多種機制，如根據 App 信任模式 (Trust model) 所建構的隱式許可 (Implicit permission) 層級；執行期間的沙箱執行作業 (Sandboxed execution)；僅限 API 存取行動電話的底層硬體；健全的許可模型 (Permission model)；安全的安裝與更新程序。若要進一步了解相關技術，可參閱應用程式安全性。

    在 Firefox OS 中的所有應用程式，均為 Web App ─ 即以 HTML5、JavaScript、CSS、媒體、其他開放式 Web 技術 (可於瀏覽器中執行的網頁，並不屬於本文所提的 Web App) 所撰寫的程式。由於這些 Web App 並非二進制 ─ 即所謂的「原生 (Native)」─ 應用，因此將由 Web API居中嚴格協調所有的系統存取作業。甚至檔案系統存取都只能透過 Web API 與後端的 SQLite 資料庫， App 不能直接存取 SD 記憶卡上的檔案。

    Firefox OS 可限制 App 所能存取/使用的資源規模，同時又可針對多樣的 App 而支援不同的許可層級。Mozilla 嚴格控制各類 App 所能存取的 API。舉例來說，僅有 Certified App (隨手機出貨) 可存取 Telephony API。另外，Dialer App 必須存取 Telephony API 才能撥打電話，而非所有 Certified App 均可存取此 API。如此可避免安裝了任何第三方 App 之後，撥打出國際/長途電話而讓帳單金額暴增。但針對其他 OEM App，仍可選擇是否給予 Telephony API 存取權。舉例來說，電信服務商可提供系統管理應用程式，讓客戶能管理自己的帳戶，甚至能直接以電話送出電信服務帳單或支援辦公室作業。

     

    受信任 (Trusted) 與未信任 (Untrusted) 的 App

    Firefox OS 將 App 分為下列類型：

    類型

    受信任層級

    說明

    Certified

    受高度信任

    這類系統 App 經過電信服務商或 OEM (起因於裝置毀損或重要功能所產生的風險) 所核可。但僅限系統 App 與相關服務，並無第三方 App。
    此信任層級僅用於極少部分的重要 App，例如 SMS、藍牙、相機、電話、系統時鐘、預設的電話播號鍵盤 (為了可確實用於緊急電話)。

    Privileged

    受信任

    由授權的商城審視、核可、數位簽章過的第三方 App。

    Web (與其他 App)

    未受信任

    屬於一般網頁內容。包含安裝式 App (儲存於行動電話中) 與托管式 (Hosted，儲存於遠端，僅有 manifest 檔案儲存於行動裝置中) App。另外也可以從 Marketplace 取得托管式 App 的  manifest 檔案。

    App 的受信任層級，某種程度上將決定其所能取用的行動電話功能。

    • Certified App 可使用大多數的 Web API 作業。
    • 針對 Certified App 所能存取的 Web API 作業，Privileged App 可使用這些 Web API 作業的子集。
    • 針對 Privileged App 所能存取的 Web API 作業，未受信任的 App 則能使用這些 Web API 作業的子集。而相關 Web API 則具備必要的安全機制，以隨時因應未受信任的網頁內容。

    某些作業 (如網路存取) 均先假設為所有 App 的隱式許可。一般來說，越是高敏感性的作業 (如撥打電話號碼或取得通訊錄內容)，就僅有更高信任度的 App 才能執行。

    最小權限原則 (Principle of Least Permissions)

    針對 Web App，Firefox OS 安全架構則以《最小權限原則 (principle of least permissions)》為架構：先給予最低權限，僅在必要或合理的情況下，才選擇性的提高權限。依預設值，任一 App 均具備最低權限，以因應未受信任的網頁內容。如果 App 所呼叫的 Web API 需要額外權限，則其 manifest 檔案 (本文稍後將敘述) 必須先列舉這些額外權限。而僅在 App 的 manifest 檔案明確要求 App 授權時，Gecko 才會給予 Web API 的存取權。此外，只有在 Web App 的類型 (即上述的 Certified 或 Trusted 或 Web 分類) 符合其存取層級，Gecko 才會給予必要的授權。

    Marketplace 對 Privileged App 的審核程序

    若要達到 Privileged App，則 App 開發/供應商必須將之提交予經過授權的 Marketplace。而 Marketplace 隨即開始嚴格的程式碼審核程序：檢視其完整性與穩定性、審查其索取的授權是否符合其載明的用途、確認其隱式許可是否使用合宜、審核「Privileged App 的內容」與「未授權的外部內容」之間的介面，是否具備合適的緩衝，以避免權限提升 (Elevation of privilege) 的影響。Marketplace 另需負責確保 Web App 不會對其給予的權限進行惡意動作。

    在 App 通過審核之後即許可使用，且 Marketplace 亦將以數位方式簽署其 manifest 檔案，以供行動裝置的使用者下載之。一旦 Marketplace 遭駭，數位簽章可確保駭客無法將任意內容或惡意程式碼，安裝於使用者的行動電話上。也基於此審查程序，Firefox OS 從 Marketplace 取得的 Privileged App，其可信任度亦高於一般的 (未受信任的) 網頁內容。

     

    封裝式 (Packaged) 與托管式 (Hosted) App

    Firefox OS 可用封裝式 (儲存於行動電話中) 或托管式 (儲存於遠端伺服器中，僅有 manifest 檔案儲存於行動電話中) App。而此 2 種 App 的安全管理方式亦有所不同。封裝式與托管式 App 同可作為應用程式的封閉沙箱，本文稍後將說明。

    封裝式 (Packaged) App

    封裝式 App 是以 ZIP 壓縮檔所構成，內含應用程式的相關資源 (HTML5、CSS、JavaScript、影像、媒體)，另以 manifest 檔案提供上述資源的清單，與其對應的 雜湊值 (Hash)。由於 Certified 與 Privileged App 的 manifest 檔案均需完成數位簽章，因此Certified/Privileged App 必為封裝式 App。只要使用者取得封裝式 App，就會將 ZIP 檔案下載至行動電話中，另從 ZIP 檔案內的已知位置讀取 manifest 檔案。系統將在安裝過程中驗證 App 的資源，其他則儲存於本端的封裝內。執行期間將請求所有的顯式許可 (Explicit permission)、顯示使用者 App 的資料儲存目標，最後依預設值完成保存。

    若要清楚指明封裝式 App 中的資源，則 URL 應以 App 開頭並使用下列格式：

    app://identifier/path_within_zipfile/file.html

    這裡的「app://」代表 ZIP 檔案的掛載點 (Mount point)。於行動電話上安裝 App 時，隨即產生「identifier」作為 UUID。如此可確保以 :app 的 URL 指向了特定資源，且已納入於 ZIP 檔案中。而 app: 中的路徑為相對路徑，因此可於 ZIP 檔案中允許資源的相對鏈結。

    封裝式 App 主要用於 Certified 與 Privileged App，不過一般的 Web App 亦可作為封裝式。但這些 Web App 不會因為封裝格式，就自動提高其信任度或存取權限。

    托管式 (Hosted) App

    托管式 App 均儲存於網頁伺服器上，或需透過 HTTP 載入。僅有其 manifest 檔案儲存於行動電話中；其他所有檔案均儲存於遠端。僅 Privileged 與 Certified App 才能使用特定 API，以因應數位簽章作業而必須將 App 封裝。因此，即使 Web API 作業需要 Privileged/Certified App 的狀態，托管式 App 亦不需存取任何 Web API 作業。

    從安全性的觀點來說，托管式 App 的作業方式比較像一般網頁。在該網頁伺服器上，必須以寫死 (Hard-coded) 的完整 URL 指向 App 根目錄中的起始頁面，才能載入托管式 App。一旦載入托管式 App 之後，行動電話將根據網頁瀏覽時的 URL，跟著連至相同頁面。

     

    App 的 Manifest 檔案

    Open Web App 的 manifest 檔案，將提供瀏覽器與 App 互動時的必要資訊。而 manifest 即為 JSON 檔案，至少均具備 App 的名稱與描述。可參閱 App 的 manifest 檔案常見問題以進一步了解。

    Manifest 範例

    下列程式碼則具備基礎設定的 manifest 範例：

    1

    2

    3

    4

    5

    6

    7

    8

    9

    10

    11

    12

    13

    {

      "name": "My App",

      "description": "My elevator pitch goes here",

      "launch_path": "/",

      "icons": {

        "128": "/img/icon-128.png"

      },

      "developer": {

        "name": "Your name or organization",

        "url": "https://your-homepage-here.org"

      },

      "default_locale": "en"

    }

    Manifest 檔案的安全性設定

    manifest 檔案亦可具備其他設定，如下列的安全性設定：

    欄位

    說明

    permissions

    App 的必要許可。任何 App 需列出所要使用的 Web API，以取得使用者的許可。Privileged/Certified App 可識別大多數的許可，但托管式 App 不適用。API 必具備的屬性：

    • description ─ 在請求使用此 API 時，此字串將指定其背後的目的地。必填。
    • access ─ 此字串將指定許可所需的存取類型。安裝時即給予隱式許可 (Implicit permission)。僅數種 API  為必填欄位。僅接受：read、readwrite、readcreate、createonly 等數值。

    installs_allowed_from

    App 的來源。而構成來源的陣列 (scheme+unique hostname) 則可觸發此 App 的安裝作業。另可讓 App 廠商限制僅授權過的 Marketplace (如 https://marketplace.firefox.com/) 才可安裝 App。

    csp

    內容安全政策 (Content Security Policy)，將套用至 App 所載入的所有頁面。可強化 App 而避免遭惡意插入任何程式碼。若未指定 CSP，則 Privileged 與 Certified App 均已預設了系統定義值，其語法為：
    https://developer.mozilla.org/en-US/docs/Apps/Manifest#csp

    另請注意，此指令僅能增加所套用的 CSP。舉例來說，此指令並無法減少 Privileged App 所套用的 CSP。

    type

    App 的類型，即 Web、Privileged、Certified 等類型。

    Firefox OS 要求 manifest 檔案必須為特定的 mime-type 格式 ("application/x-web-app-manifest+json")，而且必須與該 App 為相同來源的完整主機名稱 (即來源)。若「App 的 manifest 檔案」與「要求安裝 App 的頁面」兩者的來源相同，則將放寬此限制。此機制可確保不能偽裝網站並托管 App 的 manifest 檔案。

     

    隔離式 (Sandboxed) 執行作業

    本章節將說明 App 與執行作業的沙箱隔離區 (Sandbox)。

    App 隔離區

    Firefox OS 的安全架構，即是將隔離區作為深度防禦 (Defense-in-depth，DID) 策略，以減少風險並保護資料、平台、行動電話。在執行期間，隔離區可為 App 產生邊界與限制。各個 App 僅於自己的工作空間 (Working space) 內執行，另僅經過授權可存取的 Web API 與資料，才能存取；工作空間相關的資訊 (IndexedDB 資料庫、Cookies、離線儲存等) 亦然。請參閱 https://developer.mozilla.org/en-US/docs/Mozilla/Firefox_OS/Security/Security_model 以進一步了解。

    下圖則簡略說明了安全模型：

    在隔離各個 App 之後，所產生的影響亦僅限於其工作空間之內，而不會受到工作空間之外的干擾 (如其他 App 或資料)。

    執行作業隔離區

    B2G (Gecko) 在一個高授權度的系統程序 (可存取行動電話中的硬體功能) 中執行。在執行期間，各個執行環境裡的 App 皆是 B2G 系統程序的子程序。而各個子程序又具備嚴格的 OS 授權。舉例來說，子程序並無法直接讀寫檔案系統中的任意檔案。必須由 Web API 提供相關存取權限；且該權限又由 B2G 母程序所居中協調。在子程序要求授權過的 API 時，母程序將確認子程序具備必要的許可，以執行相關動作。

    App 僅能透過 B2G 核心程序 (非其他程序或 App) 而相互溝通。App 無法於 B2G 之外獨立執行；各 App 亦無法互相開放。App 之間僅能間接「溝通」─ 例如接收器 (Listener) 程序偵測到其他程序所產生的事件，且必須由 B2G 程序居中協調。

    僅透過 Web API 才能存取硬體

    Web App 若要存取行動電話的功能，唯一管道只有以 Gecko 所建構的 Firefox OS Web API 。Gecko 是行動裝置與底層服務的單一出口，因此必須讓 Web API 進行呼叫作業，才能存取裝置的硬體功能。絕對沒有「原生 (Native)」的 API 或其他途徑可繞過此機制，而直接存取硬體或滲透至初階的軟體層。

     

    安全架構

    下圖則為安全架構的元件：

    • Permission Manager：可於 Web API 中存取功能的管道，是底層硬體唯一存取路徑。
    • Access Control List：由角色 (Role) 與許可 (Permission) 所構成，存取 Web API 功能所必備。
    • Credential Validation：App 與使用者的授權。
    • Permissions Store：存取 Web API 功能所需的授權集合。

     

    許可的管理與強化

    針對 Web App 所需的許可 (Permission)，Firefox OS 安全機制將進一步驗證並強化。
    僅當內容 (Content) 請求特殊許可，或當內容具備 manifest 所要求的適當許可時，系統才會發出特定許可至 App。若需要使用者進一步的授權，則某些許可亦將提出請求 (例如 App 要存取使用者目前的位置)。與傳統「角色為中心 (Role-centric)」的方式 (各個獨立角色將獲得一系列的許可)相較，這種「應用為中心 (app-centric)」的架構更能嚴密控管許可。

    現有的 Web API 集合了一系列動作 (Action) 與接收器 (Listener)。各個 Web API 則具備必須的許可層級。每次只要呼叫 Web API，則 Gecko 檢查許可 (角色查找) 的基準為：

    • 呼叫中 App 的相關許可 (已於 manifest 檔案中指定，並以 App 類型為準)
    • 執行必要作業 (Web API 呼叫) 所需的許可

    若該請求並不符合許可的準則，則 Gecko 隨即拒絕該請求。舉例來說，只要是受信任 App 所保留的 Web API，未受信任的 App 均無法執行。

     

    要求使用者給予許可

    除了與 Web App 隱性關連 (Implicitly associated) 的許可之外，在執行特定作業之前需要使用者給予顯式許可。針對這些作業，Web App 必須在 manifest 檔案中表示索取許可的理由 (Justification)。這種「資料使用意圖 (Data usage intention)」，可讓使用者在給予許可之後，知道 Web App 處理資料的方式，亦將了解可能的風險，進而能做出決定並控管自己的資料。

     

    安全的 App 更新程序

    針對 Privileged app 的升級與修正，開發/供應商必須將更新封裝提交至授權過的 Marketplace，以供 Marketplace 進一步審查。而在核准之後，隨即完成數位簽章並提供予使用者。在搭載 Firefox OS 的裝置上，亦可透過 App 更新公用程式 (暫譯 App Update Utility) 定期檢查 App 是否有可用的更新。若發現可用的更新，系統隨即會詢問使用者是否安裝。在行動裝置安裝更新檔案之前，必將驗證封裝的：

    • 更新檔來源 (驗證更新與 manifest 檔案的來源位置 protocol:domain:port)
    • 檔案完整性 (SHA-256 雜湊檢查)
    • 程式碼簽章 ─ 針對憑證簽發源頭 (Trusted root) 而檢查認證

    透過適當且嚴格的檢查，可確保行動電話已正確套用了更新。
    在開始更新程序之前，必須先下載完整的更新封裝至特定且安全的位置。安裝作業並不會覆寫任何使用者資料。

     

    裝置安全性 (硬體)

    行動裝置硬體的安全機制，一般均由 OEM 廠商所決定。舉例來說，OEM 廠商可能提供 SIM (Subscriber Identity Module) 卡的鎖定機制，另搭配 PUK (PIN Unlock Key) 密碼，以用於輸入錯誤 PIN 而遭鎖定的 SIM 卡。這部份需聯絡 OEM 廠商以了解細節。Firefox OS 則可讓使用者設定密碼與待機畫面，將於稍後說明。

     

    資料安全性

    使用者可將個人資料儲存於手機中，並可設定其隱私性，包含聯絡資訊、金融資訊 (銀行與信用卡細節)、密碼、行事曆等。Firefox OS 則針對惡意 App (竊取、挖掘、破壞私密資料) 而設計了防護機制。

     

    密碼與待機畫面

    Firefox OS 可供使用者設定行動電話的密碼，往後必須輸入正確密碼才能使用該行動電話。Firefox OS 另提供待機畫面的功能。只要設定特定時間內未使用行動電話，隨即顯示待機畫面。此時必須輸入密碼授權才能繼續使用手機。

     

    隔離式 (Sandboxed) 資料

    如之前所述，執行期間的 App 均進入隔離狀態。如此可避免 App 相互存取其內的資料；除非該筆資料已設為共享資料，且其他 App 擁有夠高的許可層級可存取之。

     

    序列化 (Serialized) 資料

    Web App 並無法直接讀寫檔案系統。相反的，僅能透過 Web API 而存取儲存媒體。Web API 另將透過 SQLite 資料庫居中協調，才能進一步讀取、寫入儲存媒體。不會直接以 I/O 進行存取作業。各個 App 均擁有自己的資料儲存媒體，將經過資料庫而序列化至磁碟中。

     

    資料銷毀

    一旦使用者取消安裝 App，則將刪除該 App 所有的相關資料，如 cookies、localStorage、Indexeddb 等。

     

    隱私性

    根據隱私權原則 (https://www.mozilla.org/privacy/)，Mozilla 致力保護使用者隱私與資料，同時可參閱 Mozilla Manifesto (https://www.mozilla.org/about/manifesto.html)。而 Mozilla 的 Firefox Privacy Policy 則說明 Mozilla 將如何蒐集、利用 Mozilla Firefox 瀏覽器的使用者資訊，包含 Firefox 所傳送至網頁的資料、Mozilla 的資料保護方式、Mozilla 資料實務情況等。若要進一步了解相關細節，可參閱：

    在擬定 Firefox OS 的原則時，均將使用者資料的控制權交付給使用者本身。而使用者必須自己決定個人資訊的運用方法。Firefox OS 將提供下列功能：

    • 「不要追蹤我 (Do Not Track)」選項
    • 可停用 Firefox 瀏覽器的 Cookies
    • 可刪除 Firefox OS 的瀏覽記錄

    文件標籤與貢獻者

     此頁面的貢獻者: chrisdavidmills, foxbrush, MashKao
     最近更新: chrisdavidmills,