Android* 安全性自訂：SEAndroid

Android* 安全性自訂：SEAndroid

Android 安全性強化功能 (SEAndroid)

Android 在 4.4 版的 Android 作業系統 (「Kitkat」) 新增全新功能，其中最重要的變化就是能夠在強制模式整合 SEAndroid，也就是說所有 Android 元件的存取權限都由 SEAndroid 控制。
什麼是 SEAndroid？SEAndroid 代表 Android 安全性強化功能 (Security Enhancements for Android)，是 Android 的安全性解決方案，可找出並因應關鍵漏洞。這項專案最初是為了讓 SELinux 能在 Android 使用，以限制有缺陷或惡意應用程式可能造成的傷害，並於應用程式之間執行分離保證。不過之後專案範圍改變，以納入 SELinux 以外的其他項目。SEAndroid 目前作為整體架構，在 Android 實作 SELinux 強制存取控制 (MAC) 及中介軟體強制存取控制 (MMAC)。
以下釐清一些有關 SEAndroid 的概念：

• 安全增強式 Linux* (SELinux) 是強制存取控制實作，於 Linux 核心使用 Linux 安全模組 (LSM)，以最小權限原則為基礎。這並不是 Linux 發行版，而是一組修改，可套用至類 UNIX* 作業系統，例如 Linux 及 BSD。
• 自由存取控制 (DAC) 是 Linux 的標準安全性模型，其中的存取權限是以使用者身分及物件擁有權為基礎。
• 強制存取控制 (MAC) 會限制主體 (程序) 及物件 (檔案、通訊端、裝置等) 的權限。

SEAndroid 藉由將 SELinux 支援新增至核心及使用者空間來強化 Android 系統：
SEAndroid enhances the Android system by adding SELinux support to the kernel and user space to:

• 限制具權限精靈避免遭到誤用，並限制具權限精靈可能造成的傷害
• 在應用程式之間及應用程式與系統之間設置沙箱 (sandbox) 並加以隔離
• 預防應用程式權限提升
• 可利用 MMAC 於安裝及執行階段期間控制應用程式權限
• 提供集中且可分析的原則

此外在 Android 4.4 中，SEAndroid 可於強制模式啟用，而不是非功能性的停用模式，或僅限通知的寬容模式，亦即 Android 執行階段環境將禁止任何無效作業。

SEAndroid 原則

SEAndroid 原則是整體 SEAndroid 安全機制的核心之一。此外安全性架構也必須擁有嚴格的安全性原則，確保存取主體對物件僅具有最低存取權限，讓程式能夠執行基本功能，並避免執行惡意作業。
如前所述，SEAndroid 實作為強制模式，而不是非功能性的停用模式或僅限通知的寬容模式，可作為參照並協助測試及開發。
SEAndroid 的安全性內容基本上與 SELinux 一致。以下將說明使用者 (user)、角色 (role)、類型 (type) 及敏感度 (sensitivity) 等四個部分，亦即 u: object_r: system_data_file: s0：

• 使用者：第一個欄位的安全性內容就是 SEAndroid 中的 user，其中只有一個 u。
• 角色：第二個欄位代表 SEAndroid 中的 role，分別為 r 及 object_r。
• 類型：SEAndroid 針對第三個欄位類型定義 139 個不同原則類型，例如 device type、process type、file system type、network type、IPC type 等項目。
• 安全層級：第四個欄位用於提供多層次安全性 (延伸 MLS)，是一種存取機制，用於新增安全性內容及格式敏感度 [: category list] [- sensitivity [: category list]]，例如 s0 - s15: c0 - c1023，但目前 Android 版本可能不需要類別。結合敏感度及類別可宣告目前的安全性層級，並於最低及最高層級的安全性出現數字。本欄位參數用於 MLS 限制檢查，其中「15」及「1023」代表最高的敏感度及類別。本參數範圍可於 Android.mk 定義。

在第三個欄位類型中，安全性內容是最重要的部分，而程序類型則稱為 domain。Type 是最重要的 SEAndroid 參數，而原則參數則大幅擴展，因此讓每個檔案的系統標示適當類型就非常重要。
SEAndroid 原則來源位於 external/sepolicy。
原則包含來源檔案，用於產生 SELinux 核心原則檔案、file_contexts 組態、property_contexts組態、seapp_contexts 組態及 mac_permissions.xml 組態。

• file_contexts 組態用於在建置時間 (例如系統磁碟分割) 及執行階段 (例如裝置節點、服務通訊端檔案、init.rc 建立的 /data 目錄等) 標示檔案。
• property_contexts 組態用於指定 Android 屬性的安全性內容，以便允許進行檢查。
• seapp_contexts 組態用於標示應用程式程序及應用程式套件目錄。
• mac_permissions.xml 組態為中介軟體 MAC 原則。

裝置特定原則來源位於 device/<vendor>/<device>.

• 若要指定裝置特定原則，可定義 BOARD_SEPOLICY_DIRS, BOARD_SEPOLICY_UNION及 / 或 BOARD_SEPOLICY_REPLACE 變數 (在 BoardConfig.mk file 檔案，位於device/<vendor>/<device> 或 vendor/<vendor>/<device> directories, 也就是說採用 Intel® Atom™ 處理器平板電腦 (代碼為 Bay Trail) FFRD8 的組態檔案為"/device/intel/baytrail/BoardConfig.mk".
• 您可在 device/intel/baytrail/BoardConfig.mk找到範例，其中定義這些變數參照device/intel/baytrail/sepolicy 之下的裝置特定原則檔案。
• 如需每個裝置原則的文件，請前往 external/sepolicy/README.

變更 SEAndroid 原則

SEAndroid 原則位於 /external/sepolicy。您可變更這些原則檔案，觀察套用新原則時會發生什麼情形。變更原則檔案時請密切注意，因為錯誤組態可能讓整個系統在開機時終止。以下為範例：
步驟 1：在修改前進行檢查
首先，我們需要檢查檔案「/device/intel/baytrail/BoardConfig.mk」。此板的 sepolicy 組態如下：

BOARD_SEPOLICY_DIRS :=
device/intel/baytrail/sepolicy
BOARD_SEPOLICY_UNION :=
file_contexts
seapp_contexts
file.te
genfs_contexts
fs_use
device.te
healthd.te
app.te
untrusted_app.te
surfaceflinger.te
vold.te
ecryptfs.te
zygote.te
netd.te

BOARD_SEPOLICY_DIRS 定義裝置特定原則檔案所在的目錄。BOARD_SEPOLICY_UNION 代表最終原則組態是結合一般原則檔案及裝置特定原則檔案的結果。在 Android 建置程序期間，建置系統將檢查不同原則之間的衝突。若套用 BOARD_SEPOLICY_ REPLACE，就代表裝置特定原則將取代一般原則組態。
第二，我們需要開啟 「/external/sepolicy/untrusted_app.te」檔案，並檢查其中是否存在下列程式行：

Allow untrusted_app shell_data_file:file rw_file_perms
Allow untrusted_app shell_data_file:dir r_dir_perms

以上兩個原則項目提供權限給不受信任的應用程式 (一般應用程式，並不是系統應用程式)，以便使用執行階段環境下的 shell_data_file 類型讀取 / 寫入檔案及讀取目錄。shell_data_file 指向執行階段環境中 /data/local/tmp/ 的任何檔案，在下列開發環境中的 /external/sepolicy/file_contexts定義：
/data/local/tmp(/.*)? u:object_r:shell_data_file:s0
不過前述權限具有某些限制。若檔案及目錄存在於 /data/loacal/tmp/，則不受信任的應用程式可讀取 / 寫入這些檔案，並進入這些目錄。不過不受信任的應用程式不能在 /data/local/tmp/ 建立自己的檔案和目錄。只有系統應用程式或服務可針對不受信任應用程式建立檔案或目錄。如果要向不受信任的應用程式提供更多權限，可依據步驟 2 所述內容進行變更。
步驟 2：新增新原則項目
現在要編輯「/device/intel/baytrail/sepolicy/untrusted_app.te」檔案，並將下列兩個程式行新增至檔案結尾：

Allow untrusted_app shell_data_file:file create_file_perms

Allow untrusted_app shell_data_file:dir create_dir_perms

這兩個項目提供不受信任的應用程式權限，在執行階段環境的 /data/local/tmp/ 建立檔案及目錄，於下列開發環境中的 /external/sepolicy/file_contexts 定義：
/data/local/tmp(/.*)? u:object_r:shell_data_file:s0
基本檔案 / 目錄權限於 /external/sepolicy/global_macros 定義：

define(`x_file_perms', `{ getattr execute execute_no_trans }')

define(`r_file_perms', `{ getattr open read ioctl lock }')

define(`w_file_perms', `{ open append write }')

define(`rx_file_perms', `{ r_file_perms x_file_perms }')

define(`ra_file_perms', `{ r_file_perms append }')

define(`rw_file_perms', `{ r_file_perms w_file_perms }')

define(`rwx_file_perms', `{ rw_file_perms x_file_perms }')

define(`link_file_perms', `{ getattr link unlink rename }')

define(`create_file_perms', `{ create setattr rw_file_perms link_file_perms }')

define(`r_dir_perms', `{ open getattr read search ioctl }')

define(`w_dir_perms', `{ open search write add_name remove_name }')

define(`ra_dir_perms', `{ r_dir_perms add_name write }')

define(`rw_dir_perms', `{ r_dir_perms w_dir_perms }')

define(`create_dir_perms', `{ create reparent rmdir setattr rw_dir_perms link_file_perms }')

我們可發現如檔案作業「{ getattr open read ioctl lock }」等權限，與真實檔案系統的檔案作業函數相同。
最後我們需要重新建置 Android 來源樹狀結構，並將新映像置入 Bay Trail FFRD8 裝置。

驗證 SEAndroid 原則

FFRD8 開機後，我們可由 Android 應用程式商店下載 FileManager 應用程式，然後由 FileManager 選單開啟命令殼層。這樣可以模擬不受信任的應用程式執行檔案作業的狀況。
進入 /data/local/tmp/ 目錄建立新的檔案及目錄，就可建立新的檔案及目錄。(標準 FFRD8 裝置禁止建立新的檔案及目錄)。不同原則的結果顯示於以下比較影像，左圖顯示未變更原則的結果，右圖則顯示變更原則的結果：

圖 1：標準原則及變更原則之間的檔案權限比較
結論
本文介紹 SEAndroid 原則的基本概念，並以 Intel Atom 處理器平台 (代碼為 Bay Trail) 為依據，提出範例說明如何將新原則新增至 SEAndroid 原則集。這將協助有意自訂建構 SEAndroid 的 ODM 初步瞭解 SEAndroid 原則機制。

關於作者

Liang Z. Zhang 是 Intel 中國開發者關係部 (Intel PRC Developer Relationship Division) 的應用程式工程師，負責支援企業應用程式開發者在 Intel® 平台實現安全性技術。