android 8.1 安全機制 — SEAndroid & SELinux

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，能夠總結幾個知識點：

1. Linux 系統先作 DAC 檢查。若是沒有經過 DAC 權限檢查，則操做直接失敗。經過 DAC 檢查以後，再作 MAC 權限檢查
2. 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};