驗證 SELinux

Android 強烈建議原始設備製造商 (OEM) 測試 SELinux 實作項目 製造商實作 SELinux,因此應該採用 套用至測試裝置集區。

套用新政策後,請發出 getenforce 指令,確認 SELinux 在裝置上執行的模式正確無誤。

這會列印全域 SELinux 模式:強制執行或寬鬆。如要判斷每個網域的 SELinux 模式,您必須檢查對應的檔案,或執行最新版本的 sepolicy-analyze,並加上 /platform/system/sepolicy/tools/ 中的適當 (-p) 標記。

讀取遭拒次數

檢查錯誤,這些錯誤會以事件記錄的形式傳送至 dmesglogcat,並可在裝置上本機查看。製造商應檢查這些裝置的 SELinux 輸出內容,並在公開發布時使用寬鬆模式,最後切換至強制模式,並調整設定。SELinux 記錄訊息包含 avc:,因此可能會 使用 grep 就能輕鬆找到。您可以執行 cat /proc/kmsg 擷取目前的拒絕記錄,也可以執行 cat /sys/fs/pstore/console-ramoops 擷取上次開機時的拒絕記錄。

為了避免記錄淹沒,系統會在啟動完成後限制 SELinux 錯誤訊息的傳送頻率。為確保您可以看到所有相關訊息,請停用這個功能 執行 adb shell auditctl -r 0

透過這些輸出內容,製造商可以輕鬆識別系統使用者 元件違反 SELinux 政策。製造商就能維修 或是軟體和/或 SELinux 政策變更。

具體來說,這些記錄訊息會指出在哪項程序下會失敗 以及強制執行模式的原因範例如下:

avc: denied  { connectto } for  pid=2671 comm="ping" path="/dev/socket/dnsproxyd"
scontext=u:r:shell:s0 tcontext=u:r:netd:s0 tclass=unix_stream_socket

依照以下方式解讀這個輸出內容:

  • 上述 { connectto } 代表目前採取的動作。 我們與 tclass (unix_stream_socket), 可讓您大概瞭解 這類模型在這個情況下,我們已嘗試連線至 Unix 串流通訊端。
  • scontext (u:r:shell:s0) 會指出啟動該動作的結構定義。於 這個範例的作用是 做為殼層執行
  • tcontext (u:r:netd:s0) 會顯示動作的目標背景資訊。在本例中,這是 netd 擁有的 unix_stream_socket。
  • 頂端的 comm="ping" 會提供額外提示,說明產生拒絕時正在執行的項目。在這個案例中,就是一個很好的提示

另一個範例:

adb shell su root dmesg | grep 'avc: '

輸出內容:

<5> type=1400 audit: avc:  denied  { read write } for  pid=177
comm="rmt_storage" name="mem" dev="tmpfs" ino=6004 scontext=u:r:rmt:s0
tcontext=u:object_r:kmem_device:s0 tclass=chr_file

以下是這次遭拒的主要元素:

  • 動作:嘗試的動作會以方括號 read writesetenforce 標示。
  • 執行者 - scontext (來源內容) 項目代表 演員,在本例中為 rmt_storage Daemon。
  • 物件tcontext (目標情境) 項目代表要執行的物件,在本例中為 kmem。
  • 結果 - tclass (目標類別) 項目代表類型 執行動作的物件,在本例中為 chr_file (字元裝置)。

傾印使用者和核心堆疊

在某些情況下,事件記錄中包含的資訊不足以找出確切資訊 和拒絕的來源收集呼叫鏈結通常很有用,包括核心和 使用者空間,進一步瞭解導致遭拒的原因。

近期的核心定義了名為 avc:selinux_audited 的追蹤點。使用 Android simpleperf 啟用這個追蹤點,並擷取呼叫鏈結。

支援的設定

  • 支援 Linux 核心 5.10 以上版本,特別是 Android 常見核心分支的 mainlineandroid12-5.10。也支援 android12-5.4 分支。您可以使用 simpleperf 判斷追蹤點是否為 : adb root && adb shell simpleperf list | grep avc:selinux_audited。 如為其他核心版本,則可選擇修訂版本 dd8166230969bc
  • 您應該可以重現要偵錯的事件。開機時間事件未 支援 Simpleperf但您還是可以重新啟動服務來觸發 活動。

擷取呼叫鏈結

第一步是使用 simpleperf record 記錄事件:

adb shell -t "cd /data/local/tmp && su root simpleperf record -a -g -e avc:selinux_audited"

接著,應該觸發造成拒絕的事件。之後,系統就會停止錄音。在此範例中,只要使用 Ctrl-c,系統應該已擷取範例:

^Csimpleperf I cmd_record.cpp:751] Samples recorded: 1. Samples lost: 0.

最後,simpleperf report 可用於檢查擷取的堆疊追蹤。 例如:

adb shell -t "cd /data/local/tmp && su root simpleperf report -g --full-callgraph"
[...]
Children  Self     Command  Pid   Tid   Shared Object                                   Symbol
100.00%   0.00%    dmesg    3318  3318  /apex/com.android.runtime/lib64/bionic/libc.so  __libc_init
       |
       -- __libc_init
          |
           -- main
              toybox_main
              toy_exec_which
              dmesg_main
              klogctl
              entry_SYSCALL_64_after_hwframe
              do_syscall_64
              __x64_sys_syslog
              do_syslog
              selinux_syslog
              slow_avc_audit
              common_lsm_audit
              avc_audit_post_callback
              avc_audit_post_callback

上述呼叫鏈結是統一核心和使用者空間呼叫鏈結。這能 從使用者空間開始到核心,執行程式碼流程的追蹤,從使用者空間開始追蹤到 也會發生拒絕的情況如要進一步瞭解 simpleperf,請參閱 Simpleperf 可執行指令參考資料

切換至寬容模式

在 userdebug 或 eng 版本中,您可以使用 ADB 停用 SELinux 強制執行機制。如要執行此操作,請先執行 adb root,將 ADB 切換為 root。接著,如要停用 SELinux 強制執行,請執行以下指令:

adb shell setenforce 0

或透過核心指令列 (早期裝置啟動期間):

androidboot.selinux=permissive
androidboot.selinux=enforcing

或透過 Android 12 中的 bootconfig:

androidboot.selinux=permissive
androidboot.selinux=enforcing

使用 audit2allow

audit2allow 工具會擷取 dmesg 個遭拒值, 並轉換為對應的 SELinux 政策陳述式。因此, 大幅加快 SELinux 的開發速度。

如要使用,請執行:

adb pull /sys/fs/selinux/policy
adb logcat -b events -d | audit2allow -p policy

不過,請務必仔細確認 導致過度耗用資源例如,以 audit2allow 提供 顯示先前的 rmt_storage 次拒絕顯示結果如下 建議的 SELinux 政策陳述式:

#============= shell ==============
allow shell kernel:security setenforce;
#============= rmt ==============
allow rmt kmem_device:chr_file { read write };

這會授予 rmt 寫入核心記憶體 (即 令人驚訝的audit2allow 陳述式通常只是 起點套用這些聲明後,您可能需要變更 來源網域和目標標籤,並會 才能達成良好的政策有時,審查中的拒登案件並不會導致任何政策變更,而是應變更違規的應用程式。