完整性策略執行 (IPE)¶
注意
本文件面向嘗試使用 IPE 的管理員、系統構建者或個人。 如果您正在尋找更多以開發人員為中心的 IPE 文件，請參閱設計文件。
概述¶
完整性策略執行 (IPE) 是一種 Linux 安全模組，它採用了一種與訪問控制互補的方法。 與依賴於標籤和路徑進行決策的傳統訪問控制機制不同，IPE 專注於系統元件固有的不可變安全屬性。 這些屬性是系統元件的基本屬性或特徵，無法更改，從而確保了安全決策的一致且可靠的基礎。
詳細說明，在 IPE 的上下文中，系統元件主要指檔案或這些檔案所在的裝置。 然而，這只是一個起點。 系統元件的概念是靈活的，並且可以擴充套件到包括隨著系統發展的新元素。 不可變屬性包括檔案的來源，它隨著時間的推移保持不變且不可更改。 例如，可以制定 IPE 策略來信任來自 initramfs 的檔案。 由於 initramfs 通常由引導載入程式驗證，因此其檔案被認為是可信的； “檔案來自 initramfs”成為 IPE 考慮的不可變屬性。
不可變屬性概念擴充套件到檔案來源上啟用的安全功能，例如 dm-verity 或 fs-verity，它們提供了一層完整性和信任。 例如，IPE 允許定義信任來自 dm-verity 保護裝置的檔案策略。 dm-verity 透過提供其內容的可驗證和不可變狀態來確保整個裝置的完整性。 類似地，fs-verity 提供檔案系統級別的完整性檢查，允許 IPE 強制執行信任受 fs-verity 保護的檔案策略。 一旦建立這些功能就無法關閉，因此它們被認為是不可變屬性。 這些示例展示了 IPE 如何利用不可變屬性（例如檔案的來源及其完整性保護機制）來做出訪問控制決策。
對於 IPE 策略，具體來說，它透過評估安全屬性與策略中定義的參考值來授予強制執行嚴格訪問控制的能力。 此評估可以基於安全屬性的存在（例如，驗證檔案是否源自 initramfs）或評估不可變安全屬性的內部狀態。 後者包括檢查 dm-verity 保護裝置的 roothash、確定 dm-verity 是否具有有效的簽名、評估 fs-verity 保護檔案的摘要，或確定 fs-verity 是否具有有效的內建簽名。 這種細緻的策略強制執行方法支援高度安全且可定製的系統防禦機制，該機制根據特定的安全要求和信任模型量身定製。
要啟用 IPE，請確保啟用了 CONFIG_SECURITY_IPE（在 下）配置選項。
用例¶
IPE 在固定功能裝置中效果最佳：裝置的用途明確定義且不應更改（例如資料中心的網路防火牆裝置、IoT 裝置等），其中所有軟體和配置均由系統所有者構建和配置。
IPE 距離在通用計算中使用還有很長的路要走：整個 Linux 社群傾向於遵循去中心化的信任模型（稱為信任網路），IPE 尚不支援該模型。 相反，IPE 支援 PKI（公鑰基礎設施），通常指定一組受信任的實體，這些實體提供一定程度的絕對信任。
此外，雖然今天大多數軟體包都已簽名，但軟體包中的檔案（例如，可執行檔案）往往未簽名。 這使得在期望包管理器正常執行的系統中很難利用 IPE，而無需對包管理器及其背後的生態系統進行重大更改。
digest_cache LSM [1] 是一個系統，當與 IPE 結合使用時，可用於啟用和支援通用計算用例。
已知限制¶
IPE 無法驗證匿名可執行記憶體的完整性，例如 gcc 閉包和 libffi（<3.4.2）建立的 trampoline，或 JIT 的程式碼。 不幸的是，由於這是動態生成的程式碼，IPE 無法確保此程式碼的完整性以形成信任基礎。
當透過將這些程式檔案傳遞給直譯器來呼叫這些指令碼時，IPE 無法驗證用解釋語言編寫的程式的完整性。 這是因為直譯器執行這些檔案的方式； 指令碼本身不會透過 IPE 的一個鉤子評估為可執行程式碼，但它們只是讀取的文字檔案（而不是編譯的可執行檔案） [2]。
威脅模型¶
IPE 專門針對核心最初啟動後篡改使用者空間可執行程式碼的風險，包括透過 modprobe 或 insmod 從使用者空間載入的核心模組。
為了說明這一點，請考慮這樣一種情況：下載了一個不受信任的二進位制檔案（可能是惡意檔案）以及所有必需的依賴項，包括載入程式和 libc。 在這種情況下，IPE 的主要功能是阻止執行此類二進位制檔案及其依賴項。
IPE 透過在允許所有可執行程式碼執行之前驗證其完整性和真實性來實現此目的。 它進行徹底的檢查，以確保程式碼的完整性完好無損，並且它們與定義的策略中授權的參考值（摘要、簽名等）匹配。 如果二進位制檔案未透過此驗證過程，無論是由於其完整性已受到破壞還是不符合授權標準，IPE 將拒絕執行它。 此外，IPE 生成稽核日誌，可用於檢測和分析因策略違反導致的失敗。
篡改威脅場景包括各種參與者修改或替換可執行程式碼，包括
可以物理訪問硬體的參與者
可以本地網路訪問系統的參與者
可以訪問部署系統的參與者
受外部控制的受損內部系統
系統的惡意終端使用者
系統的受損終端使用者
遠端（外部）系統入侵
IPE 不會減輕由惡意但已授權的開發人員（可以訪問簽名證書）或他們使用的受損開發工具（即面向返回的程式設計攻擊）引起的威脅。 此外，IPE 在使用者空間和核心空間之間劃定了嚴格的安全邊界。 因此，核心級漏洞利用被認為超出了 IPE 的範圍，緩解措施留給其他機制。
策略¶
IPE 策略是純文字 [3] 策略，由多行上的多個語句組成。 策略頂部需要一行，指示策略名稱和策略版本，例如
policy_name=Ex_Policy policy_version=0.0.0
策略名稱是一個唯一的鍵，用於以人類可讀的名稱標識此策略。 這用於在 securityfs 下建立節點，以及唯一標識用於部署新策略與更新現有策略的策略。
策略版本指示策略的當前版本（不是策略語法版本）。 這用於防止策略回滾到可能不安全的前一個版本。
IPE 策略的下一部分是規則。 規則由鍵=值對組成，稱為屬性。 IPE 規則需要兩個屬性：action，它確定 IPE 在遇到與規則匹配時所做的事情，以及 op，它確定何時應評估該規則。 排序很重要，規則必須以 op 開頭，並以 action 結尾。 因此，最小規則是
op=EXECUTE action=ALLOW
此示例將允許任何執行。 其他屬性用於評估有關正在評估的檔案的不可變安全屬性。 這些屬性旨在描述核心中的系統，這些系統可以提供完整性驗證的度量，以便 IPE 可以根據屬性的值確定資源的信任。
規則從上到下評估。 因此，任何撤銷規則或拒絕都應放在檔案的前面，以確保在具有 action=ALLOW 的規則之前評估這些規則。
IPE 策略支援註釋。 字元“#”將用作註釋，忽略“#”右側的所有字元，直到換行符。
IPE 評估的預設行為也可以透過 DEFAULT 語句在策略中表達。 這可以在全域性級別或每個操作級別完成
# Global
DEFAULT action=ALLOW
# Operation Specific
DEFAULT op=EXECUTE action=ALLOW
必須為 IPE 中所有已知的操作設定預設值。 如果您希望保留與可以引入新操作的較新核心相容的舊策略，請設定 ALLOW 的全域性預設值，然後按每個操作覆蓋預設值（如上所示）。
對於基於可配置策略的 LSM，在啟動時強制執行可配置策略存在幾個問題，圍繞讀取和解析策略
核心不應從使用者空間讀取檔案，因此禁止直接讀取策略檔案。
核心命令列具有字元限制，並且一個核心模組不應為其自身的配置保留整個字元限制。
核心生態系統中存在各種引導載入程式，因此移交記憶體塊的維護成本很高。
因此，IPE 透過“引導策略”的概念解決了這個問題。 引導策略是編譯到核心中的最小策略。 此策略旨在使系統進入使用者空間已設定好並準備好接收命令的狀態，此時可以透過 securityfs 部署更復雜的策略。 引導策略可以透過 SECURITY_IPE_BOOT_POLICY 配置選項指定，該選項接受要應用的 IPE 策略的純文字版本的路徑。 此策略將被編譯到核心中。 如果未指定，IPE 將被停用，直到透過 securityfs 部署和啟用策略。
部署策略¶
可以透過 securityfs 從使用者空間部署策略。 這些策略透過 PKCS#7 訊息格式簽名，以強制執行策略的某種程度的授權（禁止攻擊者獲得不受約束的 root 許可權，並部署“允許所有”策略）。 這些策略必須由連結到 SYSTEM_TRUSTED_KEYRING 的證書籤名，如果啟用了 CONFIG_IPE_POLICY_SIG_SECONDARY_KEYRING 和/或 CONFIG_IPE_POLICY_SIG_PLATFORM_KEYRING，則必須由輔助和/或平臺金鑰環簽名。 使用 openssl，該策略可以透過以下方式簽名
openssl smime -sign \
-in "$MY_POLICY" \
-signer "$MY_CERTIFICATE" \
-inkey "$MY_PRIVATE_KEY" \
-noattr \
-nodetach \
-nosmimecap \
-outform der \
-out "$MY_POLICY.p7b"
部署策略是透過 securityfs 完成的，透過 new_policy 節點。 要部署策略，只需將檔案 cat 到 securityfs 節點中
cat "$MY_POLICY.p7b" > /sys/kernel/security/ipe/new_policy
成功後，這將在 /sys/kernel/security/ipe/policies/ 下建立一個子目錄。 該子目錄將是已部署策略的 policy_name 欄位，因此對於上面的示例，該目錄將是 /sys/kernel/security/ipe/policies/Ex_Policy。 在此目錄中，將有七個檔案：pkcs7、policy、name、version、active、update 和 delete。
pkcs7 檔案是隻讀的。 讀取它會返回提供給核心的原始 PKCS#7 資料，表示該策略。 如果正在讀取的策略是引導策略，則這將返回 ENOENT，因為它未簽名。
policy 檔案是隻讀的。 讀取它會返回策略的 PKCS#7 內部內容，這將是純文字策略。
active 檔案用於將策略設定為當前活動的策略。 此檔案是讀寫的，並接受值 "1" 以將該策略設定為活動的。 由於一次只能啟用一個策略，因此所有其他策略都將被標記為非活動的。 被標記為活動的策略必須具有大於或等於當前執行版本的策略版本。
update 檔案用於更新核心中已存在的策略。 此檔案是隻寫的，並接受 PKCS#7 簽名策略。 將始終對此策略執行兩個檢查：首先，policy_names 必須與更新版本和現有版本匹配。 其次，更新的策略必須具有大於當前執行版本的策略版本。 這是為了防止回滾攻擊。
delete 檔案用於刪除不再需要的策略。 此檔案是隻寫的，並接受值 1 以刪除該策略。 刪除後，將刪除表示該策略的 securityfs 節點。 但是，不允許刪除當前活動的策略，並且將返回不允許操作錯誤。
類似地，寫入 update 和 new_policy 可能會導致錯誤訊息（策略語法錯誤）或檔案存在錯誤。 後者錯誤發生在嘗試部署具有 policy_name 的策略時，而核心已經部署了具有相同 policy_name 的策略。
部署策略不會導致 IPE 開始強制執行該策略。 IPE 將僅強制執行標記為活動的策略。 請注意，一次只能啟用一個策略。
部署成功後，可以透過寫入檔案 /sys/kernel/security/ipe/policies/$policy_name/active 來啟用該策略。 例如，可以透過以下方式啟用 Ex_Policy
echo 1 > "/sys/kernel/security/ipe/policies/Ex_Policy/active"
從上述點開始，Ex_Policy 現在是系統上強制執行的策略。
IPE 還提供了一種刪除策略的方法。 這可以透過 delete securityfs 節點 /sys/kernel/security/ipe/policies/$policy_name/delete 完成。 將 1 寫入該檔案會刪除該策略
echo 1 > "/sys/kernel/security/ipe/policies/$policy_name/delete"
刪除策略只有一個要求：要刪除的策略必須處於非活動狀態。
注意
如果啟用了傳統的 MAC 系統（SELinux、apparmor、smack），則所有寫入 ipe 的 securityfs 節點都需要 CAP_MAC_ADMIN。
模式¶
IPE 支援兩種操作模式：允許模式（類似於 SELinux 的允許模式）和強制模式。 在允許模式下，將檢查所有事件並記錄策略衝突，但實際上並未強制執行該策略。 這允許使用者在強制執行策略之前對其進行測試。
預設模式是強制執行，可以透過核心命令列引數 ipe.enforce=(0|1) 或 securityfs 節點 /sys/kernel/security/ipe/enforce 進行更改。
注意
如果啟用了傳統的 MAC 系統（SELinux、apparmor、smack 等），則所有寫入 ipe 的 securityfs 節點都需要 CAP_MAC_ADMIN。
稽核事件¶
1420 AUDIT_IPE_ACCESS¶
事件示例
type=1420 audit(1653364370.067:61): ipe_op=EXECUTE ipe_hook=MMAP enforcing=1 pid=2241 comm="ld-linux.so" path="/deny/lib/libc.so.6" dev="sda2" ino=14549020 rule="DEFAULT action=DENY"
type=1300 audit(1653364370.067:61): SYSCALL arch=c000003e syscall=9 success=no exit=-13 a0=7f1105a28000 a1=195000 a2=5 a3=812 items=0 ppid=2219 pid=2241 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=2 comm="ld-linux.so" exe="/tmp/ipe-test/lib/ld-linux.so" subj=unconfined key=(null)
type=1327 audit(1653364370.067:61): 707974686F6E3300746573742F6D61696E2E7079002D6E00
type=1420 audit(1653364735.161:64): ipe_op=EXECUTE ipe_hook=MMAP enforcing=1 pid=2472 comm="mmap_test" path=? dev=? ino=? rule="DEFAULT action=DENY"
type=1300 audit(1653364735.161:64): SYSCALL arch=c000003e syscall=9 success=no exit=-13 a0=0 a1=1000 a2=4 a3=21 items=0 ppid=2219 pid=2472 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=2 comm="mmap_test" exe="/root/overlake_test/upstream_test/vol_fsverity/bin/mmap_test" subj=unconfined key=(null)
type=1327 audit(1653364735.161:64): 707974686F6E3300746573742F6D61696E2E7079002D6E00
此事件表明 IPE 做出了一項訪問控制決策； IPE 特定記錄 (1420) 始終與 AUDITSYSCALL 記錄一起發出。
確定 IPE 是處於允許模式還是強制執行模式可以從 success 屬性和 AUDITSYSCALL 記錄的退出程式碼中得出。
欄位描述
欄位 |
值型別 |
可選？ |
值的描述 |
|---|---|---|---|
ipe_op |
字串 |
否 |
與日誌關聯的 IPE 操作名稱 |
ipe_hook |
字串 |
否 |
觸發 IPE 事件的 LSM 鉤子的名稱 |
enforcing |
整數 |
否 |
當前的 IPE 強制執行狀態 1 處於強制執行模式，0 處於允許模式 |
pid |
整數 |
否 |
觸發 IPE 事件的程序的 pid。 |
comm |
字串 |
否 |
觸發 IPE 事件的程序的命令列程式名稱 |
path |
字串 |
是 |
被評估檔案的絕對路徑 |
ino |
整數 |
是 |
被評估檔案的 inode 編號 |
dev |
字串 |
是 |
被評估檔案的裝置名稱，例如 vda |
rule |
字串 |
否 |
匹配的策略規則 |
1421 AUDIT_IPE_CONFIG_CHANGE¶
事件示例
type=1421 audit(1653425583.136:54): old_active_pol_name="Allow_All" old_active_pol_version=0.0.0 old_policy_digest=sha256:E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855 new_active_pol_name="boot_verified" new_active_pol_version=0.0.0 new_policy_digest=sha256:820EEA5B40CA42B51F68962354BA083122A20BB846F26765076DD8EED7B8F4DB auid=4294967295 ses=4294967295 lsm=ipe res=1
type=1300 audit(1653425583.136:54): SYSCALL arch=c000003e syscall=1 success=yes exit=2 a0=3 a1=5596fcae1fb0 a2=2 a3=2 items=0 ppid=184 pid=229 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=4294967295 comm="python3" exe="/usr/bin/python3.10" key=(null)
type=1327 audit(1653425583.136:54): PROCTITLE proctitle=707974686F6E3300746573742F6D61696E2E7079002D66002E2
此事件表明 IPE 將活動策略從一個策略切換到另一個策略，以及這兩個策略的版本和雜湊摘要。 請注意，IPE 一次只能有一個活動策略，所有訪問決策評估均基於當前活動策略。 部署新策略的正常過程是首先將要部署的策略載入到核心中，然後將活動策略切換到該策略。
此記錄將始終與 write 系統呼叫的 AUDITSYSCALL 記錄一起發出。
欄位描述
欄位 |
值型別 |
可選？ |
值的描述 |
|---|---|---|---|
old_active_pol_name |
字串 |
是 |
上一個活動策略的名稱 |
old_active_pol_version |
字串 |
是 |
上一個活動策略的版本 |
old_policy_digest |
字串 |
是 |
上一個活動策略的雜湊 |
new_active_pol_name |
字串 |
否 |
當前活動策略的名稱 |
new_active_pol_version |
字串 |
否 |
當前活動策略的版本 |
new_policy_digest |
字串 |
否 |
當前活動策略的雜湊 |
auid |
整數 |
否 |
登入使用者 ID |
ses |
整數 |
否 |
登入會話 ID |
lsm |
字串 |
否 |
與該事件關聯的 lsm 名稱 |
res |
整數 |
否 |
已稽核操作的結果（成功/失敗） |
1422 AUDIT_IPE_POLICY_LOAD¶
事件示例
type=1422 audit(1653425529.927:53): policy_name="boot_verified" policy_version=0.0.0 policy_digest=sha256:820EEA5B40CA42B51F68962354BA083122A20BB846F26765076DD8EED7B8F4DB auid=4294967295 ses=4294967295 lsm=ipe res=1 errno=0
type=1300 audit(1653425529.927:53): arch=c000003e syscall=1 success=yes exit=2567 a0=3 a1=5596fcae1fb0 a2=a07 a3=2 items=0 ppid=184 pid=229 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=4294967295 comm="python3" exe="/usr/bin/python3.10" key=(null)
type=1327 audit(1653425529.927:53): PROCTITLE proctitle=707974686F6E3300746573742F6D61696E2E7079002D66002E2E
此記錄表明已將新策略載入到核心中，並帶有策略名稱、策略版本和策略雜湊。
此記錄將始終與 write 系統呼叫的 AUDITSYSCALL 記錄一起發出。
欄位描述
欄位 |
值型別 |
可選？ |
值的描述 |
|---|---|---|---|
policy_name |
字串 |
是 |
策略名稱 |
policy_version |
字串 |
是 |
策略版本 |
policy_digest |
字串 |
是 |
策略雜湊 |
auid |
整數 |
否 |
登入使用者 ID |
ses |
整數 |
否 |
登入會話 ID |
lsm |
字串 |
否 |
與該事件關聯的 lsm 名稱 |
res |
整數 |
否 |
已稽核操作的結果（成功/失敗） |
errno |
整數 |
否 |
來自策略載入操作的錯誤程式碼（請參閱下表） |
策略錯誤程式碼 (errno)
下表列出了載入或更新策略時可能出現在 errno 欄位中的錯誤程式碼
錯誤程式碼 |
描述 |
|---|---|
0 |
成功 |
-EPERM |
許可權不足 |
-EEXIST |
已部署同名策略 |
-EBADMSG |
策略無效 |
-ENOMEM |
記憶體不足 (OOM) |
-ERANGE |
策略版本號溢位 |
-EINVAL |
策略版本解析錯誤 |
-ENOKEY |
用於簽署 IPE 策略的金鑰未在金鑰環中找到 |
-EKEYREJECTED |
策略簽名驗證失敗 |
-ESTALE |
嘗試使用舊版本更新 IPE 策略 |
-ENOENT |
策略在更新時被刪除 |
1404 AUDIT_MAC_STATUS¶
事件示例
type=1404 audit(1653425689.008:55): enforcing=0 old_enforcing=1 auid=4294967295 ses=4294967295 enabled=1 old-enabled=1 lsm=ipe res=1
type=1300 audit(1653425689.008:55): arch=c000003e syscall=1 success=yes exit=2 a0=1 a1=55c1065e5c60 a2=2 a3=0 items=0 ppid=405 pid=441 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=)
type=1327 audit(1653425689.008:55): proctitle="-bash"
type=1404 audit(1653425689.008:55): enforcing=1 old_enforcing=0 auid=4294967295 ses=4294967295 enabled=1 old-enabled=1 lsm=ipe res=1
type=1300 audit(1653425689.008:55): arch=c000003e syscall=1 success=yes exit=2 a0=1 a1=55c1065e5c60 a2=2 a3=0 items=0 ppid=405 pid=441 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=)
type=1327 audit(1653425689.008:55): proctitle="-bash"
此記錄將始終與 write 系統呼叫的 AUDITSYSCALL 記錄一起發出。
欄位描述
欄位 |
值型別 |
可選？ |
值的描述 |
|---|---|---|---|
enforcing |
整數 |
否 |
IPE 正要切換到的強制執行狀態，1 處於強制執行模式，0 處於允許模式 |
old_enforcing |
整數 |
否 |
IPE 正要從中切換的強制執行狀態，1 處於強制執行模式，0 處於允許模式 |
auid |
整數 |
否 |
登入使用者 ID |
ses |
整數 |
否 |
登入會話 ID |
enabled |
整數 |
否 |
新的 TTY 稽核啟用設定 |
old-enabled |
整數 |
否 |
舊的 TTY 稽核啟用設定 |
lsm |
字串 |
否 |
與該事件關聯的 lsm 名稱 |
res |
整數 |
否 |
已稽核操作的結果（成功/失敗） |
成功稽核¶
IPE 支援成功稽核。 啟用後，所有透過 IPE 策略且未被阻止的事件都將發出稽核事件。 預設情況下停用此功能，可以透過核心命令列 ipe.success_audit=(0|1) 或 /sys/kernel/security/ipe/success_audit securityfs 檔案啟用。
這非常嘈雜，因為 IPE 將檢查系統上的每個使用者空間二進位制檔案，但對於除錯策略很有用。
注意
如果啟用了傳統的 MAC 系統（SELinux、apparmor、smack 等），則所有寫入 ipe 的 securityfs 節點都需要 CAP_MAC_ADMIN。
屬性¶
如上所述，IPE 屬性是在 IPE 策略中表達的 key=value 對。 兩個屬性內置於策略解析器中：“op”和“action”。 其他屬性用於限制有關正在評估的檔案的不可變安全屬性。 目前，這些屬性是：“boot_verified”、“dmverity_signature”、“dmverity_roothash”、“fsverity_signature”、“fsverity_digest”。 下面列出了 IPE 支援的所有屬性的描述
op¶
指示規則要應用到的操作。 必須在每個規則中，作為第一個標記。 IPE 支援以下操作
EXECUTE適用於嘗試執行或載入為可執行檔案的任何檔案。
FIRMWARE:適用於透過 firmware_class 介面載入的韌體。 這包括預分配的緩衝區和韌體檔案本身。
KMODULE:適用於透過
modprobe或insmod載入核心模組。
KEXEC_IMAGE:適用於透過
kexec載入的核心映像。
KEXEC_INITRAMFS適用於透過
kexec --initrd載入的 initrd 映像。
POLICY:控制透過讀取核心空間啟動的讀取來載入策略。
例如，透過將策略檔案路徑寫入
$securityfs/ima/policy來載入 IMA 策略。
X509_CERT:控制透過 Kconfig 載入 IMA 證書，
CONFIG_IMA_X509_PATH和CONFIG_EVM_X509_PATH。
action¶
確定當規則匹配時 IPE 應該做什麼。必須在每個規則中，作為最終子句。可以是以下之一：
ALLOW:如果規則匹配，則顯式允許訪問該資源，而無需執行任何其他規則。
DENY:如果規則匹配，則顯式禁止訪問該資源，而無需執行任何其他規則。
boot_verified¶
此屬性可用於授權來自 initramfs 的檔案。 此屬性的格式為：
boot_verified=(TRUE|FALSE)警告
此屬性將信任來自 initramfs（rootfs）的檔案。 它應該僅在早期引導階段使用。 在將真正的 rootfs 掛載在 initramfs 之上之前，initramfs 指令碼將遞迴刪除 initramfs 上的所有檔案和目錄。 這通常透過使用 switch_root(8) [4] 實現。 因此，在真正的 rootfs 接管之後，initramfs 將為空且無法訪問。 建議在此之後切換到不依賴此屬性的不同策略。 這確保了信任策略在整個系統執行中保持相關性和有效性。
dmverity_roothash¶
此屬性可用於授權或撤銷特定的 dm-verity 卷，透過其 root hash 識別。 它依賴於 DM_VERITY 模組。 此屬性由
IPE_PROP_DM_VERITY配置選項控制，當SECURITY_IPE和DM_VERITY都啟用時，它將自動選擇。 此屬性的格式為：dmverity_roothash=DigestName:HexadecimalStringdmverity_roothash 支援的 DigestNames 為 [5]
blake2b-512
blake2s-256
sha256
sha384
sha512
sha3-224
sha3-256
sha3-384
sha3-512
sm3
rmd160
dmverity_signature¶
此屬性可用於授權所有具有簽名 roothash 的 dm-verity 卷，該 roothash 由 dm-verity 的配置指定的金鑰環驗證，可以是系統信任金鑰環或輔助金鑰環。 它依賴於
DM_VERITY_VERIFY_ROOTHASH_SIG配置選項，並由IPE_PROP_DM_VERITY_SIGNATURE配置選項控制，當SECURITY_IPE,DM_VERITY和DM_VERITY_VERIFY_ROOTHASH_SIG都啟用時，它將自動選擇。 此屬性的格式為：dmverity_signature=(TRUE|FALSE)
fsverity_digest¶
此屬性可用於授權特定的啟用 fsverity 的檔案，透過它們的 fsverity 摘要識別。 它依賴於
FS_VERITY配置選項，並由IPE_PROP_FS_VERITY配置選項控制，當SECURITY_IPE和FS_VERITY都啟用時，它將自動選擇。 此屬性的格式為：fsverity_digest=DigestName:HexadecimalStringfsverity_digest 支援的 DigestNames 為 [6]
sha256
sha512
fsverity_signature¶
此屬性用於授權所有已透過 fs-verity 內建簽名機制驗證的啟用 fs-verity 的檔案。 簽名驗證依賴於儲存在 “.fs-verity” 金鑰環中的金鑰。 它依賴於
FS_VERITY_BUILTIN_SIGNATURES配置選項，並由IPE_PROP_FS_VERITY配置選項控制，當SECURITY_IPE、FS_VERITY和FS_VERITY_BUILTIN_SIGNATURES都啟用時，它將自動選擇。 此屬性的格式為：fsverity_signature=(TRUE|FALSE)
策略示例¶
允許所有¶
policy_name=Allow_All policy_version=0.0.0
DEFAULT action=ALLOW
僅允許 initramfs¶
policy_name=Allow_Initramfs policy_version=0.0.0
DEFAULT action=DENY
op=EXECUTE boot_verified=TRUE action=ALLOW
允許任何已簽名並驗證的 dm-verity 卷和 initramfs¶
policy_name=Allow_Signed_DMV_And_Initramfs policy_version=0.0.0
DEFAULT action=DENY
op=EXECUTE boot_verified=TRUE action=ALLOW
op=EXECUTE dmverity_signature=TRUE action=ALLOW
禁止從特定的 dm-verity 卷執行¶
policy_name=Deny_DMV_By_Roothash policy_version=0.0.0
DEFAULT action=DENY
op=EXECUTE dmverity_roothash=sha256:cd2c5bae7c6c579edaae4353049d58eb5f2e8be0244bf05345bc8e5ed257baff action=DENY
op=EXECUTE boot_verified=TRUE action=ALLOW
op=EXECUTE dmverity_signature=TRUE action=ALLOW
僅允許特定的 dm-verity 卷¶
policy_name=Allow_DMV_By_Roothash policy_version=0.0.0
DEFAULT action=DENY
op=EXECUTE dmverity_roothash=sha256:401fcec5944823ae12f62726e8184407a5fa9599783f030dec146938 action=ALLOW
允許任何具有有效內建簽名的 fs-verity 檔案¶
policy_name=Allow_Signed_And_Validated_FSVerity policy_version=0.0.0
DEFAULT action=DENY
op=EXECUTE fsverity_signature=TRUE action=ALLOW
允許執行特定的 fs-verity 檔案¶
policy_name=ALLOW_FSV_By_Digest policy_version=0.0.0
DEFAULT action=DENY
op=EXECUTE fsverity_digest=sha256:fd88f2b8824e197f850bf4c5109bea5cf0ee38104f710843bb72da796ba5af9e action=ALLOW
附加資訊¶
FAQ¶
- Q
與其他提供基於信任的訪問控制措施的 LSM 有什麼區別？
A
通常，還有另外兩個 LSM 可以提供類似的功能：IMA 和 Loadpin。
IMA 和 IPE 在功能上非常相似。 兩者之間的顯著區別在於策略。 [3]
Loadpin 和 IPE 的區別非常大，因為 Loadpin 僅涵蓋 IPE 的核心讀取操作，而 IPE 能夠控制核心讀取之上的執行。 信任模型也不同。 Loadpin 將其信任植根於初始超級塊，而 IPE 的信任則源於核心本身（透過
SYSTEM_TRUSTED_KEYS）。