init 進程具有幾乎不受限制的權限，並使用來自系統和供應商分區的輸入腳本在引導過程中初始化系統。這種訪問會在 Treble 系統/供應商拆分中造成一個巨大的漏洞，因為供應商腳本可能會指示 init 訪問不構成穩定係統-供應商應用程序二進制接口 (ABI) 一部分的文件、屬性等。
供應商 init旨在通過使用單獨的安全增強型 Linux (SELinux) 域vendor_init以運行在/vendor中找到的具有供應商特定權限的命令來填補這個漏洞。
機制
供應商 init 在引導過程的早期使用 SELinux 上下文u:r:vendor_init:s0派生一個 init 子進程。這個 SELinux 上下文的權限比默認的 init 上下文少得多，並且它的訪問權限僅限於特定於供應商或穩定係統供應商 ABI 的文件、屬性等。
Init 檢查它加載的每個腳本以查看其路徑是否以/vendor開頭，如果是，則標記它，指示其命令必須在供應商 init 上下文中運行。每個 init 內置函數都用一個布爾值進行註釋，該布爾值指定該命令是否必須在供應商 init 子進程中運行：
- 大多數訪問文件系統的命令都被註釋為在供應商 init 子進程中運行，因此受供應商 init SEPolicy 的約束。
- 大多數影響內部初始化狀態的命令（例如，啟動和停止服務）都在正常的初始化進程中運行。這些命令被告知供應商腳本正在調用它們來執行它們自己的非 SELinux 權限處理。
init 的主處理循環包含一個檢查，如果命令被註釋為在供應商子進程中運行並且源自供應商腳本，則該命令通過進程間通信 (IPC) 發送到供應商 init 子進程，後者運行命令並將結果發送回 init。
使用供應商初始化
Vendor init 默認啟用，其限制適用於/vendor分區中存在的所有 init 腳本。供應商 init 應該對那些腳本已經不訪問僅系統文件、屬性等的供應商是透明的。
但是，如果給定供應商腳本中的命令違反了供應商初始化限制，則這些命令將失敗。失敗的命令在內核日誌中有一行（用 dmesg 可見）從 init 開始指示失敗。 SELinux 審核伴隨任何因 SELinux 策略而失敗的失敗命令。包括 SELinux 審核的失敗示例：
type=1400 audit(1511821362.996:9): avc: denied { search } for pid=540 comm="init" name="nfc" dev="sda45" ino=1310721 scontext=u:r:vendor_init:s0 tcontext=u:object_r:nfc_data_file:s0 tclass=dir permissive=0
init: Command 'write /data/nfc/bad_file_access 1234' action=boot (/vendor/etc/init/hw/init.walleye.rc:422) took 2ms and failed: Unable to write to file '/data/nfc/bad_file_access': open() failed: Permission denied如果命令失敗，有兩種選擇：
- 如果命令由於預期的限製而失敗（例如，如果命令正在訪問系統文件或屬性），則必須以對 Treble 友好的方式重新實現該命令，僅通過穩定的接口。 Neverallow 規則阻止添加訪問不屬於穩定係統供應商 ABI 的系統文件的權限。
- 如果 SELinux 標籤是新的，並且尚未在系統
vendor_init.te中授予權限，也未通過 neverallow 規則排除權限，則新標籤可能會在特定於設備的vendor_init.te中授予權限。
對於在 Android 9 之前啟動的設備，可以通過將data_between_core_and_vendor_violators類型屬性添加到設備特定的vendor_init.te文件來繞過 neverallows 規則。
代碼位置
供應商初始化 IPC 的大部分邏輯位於system/core/init/subcontext.cpp中。
命令表位於system/core/init/ builtins.cpp 中的BuiltinFunctionMap類中，並包含指示命令是否必須在供應商 init 子進程中運行的註釋。
供應商 init 的 SEPolicy 拆分為 system/sepolicy 中的私有 (system/sepolicy/private/vendor_init.te ) 和公共 ( system/sepolicy/public/vendor_init.te ) 目錄。