完整性策略执行 (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 最适合固定功能的设备:其用途明确定义且不应更改的设备(例如数据中心中的网络防火墙设备、物联网设备等),其中所有软件和配置均由系统所有者构建和配置。
IPE 离在通用计算中使用还很遥远:整个 Linux 社区倾向于遵循分散的信任模型(称为信任网络),IPE 目前不支持此模型。相反,IPE 支持 PKI(公钥基础设施),它通常指定一组提供绝对信任度量的受信任实体。
此外,虽然今天大多数软件包都已签名,但软件包内部的文件(例如,可执行文件)往往是未签名的。这使得在期望软件包管理器正常运行的系统中难以利用 IPE,而无需对软件包管理器及其背后的生态系统进行重大更改。
digest_cache LSM [1] 是一个系统,当与 IPE 结合使用时,可以用于启用和支持通用计算用例。
已知限制¶
IPE 无法验证匿名可执行内存的完整性,例如 gcc 闭包和 libffi(<3.4.2)创建的蹦床,或 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
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 |
整数 |
否 |
审计操作的结果(成功/失败) |
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
:通过 Kconfigs、
CONFIG_IMA_X509_PATH
和CONFIG_EVM_X509_PATH
控制加载 IMA 证书。
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 卷,这些卷通过其根哈希值标识。它依赖于 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¶
此属性可用于授权所有 dm-verity 卷,这些卷具有由 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
其他信息¶
常见问题解答¶
- 问
其他提供基于信任的访问控制的 LSM 有什么区别?
答
一般来说,还有两个可以提供类似功能的 LSM:IMA 和 Loadpin。
IMA 和 IPE 在功能上非常相似。两者之间的显著区别在于策略。[3]
Loadpin 和 IPE 的差异非常大,因为 Loadpin 仅涵盖 IPE 的内核读取操作,而 IPE 能够控制内核读取之上的执行。信任模型也不同;Loadpin 将其信任根植于初始超级块,而 IPE 中的信任源于内核本身(通过
SYSTEM_TRUSTED_KEYS
)。