1. SELinux 背景知識
1.1 DAC 與 MAC
在 SELinux 出現之前，Linux 上的安全模型叫 DAC，全稱是 Discretionary Access Control，翻譯為自主訪問控制，
DAC 的核心思想很簡單，就是：行程理論上所擁有的權限與執行它的用戶的權限相同，比如，以 root 用戶啟動 Browser，那么 Browser 就有 root 用戶的權限，在 Linux 系統上能干任何事情，
顯然，DAD 管理太過寬松，只要想辦法在 Android 系統上獲取到 root 權限就可以了，那么 SELinux 是怎么解決這個問題呢？在 DAC 之外，它設計了一種新的安全模型，叫 MAC（Mandatory Access Control），翻譯為強制訪問控制，
MAC 的理論也很簡單，任何行程想在 SELinux 系統上干任何事情，都必須在《安全策略檔案》中賦予權限，凡是沒有出現在安全策略檔案中的權限，就不行，
關于 DAC 和 MAC，可以總結幾個知識點：
- Linux 系統先做 DAC 檢查，如果沒有通過 DAC 權限檢查，則操作直接失敗，通過 DAC 檢查之后，再做 MAC 權限檢查
- SELinux 有自己的一套規則來撰寫安全策略檔案，這套規則被稱之為 SELinux Policy 語言，
1.2 SEPolicy 語言
Linux中有兩種東西，一種死的（Inactive），一種活的（Active），死的東西就是檔案（Linux哲學，萬物皆檔案，注意，萬不可狹義解釋為File），而活的東西就是行程，此處的 死 和 活 是一種比喻，映射到軟體層面的意思是：行程能發起動作，例如它能打開檔案并操作它，而檔案只能被行程操作，
根據 SELinux 規范，完整的 Secure Context 字串為：user:role:type[:range]
1.2.1 行程的 Secure Context
在 SELinux 中，每種東西都會被賦予一個安全屬性，官方說法叫做 Security Context，Security Context 是一個字串，主要由三個部分組成，例如 SEAndroid 中，行程的 Security Context 可通過 ps -Z 命令查看：
rk3288:/ $ ps -AZ
u:r:hal_wifi_supplicant_default:s0 wifi 1816 1 11388 6972 0 0 S wpa_supplicant
u:r:platform_app:s0:c512,c768 u0_a14 1388 228 1612844 57396 0 0 S android.ext.services
u:r:system_app:s0 system 1531 228 1669680 119364 0 0 S com.android.gallery3d
u:r:kernel:s0 root 582 2 0 0 0 0 S [kworker/1:2]
u:r:radio:s0 radio 594 228 1634876 89296 0 0 S com.android.phone
u:r:system_app:s0 system 672 228 1686204 141716 0 0 S com.android.settings
u:r:platform_app:s0:c512,c768 u0_a18 522 223 1721656 152116 0 0 S com.android.systemui
上面的最左邊的一列就是行程的 Security Context，以第一個行程 wpa_supplicant 為例
u:r:hal_wifi_supplicant_default:s0
其中:
- u 為 user 的意思，SEAndroid 中定義了一個 SELinux 用戶，值為 u
- r 為 role 的意思，role 是角色之意，它是 SELinux 中一個比較高層次，更方便的權限管理思路，簡單點說，一個 u 可以屬于多個 role，不同的 role 具有不同的權限，
- hal_wifi_supplicant_default 代表該行程所屬的 Domain 為 hal_wifi_supplicant_default，MAC（Mandatory Access Control）強制訪問控制 的基礎管理思路其實是 Type Enforcement Access Control（簡稱TEAC，一般用TE表示），對行程來說，Type 就是 Domain，比如 hal_wifi_supplicant_default 需要什么權限，都需要通過 allow 陳述句在 te 檔案中進行說明，
- s0 是 SELinux 為了滿足軍用和教育行業而設計的 Multi-Level Security（MLS）機制有關，簡單點說，MLS 將系統的行程和檔案進行了分級，不同級別的資源需要對應級別的行程才能訪問
1.2.2 檔案的 Secure Context
檔案的 Secure Context 可以通過 ls -Z 來查看，如下
rk3288:/vendor/lib $ ls libOMX_Core.so -Z
u:object_r:vendor_file:s0 libOMX_Core.so
- u：同樣是 user 之意，它代表創建這個檔案的 SELinux user
- object_r：檔案是死的東西，它沒法扮演角色，所以在 SELinux 中，死的東西都用 object_r 來表示它的 role
- vendor_file：type，和行程的 Domain 是一個意思，它表示 libOMX_Core.so 檔案所屬的 Type 是 vendor_file
- s0：MLS 的等級
1.3 TE 介紹
MAC 基本管理單位是 TEAC（Type Enforcement Accesc Control），然后是高一級別的 Role Based Accesc Control，RBAC 是基于 TE 的，而 TE 也是 SELinux 中最主要的部分，上面說的 allow 陳述句就是 TE 的范疇，
根據 SELinux 規范，完整的 SELinux 策略規則陳述句格式為：
allow domains types:classes permissions;
- Domain - 一個行程或一組行程的標簽，也稱為域型別，因為它只是指行程的型別，
- Type - 一個物件（例如，檔案、套接字）或一組物件的標簽，
- Class - 要訪問的物件（例如，檔案、套接字）的型別，
- Permission - 要執行的操作（例如，讀取、寫入），
= allow ： 允許主體對客體進行操作
= neverallow ：拒絕主體對客體進行操作
= dontaudit ： 表示不記錄某條違反規則的決策資訊
= auditallow ：記錄某項決策資訊，通常 SElinux 只記錄失敗的資訊，應用這條規則后會記錄成功的決策資訊，
使用政策規則時將遵循的結構示例：
陳述句：
allow appdomain app_data_file:file rw_file_perms;
這表示所有應用域都可以讀取和寫入帶有 app_data_file 標簽的檔案
—> 相關實體
1. SEAndroid 中的安全策略檔案 policy.conf
# 允許 zygote 域中的行程向 init 域中的行程（Object Class 為 process）發送 sigchld 信號
allow zygote init:process sigchld;
2. # 允許 zygote 域中的行程 search 或 getattr 型別為 appdomain 的目錄，
# 注意，多個 perm_set 可用 {} 括起來
allow zygote appdomain:dir { getattr search };
3. # perm_set 語法比較奇特，前面有一個 ~ 號，
# 它表示除了{entrypoint relabelto}之外，{chr_file #file}這兩個object_class所擁有的其他操作
allow unconfineddomain {fs_type dev_type file_type}:{ chr_file file } \
~{entrypoint relabelto};
轉載請註明出處，本文鏈接：https://www.uj5u.com/yidong/4159.html
標籤：Android