1. SELinux 背景知識 1.1 DAC 與 MAC 在 SELinux 出現之前，Linux 上的安全模型叫 DAC，全稱是 Discretionary Access Control，翻譯為自主訪問控制。 DAC 的核心思想很簡單，就是：進程理論上所擁有的許可權與執行它的用戶的許可權相同。比如， ...
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};
