完整性策略执行 (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）。