MDN’s new design is in Beta! A sneak peek: https://blog.mozilla.org/opendesign/mdns-new-design-beta/

本文旨在提供 Firefox OS 系統安全模型概觀,說明系統是如何保持安全性與實施權限管理。

名詞解釋

在開始之前,有幾個名詞需要了解一下。

網頁應用程式 (Web application)
網頁應用程式 (web application, web app, open web app, moz app, application) 是運行在 Firefox OS (或其他支援平台)、用 HTML, JavaScript, 以及其他開源網頁技術所寫成的應用程式。所有 B2G 上使用者使用的應用程式都是網頁應用程式,例如撥號程式是一個 web app,但顯示在瀏覽中的網頁並不屬於網頁應用程式的範疇。
b2g 程序 (b2g process)
Firefox OS b2g process 通常會被叫做 "b2g" 或 "Gecko"。b2g 實際上是一個高權限 (root 權限) 應用程式,控制了所有 web app 對資源和硬體的存取。
內容程序 (Content process)
b2g 產生的子程序,會和 b2g 溝通,代表了 web app。它擁有的權限較低 (一般使用者權限;受限的作業系統資源存取),透過 inter-process communication (IPC) 和 OS 核心溝通。
IPDL
Intercommunication Protocol Definition Language, 請參照 IPDL.
AOSP
Android Open Source Project.
System call
一個介於使用者空間 (user space) 和核心 (kernel) 的溝通介面,使用者空間只能透過這個介面和核心溝通。
DAC, MAC
使用者可設定的自主存取控制 (Discretionary Access Control) 和 系統強制的強制存取控制 (Mandatory Access Control)。
FOTA
自動韌體更新機制 (Firmware Over The Air),透過無線網路"空中"更新韌體。
MSU (Mozilla System Updater), MAR (Mozilla ARchive)
和 Firefox 桌面產品一樣的更新機制和檔案格式。

Firefox 作業系統安全模型目標與範疇

Firefox OS 安全模型的設計目標:

  • 限制 web app 所能存取的資源範疇。
  • 確保作業系統各層安全措施正確執行。
  • 從 Gonk 層起,限制與控管安全漏洞所造成之衝擊影響。
  • Web app 權限以及所有應用程式相關安全性特色都在應用程式安全模型詳述。

下面將說明每一個目標以及 Firefox OS 如何達成個目標。

權限強制

應用程式安全模型描述了使用者如何直接或透過受信任第三方來授予應用程式權限,這些強制加諸於內容程序 (content process) 的權限是透過限制資源存取必須經過和核心程序 (core process) 之間的 IPC call。

  • Firefox OS 核心程序, b2g, 的權限極高,同時能夠存取大部分硬體資源。
  • 較低權限的 Web app 的內容程序只能透過 IPC 和 b2g 溝通;IPC 是用 IPDL 實現。
  • 內容程序無法存取系統層級的資源。
  • 每一個 Web API 都有一個以上相關聯的 IPDL 協定宣告檔 (*.ipdl).

內容程序初始化

所有的 web app 都運行在低權限、分開的內容程序。當 web app 載入到一個特別的 <iframe> 型態: <iframe mozapp> 時 b2g 程序會啟動內容程序,這樣會將 web app 和其他內容隔離開來,而且和 web app 的 manifest 高度相關 (請參照 應用程式安全模型),內容程序會在一個稱為 "out of process" (OOP) 的容器裡啟動,這個 OOP 即是 plugin-container 程序,並且和桌面 Firefox 所用的 plugin-container 程序有著相似的原始碼。

風險

  • 當產生 web app 內容程序時的資訊外洩。
  • 提高到和 b2g 一樣權限層級以及存取作業系統資源的意外可能性。
  • 跳過內容程序初始化過程。

實作

在 b2g 程序裡啟動

順序如下:

  1. fork()
  2. setuid(new, different, unused user id|nobody) (無特權的使用者)
  3. chrdir('/')
  4. execve('plugin-container')

這邊的啟動順序確保 OOP 程序運行在隔離的記憶體空間,同時只是低權限使用者,無法提高到 b2g 的高權限。

File descriptor (檔案描述子) 管理

File descriptors 的管理方法是白名單;一份受允許的 file descriptors (FDs) 清單儲存在 mFileMap 物件,在呼叫 fork() 後 (FDs 複製前) 和呼叫 execve()前 (新 web app 開始運行),LaunchApp() 函數會強制關閉不在白名單上的 FD。

不同於傳統的黑名單作法 (close-on-exec flag: CLOEXEC),這種做法確保不會有多餘的開啟 FD,比較可靠。

Content process sandboxing (沙箱,低權限內容程序)

風險

  • 記憶體錯誤或 Gecko 執行時期邏輯錯誤可能導致意外程式碼的執行。
  • 作業系統,特別是核心,類似錯誤可能導致意外程式碼的執行。
  • 資訊洩漏、檔案系統讀寫。

下表為 sandbox 開啟下可能的威脅列表,附帶前述的可能風險。

範疇: 當攻擊者以內容程序執行意外執行碼時,會出現下面的威脅,也就是說,攻擊者發現了 Gecko 的安全漏洞。

威脅 潛在衝擊 可能性因子 建議對應作法

惡意內容程序利用核心安全漏洞

"2 steps attack".

嚴重:整個裝置都將受到控制 : 內容程序只有有限的方法呼叫系統。
  • 減少允許的系統呼叫數量到最低需要量。
  • 用預防性修正檔保護核心,例如 PaX (Protection Against eXecution).

提升到父程序權限

惡意內容程序利用和父程序之間的 IPDL 安全漏洞

"2 steps attack".

: 許多敏感的系統呼叫都可以被執行 (資料損失、相機存取、網路存取等等) : 父程序大量的程式碼代表大範圍的可能攻擊點。少量的 IPDL 資料消毒,例如傳送指標。
  • 以非 root / 非特權使用者執行父程序
  • 盡可能以 sandbox 方法執行父程序

惡意內容程序利用父程序攻擊核心安全漏洞

"3 steps attack".

嚴重:整個裝置都將受到控制

: 需要父程序有可以透過 IPDL 攻擊的 bug。

需要核心和父程序之間的系統呼叫可利用的漏洞 (相較內容程序,父程序有更多可行的系統呼叫)

  • 以非 root / 非特權使用者執行父程序
  • 盡可能以 sandbox 方法執行父程序
  • 用預防性修正檔保護核心,例如 PaX (Protection Against eXecution)

惡意內容程序、父程序、web app 利用硬體裝置的 bug

"1 and 2 steps attack".

: 可以執行特別權限的作業 (如撥號、傳 SMS 簡訊等)

嚴重:整個裝置都將受到控制或執行硬體程式碼。

: 需要硬體 bug 以及 IPDL 或系統呼叫授予的硬體溝通管道
  • 對硬體裝置實施模糊測試 (Fuzz testing)
  • 利用核心或父程序 API 修正檔避開問題 (關閉不安全的硬體功能、消毒資料等等)

Note:

* PaX (Protection Against eXecution) 是一個由 GrSecurity (docs) 所發佈的核心修正檔,實作了 PaX 以及額外的保護措施,如 UDEREF 和 SMAP。

* 未列出的安全性漏洞代表已被 snadbox 解決掉了。

實作內容

Process Model Sandbox

Note: 內容程序 (Content Processes) 就是運行中的 web app,也會被限制在 sandbox 環境。

Gecko APIs 實作

內容程序可見的 APIs 絕不應該直接存取檔案系統,取而代的是應該透過 IPDL,所以說會需要存取資源的 API 都需要在父程序中有一個對應的元件代表 API 存取資源。

實作相關部分時要特別小心,所有送到父程序的輸入都應該要先消毒,不可以相信內容程序以及來自內容程序的 IPDL 訊息。

Warning: 任何內容程序取得的受信任授權都可以被用來繞過 sandbox 所加諸的限制。

何謂 seccomp

Seccomp 代表 secure computing mode (安全電腦模式),目前有兩種版本:

  1. seccomp, 可見於 Linux kernel 2.6.12 以上版本:

    • 開啟 seccomp 會將程序的系統呼叫 (System call) 限制在 read, write, sigreturn, 和 exit

    • 使用 prctl() system call

    • 可以在指定地方、程序初始化後啟動

  2. seccomp-bpf, 又稱為 seccomp mode filter 或 mode 2, 可見於 Linux kernel 3.5 以上版本:

    • 如同 seccomp,但多了 BPF 過濾系統呼叫

    • 可以使用系統呼叫白名單和啟動時傳入參數,而非單單預先寫死的作法

    • 更有彈性,可以有"較多自由的 sandbox",對限制性較低的 sandbox 來說很有用,而且也可以移轉到限制性較高的 sandbox

    • 多了一個安全性旗幟避免程序和子程序推翻既有權限限制

Note: 基於 seccomp-bpf 更有彈性,所以我們決定採用,並且替版本低於3.5 的 kernel (涵蓋了目前大部分的 Android kernel)提供向下相容移植。目前已經有不會造成衝突、可供使用的移植包 (請見 bug 790923).

Seccomp-bpf 效能

seccomp-bpf 會對每一次系統呼叫造成效能負擔,目前沒有一定的效能標竿準則,但我們預估大約最高 1% 的系統呼叫負擔會產生。

由於我們的程序模型減少許多系統呼叫,所以實際上我們預估效能負擔將會趨近於無。

不過因實作細節而異, IPDL 呼叫卻可能造成效能負擔以及增加延遲,建議對於資源需求密集的 API,如 OpenGL 呼叫,可以看一下 Chromium的實作細節。和 seccomp-bpf 一樣,我們能夠最少化 IPDL 呼叫次數來最小化效能負擔。

實作內容

seccomp 在 Gecko 以 --enable-content-sandbox 開啟。.

預設上系統呼叫拒絕資訊不會被回報,我們可以透過 --enable-content-sandbox-reporter 打開回報機制。

程式碼放在 gecko/security/sandbox,白名單放在 gecko/security/sandbox/seccomp_filter.h

檔案系統安全強化

風險

  • 讀、寫、刪除另一位使用者的檔案可能會導致資訊洩漏或未預期權限提升
  • 經由應用程式漏洞執行本地編譯碼
  • setuid 程式的安全漏洞導致權限提升

實作內容

原則上只有使用者內容區域可以讀寫 (除非 OS 未來要求新的讀寫區域),而且一定要包含 nodevnosuidnoexec 選項。標準檔案系統掛載點限制如下:

掛載點 檔案系統 選項
/ rootfs read-only
/dev tmpfs read-write, nosuid, noexec, mode=0755
/dev/pts ptsfs read-write, nosuid, noexec, mode=0600
/proc proc read-write, nosuid, nodev, noexec
/sys sysfs read-write, nosuid, nodev, noexec
/cache yaffs2 or ext4 read-write, nosuid, nodev, noexec
/efs yaffs2 or ext4 read-write, nosuid, nodev, noexec
/system ext4 read-only, nodev
/data ext4 read-write, nosuid, nodev, noexec
/mnt/sdcard ext4 or vfat read-write, nosuid, nodev, noexec, uid=1000, fmask=0702, dmask=0702
/acct cgroup read-write, nosuid, nodev, noexec
/dev/cpuctl cgroup read-write, nosuid, nodev, noexec

Note: 實際的掛載點可能有所變更

Linux DAC

Linux DAC represents 是一個有名的 Linux 檔案系統權限模型。

Note: 這是傳統的 user/group/others 權限模型,而非 Linux POSIX 1.e ACLs.

  • Web app 系統使用者沒有寫入任何檔案的權限
  • setuid 二進位檔只能在必要時使用
  • 新內容程序以合理的 umask 啟動

安全系統更新

風險

  • 受感染的更新檔案導致未受信任的更新檔被安裝
  • 受感染的更新檢查
    • 使用者看不到更新
    • 使用者更新到過時的更新檔,導致軟體降級
  • 安裝更新時受感染或未知的系統狀態可能導致:
    • 遺失安裝檔案,例如一些安全性修正檔
    • 安全性修正被受感染的系統推翻
  • 更新機制的安全漏洞
  • 對已知漏洞缺乏更新或追蹤

實作內容

Firefox OS 的更新機制使用安全的 Mozilla 程序,更新檔是由受信任,通常是 OEM 廠商,組建、測試、簽署數位簽章。

FOTA (Firmware over the air) 更新

系統更新可能涵蓋全部或部分 Firefox OS,如果更新涵蓋到 Gonk,那麼 FOTA (Firmware Over the Air) 安裝程序會被採用。FOTA 也可涵蓋到 OS 其他部分,例如裝置管理 (FOTA, firmware / drivers)、設定管理 (Firefox OS settings)、安全更新、Gaia、Gecko 等等。

MSU/MAR 更新

不牽涉到 Gonk 的更新可以透過 Mozilla 系統更新工具。Firefox OS 使用和桌面 FIrefox 一樣的更新架構、程序 Mozilla ARchive (MAR) 格式 (用於更新包)。

更新服務

Note: 更新服務能由 OEM 廠商提供。

手機內建的更新系統會定期檢查更新,一但發現新更新,會提示使用者安裝更新,另外安裝前也會檢查手機儲存空間以及驗證發行者身分:

  • 更新來源 (驗證更新和 manifest 檔的來源位置,protocol:domain:port)
  • 檔案完整性 (加密 hash checksums).
  • 程式碼簽章

下列安全性作法會用在更新程序:

  • Mozilla 建議並且預期更新有受信任的證明以及通過 SSL 下載。
  • 更新韌體需要高度加密驗證。
  • 更新前完整的更新檔必須從特定、安全的來源下載。
  • 當系統更新時,系統必須要在安全的狀態下,不可以運行任何 web app。
  • 金鑰必須存在裝置上安全的地方。

縝密的更新檢查確保正常地安裝更新。

Note: 更多有關更新資訊,請見 Creating and applying Firefox OS update packages.

 

文件標籤與貢獻者

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