Search This Blog

7/23/16

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 定義。
在第三個欄位類型中,安全性內容是最重要的部分,而程序類型則稱為 domainType 是最重要的 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_DIRSBOARD_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® 平台實現安全性技術。

No comments:

Post a Comment

Related Posts Plugin for WordPress, Blogger...