* [PATCH 09/10] docs/zh_CN: add LSM/ipe Chinese translation
From: Yan Zhu @ 2026-06-12 15:58 UTC (permalink / raw)
To: alexs, si.yanteng, corbet, mic
Cc: dzm91, skhan, gnoack, zhuyan2015, linux-doc,
linux-security-module
In-Reply-To: <cover.1781105672.git.zhuyan2015@qq.com>
Translate Documentation/admin-guide/LSM/ipe.rst into Chinese.
Update the translation through commit d7ba853c0e47
("ipe: Update documentation for script enforcement")
Assisted-by: Claude:deepseek-4-pro
Signed-off-by: Yan Zhu <zhuyan2015@qq.com>
---
.../zh_CN/admin-guide/LSM/ipe.rst | 723 ++++++++++++++++++
1 file changed, 723 insertions(+)
create mode 100644 Documentation/translations/zh_CN/admin-guide/LSM/ipe.rst
diff --git a/Documentation/translations/zh_CN/admin-guide/LSM/ipe.rst b/Documentation/translations/zh_CN/admin-guide/LSM/ipe.rst
new file mode 100644
index 000000000000..08af2d03d400
--- /dev/null
+++ b/Documentation/translations/zh_CN/admin-guide/LSM/ipe.rst
@@ -0,0 +1,723 @@
+.. SPDX-License-Identifier: GPL-2.0
+.. include:: ../../disclaimer-zh_CN.rst
+
+:Original: Documentation/admin-guide/LSM/ipe.rst
+:翻译:
+ 朱岩 Yan Zhu <zhuyan2015@qq.com>
+
+==================================
+Integrity Policy Enforcement (IPE)
+==================================
+
+.. NOTE::
+
+ 本文档面向管理员、系统构建者或尝试使用 IPE 的个人。如需面向开发者的 IPE 文
+ 档，请参阅 :doc:`设计文档 </security/ipe>`。
+
+概览
+----
+
+Integrity Policy Enforcement (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，请确保在 :menuselection:`Security --> Integrity Policy
+Enforcement (IPE)` 下的 ``CONFIG_SECURITY_IPE`` 配置选项已打开。
+
+使用场景
+--------
+
+IPE 最适用于固定功能设备：即用途明确定义且不应更改的设备（如数据中心的网络防
+火墙设备、IoT 设备等），其中所有软件和配置均由系统所有者构建和部署。
+
+IPE 在通用计算领域还有很长的路要走：Linux 社区整体倾向于采用去中心化的信任模
+型（即 web of trust），而 IPE 目前尚不支持此模型。相反，IPE 支持 PKI（公钥基
+础设施），通常指定一组受信任的实体来提供一定程度的绝对信任。
+
+此外，虽然当今大多数软件包已经过签名，但包内的文件（例如可执行文件）通常未签
+名。这使得在需要包管理器正常工作的系统中难以利用 IPE，除非对包管理器及其背后
+的生态系统进行重大更改。
+
+digest_cache LSM [#digest_cache_lsm]_ 是一个系统，当与 IPE 结合使用时，可
+用于启用和支持通用计算场景。
+
+已知限制
+--------
+
+IPE 无法验证匿名可执行内存的完整性，例如 gcc 闭包和 libffi (<3.4.2) 创建的跳
+转表，或 JIT 编译的代码。不幸的是，由于这些是动态生成的代码，IPE 无法确保其完
+整性从而形成信任基础。
+
+IPE 无法验证解释型语言的程序完整性，当这些脚本通过以解释器传递程序文件的方式
+被调用时。这是因为解释器执行这些文件的方式所致；脚本本身并不通过 IPE 的任一钩
+子被评估为可执行代码，它们只是作为文本文件被读取（与已编译的可执行文件相对）。
+然而，随着 ``AT_EXECVE_CHECK`` 标志的引入
+(:doc:`AT_EXECVE_CHECK </userspace-api/check_exec>`)，解释器可以使用它来通知
+内核一个脚本文件即将被执行，并请求内核对其执行 LSM 安全检查。
+
+IPE 的 EXECUTE 操作执行策略在已编译可执行文件和解释型脚本之间有所不同：对于已
+编译可执行文件，执行检查在内核执行 ``execve()``、``execveat()``、``mmap()``
+和 ``mprotect()`` 系统调用加载可执行内容时自动触发。对于解释型脚本，执行检查
+需要解释器显式集成，使用带 ``AT_EXECVE_CHECK`` 标志的 ``execveat()``。与 IPE
+在执行过程中拦截的 exec 系统调用不同，这一机制需要解释器主动配合，除非加入信
+号调用，否则现有解释器不会自动获得支持。
+
+威胁模型
+--------
+
+IPE 专门针对内核初始引导后用户空间可执行代码被篡改的风险，包括通过
+``modprobe`` 或 ``insmod`` 从用户空间加载的内核模块。
+
+举例说明，设想一个场景：一个不受信任的二进制文件（可能是恶意的）连同各种必要
+的依赖项（包括加载器和 libc）一起被下载。IPE 在此场景中的主要功能是阻止此类二
+进制文件及其依赖项的执行。
+
+IPE 通过在执行前验证所有可执行代码的完整性和真实性来实现这一目标。它进行彻底
+的检查，确保代码的完整性完好无损，并且代码与既定策略中授权的参考值（摘要、签
+名等）匹配。如果二进制文件未通过此验证过程——无论是因其完整性受到破坏还是不符
+合授权条件——IPE 将拒绝其执行。此外，IPE 还会生成审计日志，可用于检测和分析因
+策略违规而导致的失败。
+
+篡改威胁场景包括各类行为者对可执行代码的修改或替换，包括：
+
+- 对硬件有物理访问权限的行为者
+- 对系统有本地网络访问权限的行为者
+- 对部署系统有访问权限的行为者
+- 处于外部控制下的受感染内部系统
+- 系统的恶意终端用户
+- 系统受感染的终端用户
+- 系统的远程（外部）入侵
+
+IPE 不缓解来自恶意但已获授权的开发者（持有签名证书），或其使用的受感染开发工
+具（即面向返回编程攻击）所带来的威胁。此外，IPE 在用户空间与内核空间之间划定
+了硬安全边界。因此，内核级别的漏洞利用被视为IPE 范围之外，应由其他机制来缓解。
+
+策略
+----
+
+IPE 策略是一种纯文本 [#devdoc]_ 格式，由多条分布在多行上的语句组成。策略顶部
+有一行必需的内容，用于指明策略名称和策略版本，例如::
+
+ policy_name=Ex_Policy policy_version=0.0.0
+
+策略名称唯一键值，以人类可读的名称标识该策略。它用于在 securityfs 下创建节点，
+以及唯一标识策略以部署新策略或更新现有策略。
+
+策略版本表示策略的当前版本（**非** 策略语法版本）。用于防止将策略回滚到可能不
+安全的旧版本。
+
+IPE 策略的下一部分是规则。规则由 ``key=value`` 对组成，称为属性。IPE 规则需
+要两个属性：``action`` 决定了 IPE 在匹配到该规则时的行为，以及 ``op`` 决定了
+该规则何时应该被评估。顺序很重要，规则必须以 ``op`` 开头，以 ``action`` 结尾。
+因此，最小规则是::
+
+ op=EXECUTE action=ALLOW
+
+此示例将允许任何执行。其他属性用于评估被评估文件的不可变安全属性。这些属性旨
+在描述内核中能够提供完整性验证度量的系统，使得 IPE 能够根据属性的取值来判断资
+源的可信度。
+
+规则从上到下进行评估。因此，任何撤销规则或拒绝规则应放在文件的较早位置，以确
+保这些规则在带有 ``action=ALLOW`` 的规则之前被评估。
+
+IPE 策略支持注释。字符 '#' 起到注释的作用，忽略 '#' 右侧直到换行符之前的所有
+字符。
+
+IPE 评估的默认行为也可以通过 ``DEFAULT`` 语句在策略中表达。可以在全局级别或
+按操作级别设置::
+
+ # 全局
+ DEFAULT action=ALLOW
+
+ # 按操作级别
+ DEFAULT op=EXECUTE action=ALLOW
+
+必须为 IPE 中所有已知操作设置默认值。如果您希望保留旧策略与新内核的兼容性（新
+内核可能引入新操作），可以设置 ``ALLOW`` 的全局默认值，然后在每个操作的基础上
+覆盖默认值（如上所示）。
+
+对于基于可配置策略的 LSM，在启动时实施可配置策略存在若干问题，围绕策略的读取
+和解析：
+
+1. 内核 **不应** 从用户空间读取文件，因此直接读取策略文件是被禁止的。
+2. 内核命令行有字符长度限制，一个内核模块不应为自身配置占用整个字符限制。
+3. 内核生态系统中存在各种引导加载程序，因此通过传递内存块的方式成本高昂，难以
+ 维护。
+
+为此，IPE 通过 "boot policy" 的概念来解决这个问题。启动策略是一份编译进内核
+的最小策略。该策略旨在将系统引导至用户空间已设置好并可以接收命令的状态，届时
+可以通过 securityfs 部署更复杂的策略。启动策略可以通过
+``SECURITY_IPE_BOOT_POLICY`` 配置选项指定，该选项接受要应用的 IPE 策略纯文本
+版本的路径。此策略将被编译进内核。如果未指定，IPE 将保持禁用状态，直到通过
+securityfs 部署并激活策略。
+
+部署策略
+~~~~~~~~
+
+策略可以通过 securityfs 从用户空间部署。这些策略通过 PKCS#7 消息格式进行签名，
+以实施某种程度的策略授权（防止攻击者获得无限制的 root 权限并部署 "allow all"
+策略）。这些策略必须由可链至 ``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"
+
+删除策略只有一个要求：被删除的策略必须处于非活动状态。
+
+.. NOTE::
+
+ 如果启用了传统 MAC 系统（SELinux、apparmor、smack），所有对 IPE
+ securityfs 节点的写入都需要 ``CAP_MAC_ADMIN``。
+
+模式
+~~~~
+
+IPE 支持两种操作模式：宽松模式（permissive，类似 SELinux 的 permissive 模式）
+和强制模式（enforced）。在宽松模式下，所有事件都会被检查，策略违规会被记录，
+但策略不会真正被强制执行。这允许用户在强制执行之前先测试策略。
+
+默认模式为强制模式（enforce），可以通过内核命令行参数 ``ipe.enforce=(0|1)``
+或 securityfs 节点 ``/sys/kernel/security/ipe/enforce`` 进行更改。
+
+.. NOTE::
+
+ 如果启用了传统 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`` 记录一起发出。
+
+可以通过 ``AUDITSYSCALL`` 记录的 ``success`` 属性和退出码来判断 IPE 处于宽松
+模式还是强制模式。
+
+字段说明:
+
++-----------+----------+--------+--------------------------------------------+
+| 字段 | 值类型 | 可选? | 值说明 |
++===========+==========+========+============================================+
+| ipe_op | string | 否 | 与日志关联的 IPE 操作名称 |
++-----------+----------+--------+--------------------------------------------+
+| ipe_hook | string | 否 | 触发 IPE 事件的 LSM 钩子名称 |
++-----------+----------+--------+--------------------------------------------+
+| enforcing | integer | 否 | 当前 IPE 强制执行状态,1:强制模式,0:宽松模式|
++-----------+----------+--------+--------------------------------------------+
+| pid | integer | 否 | 触发 IPE 事件的进程 PID |
++-----------+----------+--------+--------------------------------------------+
+| comm | string | 否 | 触发 IPE 事件的进程命令行程序名 |
++-----------+----------+--------+--------------------------------------------+
+| path | string | 是 | 被评估文件的绝对路径 |
++-----------+----------+--------+--------------------------------------------+
+| ino | integer | 是 | 被评估文件的 inode 号 |
++-----------+----------+--------+--------------------------------------------+
+| dev | string | 是 | 被评估文件的设备名,如 vda |
++-----------+----------+--------+--------------------------------------------+
+| rule | string | 否 | 匹配的策略规则 |
++-----------+----------+--------+--------------------------------------------+
+
+
+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 | string | 是 | 前一个活动策略的名 |
++------------------------+-----------+--------+----------------------------+
+| old_active_pol_version | string | 是 | 前一个活动策略的版本 |
++------------------------+-----------+--------+----------------------------+
+| old_policy_digest | string | 是 | 前一个活动策略的哈希值 |
++------------------------+-----------+--------+----------------------------+
+| new_active_pol_name | string | 否 | 当前活动策略的名称 |
++------------------------+-----------+--------+----------------------------+
+| new_active_pol_version | string | 否 | 当前活动策略的版本 |
++------------------------+-----------+--------+----------------------------+
+| new_policy_digest | string | 否 | 当前活动策略的哈希值 |
++------------------------+-----------+--------+----------------------------+
+| auid | integer | 否 | 登录用户 ID |
++------------------------+-----------+--------+----------------------------+
+| ses | integer | 否 | 登录会话 ID |
++------------------------+-----------+--------+----------------------------+
+| lsm | string | 否 | 与该事件关联的 LSM 名称 |
++------------------------+-----------+--------+----------------------------+
+| res | integer | 否 | 审计操作的结果（成功/失败）|
++------------------------+-----------+--------+----------------------------+
+
+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 | string | 是 | 策略名称 |
++----------------+-----------+--------+-----------------------------------+
+| policy_version | string | 是 | 策略版本 |
++----------------+-----------+--------+-----------------------------------+
+| policy_digest | string | 是 | 策略哈希 |
++----------------+-----------+--------+-----------------------------------+
+| auid | integer | 否 | 登录用户 ID |
++----------------+-----------+--------+-----------------------------------+
+| ses | integer | 否 | 登录会话 ID |
++----------------+-----------+--------+-----------------------------------+
+| lsm | string | 否 | 与该事件关联的 LSM 名称 |
++----------------+-----------+--------+-----------------------------------+
+| res | integer | 否 | 审计操作的结果（成功/失败） |
++----------------+-----------+--------+-----------------------------------+
+| errno | integer | 否 | 策略加载操作的错误码（见下表） |
++----------------+-----------+--------+-----------------------------------+
+
+策略错误码 (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 | integer | 否 | IPE 切换到的强制执行状态,1:强制模式,0:宽松模式 |
++--------------+-----------+--------+-------------------------------------------------------+
+| old_enforcing| integer | 否 | IPE 切换前的强制执行状态,1:强制模式,0:宽松模式 |
++--------------+-----------+--------+-------------------------------------------------------+
+| auid | integer | 否 | 登录用户 ID |
++--------------+-----------+--------+-------------------------------------------------------+
+| ses | integer | 否 | 登录会话 ID |
++--------------+-----------+--------+-------------------------------------------------------+
+| enabled | integer | 否 | 新的 TTY 审计启用设置 |
++--------------+-----------+--------+-------------------------------------------------------+
+| old-enabled | integer | 否 | 旧的 TTY 审计启用设置 |
++--------------+-----------+--------+-------------------------------------------------------+
+| lsm | string | 否 | 与该事件关联的 LSM 名称 |
++--------------+-----------+--------+-------------------------------------------------------+
+| res | integer | 否 | 审计操作的结果（成功/失败） |
++--------------+-----------+--------+-------------------------------------------------------+
+
+
+成功审计
+^^^^^^^^
+
+IPE 支持成功审计。启用后，所有通过 IPE 策略且未被阻止的事件都将生成审计事件。
+此功能默认关闭，可以通过内核命令行参数 ``ipe.success_audit=(0|1)`` 或
+securityfs 文件 ``/sys/kernel/security/ipe/success_audit`` 启用。
+
+这会产生 **大量** 日志，因为 IPE 会检查系统上的每一个用户空间二进制文件，但
+在调试策略时非常有用。
+
+.. NOTE::
+
+ 如果启用了传统 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 选项 ``CONFIG_IMA_X509_PATH`` 和
+ ``CONFIG_EVM_X509_PATH`` 控制 IMA 证书的加载。
+
+action
+~~~~~~
+
+ 决定 IPE 在规则匹配时的行为。必须作为最后一条子句出现在每条规则中。可以取
+ 以下值：
+
+ ``ALLOW``:
+
+ 如果规则匹配，显式允许访问资源并继续执行，不再评估后续规则。
+
+ ``DENY``:
+
+ 如果规则匹配，显式禁止访问资源并停止执行，不再评估后续规则。
+
+boot_verified
+~~~~~~~~~~~~~
+
+ 此属性可用于对来自 initramfs 的文件进行授权。
+ 此属性的格式是::
+
+ boot_verified=(TRUE|FALSE)
+
+ .. WARNING::
+
+ 此属性将信任来自 initramfs(rootfs) 的文件。它应仅在早期引导阶段使用。
+ 在实际根文件系统挂载到 initramfs 之上之前，initramfs 脚本将递归删除
+ initramfs 上的所有文件和目录。这通常通过使用
+ switch_root(8) [#switch_root]_ 来实现。因此在实际根文件系统接管后，
+ initramfs 将为空且不可访问。建议在此之后切换到不依赖该属性的其他策略。
+ 这样可以确保信任策略在整个系统运行期间保持相关和有效。
+
+dmverity_roothash
+~~~~~~~~~~~~~~~~~
+
+ 此属性可用于授权或撤销特定的 dm-verity 卷，通过其根哈希进行标识。它依赖于
+ DM_VERITY 模块。此属性由 ``IPE_PROP_DM_VERITY`` 配置选项控制，当
+ ``SECURITY_IPE`` 和 ``DM_VERITY`` 都启用时它将自动被选中。
+ 此属性的格式是::
+
+ dmverity_roothash=DigestName:HexadecimalString
+
+ dmverity_roothash 支持的 DigestName 有 [#dmveritydigests]_
+
+ + blake2b-512
+ + blake2s-256
+ + sha256
+ + sha384
+ + sha512
+ + sha3-224
+ + sha3-256
+ + sha3-384
+ + sha3-512
+ + sm3
+ + rmd160
+
+dmverity_signature
+~~~~~~~~~~~~~~~~~~
+
+ 此属性可用于授权所有具有已签名 roothash 的 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:HexadecimalString
+
+ fsverity_digest 支持的 DigestName 有 [#fsveritydigest]_
+
+ + 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
+
+附加信息
+--------
+
+- `Github 仓库 <https://github.com/microsoft/ipe>`_
+- :doc:`IPE 开发者和设计文档 </security/ipe>`
+
+FAQ
+---
+
+Q:
+ IPE 与其他提供基于信任的访问控制的 LSM 有什么区别？
+
+A:
+
+ 一般而言，另外有两种 LSM 可以提供类似的功能：IMA 和 Loadpin。
+
+ IMA 和 IPE 在功能上非常相似。两者之间的显著区别在于策略。 [#devdoc]_
+
+ Loadpin 与 IPE 差异相当大，因为 Loadpin 只覆盖了 IPE 的内核读取操作，而
+ IPE 除了内核读取外还能控制执行。信任模型也不同；Loadpin 的信任根植于初始
+ 超级块，而 IPE 的信任来源于内核自身（通过 ``SYSTEM_TRUSTED_KEYS``）。
+
+------------
+
+.. [#digest_cache_lsm] https://lore.kernel.org/lkml/20240415142436.2545003-1-roberto.sassu@huaweicloud.com/
+
+.. [#devdoc] 关于此主题的更多信息，请参阅 :doc:`设计文档 </security/ipe>`。
+
+.. [#switch_root] https://man7.org/linux/man-pages/man8/switch_root.8.html
+
+.. [#dmveritydigests] 这些哈希算法基于 Linux 加密 API 接受的值；IPE 不限制摘
+ 要算法本身；因此，此列表可能不是最新的。
+
+.. [#fsveritydigest] 这些哈希算法基于内核 fsverity 支持接受的值；IPE 不限制
+ 摘要算法本身；因此，此列表可能不是最新的。
--
2.43.0
^ permalink raw reply related
* [PATCH 10/10] docs/zh_CN: add LSM/landlock Chinese translation
From: Yan Zhu @ 2026-06-12 15:58 UTC (permalink / raw)
To: alexs, si.yanteng, corbet, mic
Cc: dzm91, skhan, gnoack, zhuyan2015, linux-doc,
linux-security-module
In-Reply-To: <cover.1781105672.git.zhuyan2015@qq.com>
Translate Documentation/admin-guide/LSM/landlock.rst into Chinese.
Update the translation through commit de4b09abf088
("landlock: Document audit blocker field format")
Assisted-by: Claude:deepseek-4-pro
Signed-off-by: Yan Zhu <zhuyan2015@qq.com>
---
.../zh_CN/admin-guide/LSM/landlock.rst | 169 ++++++++++++++++++
1 file changed, 169 insertions(+)
create mode 100644 Documentation/translations/zh_CN/admin-guide/LSM/landlock.rst
diff --git a/Documentation/translations/zh_CN/admin-guide/LSM/landlock.rst b/Documentation/translations/zh_CN/admin-guide/LSM/landlock.rst
new file mode 100644
index 000000000000..7c465ce1c774
--- /dev/null
+++ b/Documentation/translations/zh_CN/admin-guide/LSM/landlock.rst
@@ -0,0 +1,169 @@
+.. SPDX-License-Identifier: GPL-2.0
+.. Copyright © 2025 Microsoft Corporation
+.. include:: ../../disclaimer-zh_CN.rst
+
+:Original: Documentation/admin-guide/LSM/landlock.rst
+:翻译:
+ 朱岩 Yan Zhu <zhuyan2015@qq.com>
+
+
+========================
+Landlock：系统范围的管理
+========================
+
+:Author: Mickaël Salaün
+:Date: 2026年1月
+
+Landlock 可以利用审计框架记录事件。
+
+用户空间文档位于：Documentation/userspace-api/landlock.rst。
+
+审计
+====
+
+默认情况下，若启用了 ``audit``，沙箱程序的被拒访问请求会被记录。此默认行为可
+通过 ``sys_landlock_restrict_self()`` 标志更改（参见
+Documentation/userspace-api/landlock.rst）。审计规则也可以屏蔽 Landlock 日志。
+Landlock 能生成两种审计记录类型。
+
+记录类型
+--------
+
+AUDIT_LANDLOCK_ACCESS
+ 此记录标识对内核资源的拒绝访问请求。``domain`` 字段指示阻止该请求的
+ 域 ID。``blockers`` 字段列出导致拒绝的原因（逗号分隔），随后字段标识
+ 内核对象（类似 SELinux）。一次审计事件可能出现多个此类记录。
+
+ 示例：同一事件中两条文件链接请求记录::
+
+ domain=195ba459b blockers=fs.refer path="/usr/bin" dev="vda2" ino=351
+ domain=195ba459b blockers=fs.make_reg,fs.refer path="/usr/local" dev="vda2" ino=365
+
+ ``blockers`` 字段使用点分前缀标识限制类型：
+
+ **fs.*** – 文件系统访问权（ABI 1+）:
+ - fs.execute, fs.write_file, fs.read_file, fs.read_dir
+ - fs.remove_dir, fs.remove_file
+ - fs.make_char, fs.make_dir, fs.make_reg, fs.make_sock
+ - fs.make_fifo, fs.make_block, fs.make_sym
+ - fs.refer (ABI 2+)
+ - fs.truncate (ABI 3+)
+ - fs.ioctl_dev (ABI 5+)
+
+ **net.*** – 网络访问权（ABI 4+）:
+ - net.bind_tcp – TCP 端口绑定被拒绝
+ - net.connect_tcp – TCP 连接被拒绝
+
+ **scope.*** – IPC 范围限制（ABI 6+）:
+ - scope.abstract_unix_socket – 抽象 UNIX 套接字连接被拒绝
+ - scope.signal – 信号发送被拒绝
+
+ 当多个访问权缺失时，可出现多个 ``blockers``（逗号分隔），例如缺少
+ ``make_reg`` 与 ``refer`` 权限时会显示 ``blockers=fs.make_reg,fs.refer``。
+
+ 对象标识字段（路径、设备、inode 等）根据被阻止的访问类型提供上下文信息。
+
+AUDIT_LANDLOCK_DOMAIN
+ 此记录描述 Landlock 域的状态。``status`` 字段为 ``allocated`` 或
+ ``deallocated``。
+
+ ``allocated`` 状态随同首条 ``AUDIT_LANDLOCK_ACCESS`` 记录出现，
+ 提供以下信息：
+
+ - 域 ID（``domain``）
+ - 强制模式（``mode``）
+ - 创建域的 PID（``pid``）
+ - 创建域的 UID（``uid``）
+ - 创建域的可执行路径（``exe``）
+ - 创建域的命令行（``comm``）
+
+ 示例::
+
+ domain=195ba459b status=allocated mode=enforcing pid=300 uid=0 ...
+
+ ``deallocated`` 为单独事件，表示域释放。此后该域 ID 不会在系统生命周期中
+ 再次使用。``deallocated`` 记录包含域 ID 与 ``denials`` 字段，后者统计该
+ 域被拒绝的请求数。
+
+ 示例::
+
+ domain=195ba459b status=deallocated denials=3
+
+事件示例
+--------
+
+以下为两组审计日志示例（含序列号）。
+
+示例 1：沙箱程序 ``kill`` 试图向 init 进程发送信号，
+被 ``scope.signal`` 限制拒绝::
+
+ $ LL_FS_RO=/ LL_FS_RW=/ LL_SCOPED=s LL_FORCE_LOG=1 ./sandboxer kill 1
+
+此命令生成两个事件，每个事件都由一个时间戳后跟一个唯一的序列号标识
+（``msg=audit(1729738800.268:30)``）。第一个事件（序列号为“30”）包含 4 条记
+录。第一条记录（``type=LANDLOCK_ACCESS``）显示域 `1a6fdc66f` 拒绝了访问。拒
+绝的原因是信号范围限制（``blockers=scope.signal``）。本应接收此信号的进程是
+init 进程（``opid=1 ocomm="systemd"``）。
+
+第二个记录（``type=LANDLOCK_DOMAIN``） 描述了（``status=allocated``）域
+`1a6fdc66f`。此域由进程 ``286`` 创建，该进程执行了由 root 用户启动的
+`/root/sandboxer` 程序。
+
+第三个记录（``type=SYSCALL``）描述了系统调用、其提供的参数、其结果
+``success=no exit=-1`` 以及调用它的进程。
+
+第四个记录（``type=PROCTITLE``）以十六进制值的形式显示命令名称。这可以通过执
+行 ``python -c 'print(bytes.fromhex("6B696C6C0031"))'`` 进行转换。
+
+最后一条记录（``type=LANDLOCK_DOMAIN``）也是第二个事件（序列号“31”）中的唯一
+一条记录。它并非与直接的用户空间操作相关，而是异步操作以释放与 Landlock 域相
+关的资源（``status=deallocated``）。这有助于了解后续的日志将不再涉及域
+`1a6fdc66f`。此记录还总结了该域拒绝的请求数量（``denials=1``），以及这些请求
+是否被记录。
+
+
+.. code-block::
+
+ type=LANDLOCK_ACCESS msg=audit(1729738800.268:30): domain=1a6fdc66f blockers=scope.signal opid=1 ocomm="systemd"
+ type=LANDLOCK_DOMAIN msg=audit(1729738800.268:30): domain=1a6fdc66f status=allocated mode=enforcing pid=286 uid=0 exe="/root/sandboxer" comm="sandboxer"
+ type=SYSCALL msg=audit(1729738800.268:30): arch=c000003e syscall=62 success=no exit=-1 [..] ppid=272 pid=286 auid=0 uid=0 gid=0 [...] comm="kill" [...]
+ type=PROCTITLE msg=audit(1729738800.268:30): proctitle=6B696C6C0031
+ type=LANDLOCK_DOMAIN msg=audit(1729738800.324:31): domain=1a6fdc66f status=deallocated denials=1
+
+
+示例 2：文件系统访问控制示例::
+
+ $ LL_FS_RO=/ LL_FS_RW=/tmp LL_FORCE_LOG=1 ./sandboxer sh -c "echo > /etc/passwd"
+
+相关的审计日志包含由同一个域 `1a6fdc679` 创建的 3 个不同事件（序列号 33、34
+和 35）的 8 条记录::
+
+ type=LANDLOCK_ACCESS msg=audit(1729738800.221:33): domain=1a6fdc679 blockers=fs.write_file path="/dev/tty" dev="devtmpfs" ino=9
+ type=LANDLOCK_DOMAIN msg=audit(1729738800.221:33): domain=1a6fdc679 status=allocated mode=enforcing pid=289 uid=0 exe="/root/sandboxer" comm="sandboxer"
+ type=SYSCALL msg=audit(1729738800.221:33): arch=c000003e syscall=257 success=no exit=-13 [...] ppid=272 pid=289 auid=0 uid=0 gid=0 [...] comm="sh" [...]
+ type=PROCTITLE msg=audit(1729738800.221:33): proctitle=7368002D63006563686F203E202F6574632F706173737764
+ type=LANDLOCK_ACCESS msg=audit(1729738800.221:34): domain=1a6fdc679 blockers=fs.write_file path="/etc/passwd" dev="vda2" ino=143821
+ type=SYSCALL msg=audit(1729738800.221:34): arch=c000003e syscall=257 success=no exit=-13 [...] ppid=272 pid=289 auid=0 uid=0 gid=0 [...] comm="sh" [...]
+ type=PROCTITLE msg=audit(1729738800.221:34): proctitle=7368002D63006563686F203E202F6574632F706173737764
+ type=LANDLOCK_DOMAIN msg=audit(1729738800.261:35): domain=1a6fdc679 status=deallocated denials=2
+
+
+过滤审计日志
+------------
+
+如果审计日志数量过多，可通过以下两种方式过滤噪声：
+
+- 使用 ``sys_landlock_restrict_self()`` 的标志对沙箱程序进行配置；
+- 或使用审计规则（参见 :manpage:`auditctl(8)`）过滤。
+
+补充文档
+--------
+
+* `Linux Audit Documentation`_
+* Documentation/userspace-api/landlock.rst
+* Documentation/security/landlock.rst
+* https://landlock.io
+
+.. 链接
+.. _Linux Audit Documentation:
+ https://github.com/linux-audit/audit-documentation/wiki
--
2.43.0
^ permalink raw reply related
* [PATCH 03/10] docs/zh_CN: add LSM/LoadPin Chinese translation
From: Yan Zhu @ 2026-06-12 15:58 UTC (permalink / raw)
To: alexs, si.yanteng, corbet, mic
Cc: dzm91, skhan, gnoack, zhuyan2015, linux-doc,
linux-security-module
In-Reply-To: <cover.1781105672.git.zhuyan2015@qq.com>
Translate Documentation/admin-guide/LSM/LoadPin.rst into Chinese.
Update the translation through commit 0860b72d535f
("security/loadpin: Update the changing interface in the source code.")
Assisted-by: Claude:deepseek-4-pro
Signed-off-by: Yan Zhu <zhuyan2015@qq.com>
---
.../zh_CN/admin-guide/LSM/LoadPin.rst | 33 +++++++++++++++++++
1 file changed, 33 insertions(+)
create mode 100644 Documentation/translations/zh_CN/admin-guide/LSM/LoadPin.rst
diff --git a/Documentation/translations/zh_CN/admin-guide/LSM/LoadPin.rst b/Documentation/translations/zh_CN/admin-guide/LSM/LoadPin.rst
new file mode 100644
index 000000000000..d75a06f515f6
--- /dev/null
+++ b/Documentation/translations/zh_CN/admin-guide/LSM/LoadPin.rst
@@ -0,0 +1,33 @@
+.. SPDX-License-Identifier: GPL-2.0
+.. include:: ../../disclaimer-zh_CN.rst
+
+:Original: Documentation/admin-guide/LSM/LoadPin.rst
+:翻译:
+ 朱岩 Yan Zhu <zhuyan2015@qq.com>
+
+
+=======
+LoadPin
+=======
+
+LoadPin 是一种 Linux 安全模块（LSM），保证所有内核加载的文件（模块、固件等）
+均来自同一文件系统，并且该文件系统应当以只读设备（如 dm-verity 或 CDROM）为后
+端存储。这使得在拥有经过验证和/或不可更改的文件系统的系统上，能够在不对每个文
+件单独签名的前提下，强制模块和固件的加载限制。
+
+该 LSM 在编译时通过 ``CONFIG_SECURITY_LOADPIN`` 进行选择，并且可以在启动时通
+过内核命令行参数 ``loadpin.enforce`` 进行控制。默认情况下该功能是启用的，亦可
+在启动时通过 ``loadpin.enforce=0`` 将其关闭。
+
+LoadPin 会在检测到首个文件被加载时开始生效。如果承载该文件系统的块设备不是只
+读的，系统会创建一个 sysctl 条目 ``/proc/sys/kernel/loadpin/enabled`` 用于切
+换锁定功能。可写的文件系统意味着锁定功能亦可被修改，但通过 sysctl 可以在可
+写文件系统上便捷地进行测试。
+
+也可以使用内核命令行参数 ``loadpin.exclude`` 将特定文件类型从 LoadPin 中排除。
+默认情况下所有文件均被包含，但可以通过
+``loadpin.exclude=kernel-module,kexec-image`` 等方式排除相应类型。这允许在使
+用 ``CONFIG_MODULE_SIG``、``CONFIG_KEXEC_VERIFY_SIG`` 等机制对内核模块和内核
+镜像进行校验的同时，仍然利用 LoadPin 保护其他内核加载文件的完整性。有效文件类
+型的完整列表可在 ``include/linux/kernel_read_file.h`` 中的
+``kernel_read_file_str`` 找到。
--
2.43.0
^ permalink raw reply related
* [PATCH 08/10] docs/zh_CN: add LSM/SafeSetID Chinese translation
From: Yan Zhu @ 2026-06-12 15:58 UTC (permalink / raw)
To: alexs, si.yanteng, corbet, mic
Cc: dzm91, skhan, gnoack, zhuyan2015, linux-doc,
linux-security-module
In-Reply-To: <cover.1781105672.git.zhuyan2015@qq.com>
Translate Documentation/admin-guide/LSM/SafeSetID.rst into Chinese.
Update the translation through commit c34921670736
("Documentation: Fix admin-guide typos")
Assisted-by: Claude:deepseek-4-pro
Signed-off-by: Yan Zhu <zhuyan2015@qq.com>
---
.../zh_CN/admin-guide/LSM/SafeSetID.rst | 82 +++++++++++++++++++
1 file changed, 82 insertions(+)
create mode 100644 Documentation/translations/zh_CN/admin-guide/LSM/SafeSetID.rst
diff --git a/Documentation/translations/zh_CN/admin-guide/LSM/SafeSetID.rst b/Documentation/translations/zh_CN/admin-guide/LSM/SafeSetID.rst
new file mode 100644
index 000000000000..3f96df3ed776
--- /dev/null
+++ b/Documentation/translations/zh_CN/admin-guide/LSM/SafeSetID.rst
@@ -0,0 +1,82 @@
+.. SPDX-License-Identifier: GPL-2.0
+.. include:: ../../disclaimer-zh_CN.rst
+
+:Original: Documentation/admin-guide/LSM/SafeSetID.rst
+:翻译:
+ 朱岩 Yan Zhu <zhuyan2015@qq.com>
+
+
+=========
+SafeSetID
+=========
+
+SafeSetID 是一个 LSM 模块，用于对 setid 系列系统调用进行门控，限制 UID/GID
+的转变只能在系统范围的白名单中批准的 UID/GID 之间进行。这些限制还禁止给定的
+UID/GID 获得与 ``CAP_SET{U/G}ID`` 关联的辅助特权，例如允许用户设置用户命名空
+间的 UID/GID 映射。
+
+背景
+====
+在缺少文件能力的情况下，需要切换到其他用户的进程必须具备 ``CAP_SETUID`` 权限。
+``CAP_SETUID`` 只授予以 root 身份运行的程序或显式获得 ``CAP_SETUID`` 运行时
+能力的非 root 程序。相较于文件能力，通常更推荐使用 Linux 运行时能力，因为使
+用文件能力以提升的权限运行程序会带来潜在的安全风险——任何拥有该文件访问权限的
+用户都可以通过 ``exec()`` 运行该程序来获得提升的特权。
+
+虽然可以通过为完整的 ``CAP_SET{U/G}ID`` 能力给进程树授予权限来实现，但这与在
+非 root 用户下运行进程树的目标相冲突。尤其 ``CAP_SETUID`` 允许切换到系统上任
+何用户，包括 root，这在很多场景中过于强大。实际中多数程序仅调用 ``setuid()``
+降低特权，而非提升特权。Linux 并未提供通用机制限制用户通过 ``setuid()`` 能切
+换到的 UID 范围，除非允许其切换到系统上任意用户。SafeSetID LSM 正是为了解决
+这一问题。
+
+主要使用场景是允许非 root 程序在不拥有完整 ``CAP_SETUID`` 能力的情况下，安全
+地切换到其他非受信任的 UID。该非 root 程序仍需 ``CAP_SETUID`` 才能执行任何转
+变，但SafeSetID 施加的额外限制，使其成为 ``CAP_SETUID`` 的“安全版”，防止其进
+行未授权操作（如切换到 UID 0 或创建/进入新的用户命名空间）。这为系统服务提供
+基于UID 的沙箱化提供了可能，而无需在大量非 root 程序上分配完整的
+``CAP_SETUID``。
+
+其他已考虑的方案
+================
+
+在用户空间解决此问题
+--------------------
+可以通过在用户空间完全移除 setid 能力并使用特权帮助程序来完成进程的 UID/GID
+转换。然而，这会影响大量与进程生成相关的语义，如 ``fork()`` 后不立即
+``exec()`` 的行为、父进程自定义环境变量或命令行参数、以及文件句柄跨
+``fork()/exec()`` 的继承等。因此，此类方案对依赖特定进程生成语义的现有项目
+支持度较低。
+
+使用用户命名空间
+----------------
+另一种思路是在独立的用户命名空间中运行进程树，并在该命名空间内授予 setid 能力。
+这样，进程可以在自己的命名空间内自由切换 UID/GID，但只能映射到系统范围白名单
+中的 UID/GID。遗憾的是，用户命名空间往往需要与其他命名空间配合使用，例如网络
+或 PID 命名空间，否则会导致失去 ``CAP_NET_ADMIN`` 等关键能力，限制了实际可用
+性。
+
+使用已有 LSM
+------------
+当前树中没有任何其他 LSM 能够对 setid 转换进行门控，也没有实现
+``security_task_fix_setuid`` 钩子。SELinux 对此钩子声明：
+"由于setuid仅影响当前进程，并且由于SELinux的权限控制不基于Linux标识属性。
+因此，SELinux不需要控制此操作。"
+
+使用方法
+========
+SafeSetID 在 ``securityfs`` 中通过写入 ``safesetid/uid_allowlist_policy``
+与 ``safesetid/gid_allowlist_policy`` 文件来配置策略。策略的格式为
+``<UID>:<UID>`` 或 ``<GID>:<GID>``（使用十进制数字），并以换行符结束，例如
+``123:456\n``。写入空字符串 ``""`` 可清空策略。为特定 UID/GID 配置策略后，将
+阻止该 UID/GID 获得 ``CAP_SET{U/G}ID`` 相关的辅助特权，例如设置用户命名空间
+UID/GID 映射。
+
+GID 策略与 ``setgroups()``
+==========================
+在 v5.9 中已加入对 ``CAP_SETGID`` 限制的支持，与之前对 ``CAP_SETUID`` 的处理
+相同。然而，为了兼容用户空间常见的沙箱化代码规范，目前允许具有 ``CAP_SETGID``
+限制的进程调用任意 ``setgroups()``。这意味着在这些 ``setgroups()`` 限制策略
+检查代码就位之前，**当前的 GID 策略并未提供任何有意义的安全保障**。
+``setgroups()`` 的限制将在未来版本中加入策略检查代码后真正生效，该代码将依赖
+于 v5.9 中加入的 GID 策略配置代码。
--
2.43.0
^ permalink raw reply related
* [PATCH 03/10] docs/zh_CN: add LSM/LoadPin Chinese translation
From: Yan Zhu @ 2026-06-12 16:03 UTC (permalink / raw)
To: alexs, si.yanteng, corbet, mic
Cc: dzm91, skhan, gnoack, zhuyan2015, linux-doc,
linux-security-module
In-Reply-To: <cover.1781105672.git.zhuyan2015@qq.com>
Translate Documentation/admin-guide/LSM/LoadPin.rst into Chinese.
Update the translation through commit 0860b72d535f
("security/loadpin: Update the changing interface in the source code.")
Assisted-by: Claude:deepseek-4-pro
Signed-off-by: Yan Zhu <zhuyan2015@qq.com>
---
.../zh_CN/admin-guide/LSM/LoadPin.rst | 33 +++++++++++++++++++
1 file changed, 33 insertions(+)
create mode 100644 Documentation/translations/zh_CN/admin-guide/LSM/LoadPin.rst
diff --git a/Documentation/translations/zh_CN/admin-guide/LSM/LoadPin.rst b/Documentation/translations/zh_CN/admin-guide/LSM/LoadPin.rst
new file mode 100644
index 000000000000..d75a06f515f6
--- /dev/null
+++ b/Documentation/translations/zh_CN/admin-guide/LSM/LoadPin.rst
@@ -0,0 +1,33 @@
+.. SPDX-License-Identifier: GPL-2.0
+.. include:: ../../disclaimer-zh_CN.rst
+
+:Original: Documentation/admin-guide/LSM/LoadPin.rst
+:翻译:
+ 朱岩 Yan Zhu <zhuyan2015@qq.com>
+
+
+=======
+LoadPin
+=======
+
+LoadPin 是一种 Linux 安全模块（LSM），保证所有内核加载的文件（模块、固件等）
+均来自同一文件系统，并且该文件系统应当以只读设备（如 dm-verity 或 CDROM）为后
+端存储。这使得在拥有经过验证和/或不可更改的文件系统的系统上，能够在不对每个文
+件单独签名的前提下，强制模块和固件的加载限制。
+
+该 LSM 在编译时通过 ``CONFIG_SECURITY_LOADPIN`` 进行选择，并且可以在启动时通
+过内核命令行参数 ``loadpin.enforce`` 进行控制。默认情况下该功能是启用的，亦可
+在启动时通过 ``loadpin.enforce=0`` 将其关闭。
+
+LoadPin 会在检测到首个文件被加载时开始生效。如果承载该文件系统的块设备不是只
+读的，系统会创建一个 sysctl 条目 ``/proc/sys/kernel/loadpin/enabled`` 用于切
+换锁定功能。可写的文件系统意味着锁定功能亦可被修改，但通过 sysctl 可以在可
+写文件系统上便捷地进行测试。
+
+也可以使用内核命令行参数 ``loadpin.exclude`` 将特定文件类型从 LoadPin 中排除。
+默认情况下所有文件均被包含，但可以通过
+``loadpin.exclude=kernel-module,kexec-image`` 等方式排除相应类型。这允许在使
+用 ``CONFIG_MODULE_SIG``、``CONFIG_KEXEC_VERIFY_SIG`` 等机制对内核模块和内核
+镜像进行校验的同时，仍然利用 LoadPin 保护其他内核加载文件的完整性。有效文件类
+型的完整列表可在 ``include/linux/kernel_read_file.h`` 中的
+``kernel_read_file_str`` 找到。
--
2.43.0
^ permalink raw reply related
* [PATCH v2] landlock: Set audit_net.sk for socket access checks
From: Mickaël Salaün @ 2026-06-12 17:27 UTC (permalink / raw)
To: Günther Noack
Cc: Mickaël Salaün, linux-security-module, Tingmao Wang,
Matthieu Buffet, stable
Set audit_net.sk in current_check_access_socket() to provide the socket
object to audit_log_lsm_data(). This makes Landlock consistent with
AppArmor, which always sets .sk for socket operations, and with
SELinux's generic socket permission checks.
The socket's local and foreign address information (laddr, lport, faddr,
fport) is logged by the shared lsm_audit.c infrastructure when the
socket has bound or connected state. Fields with zero values are
suppressed by print_ipv4_addr()/print_ipv6_addr(), so the audit output
is unchanged for the common case of bind denials on unbound sockets.
For connect denials after a prior bind, the bound local address (laddr,
lport) appears before the existing sockaddr fields (daddr, dest).
No existing fields are removed or reordered, and the new field names
(laddr, lport, faddr, fport) are standard audit fields already emitted
by other LSMs through the same lsm_audit.c code path.
Add a connect_tcp_bound audit test that binds to an allowed port and
then connects to a denied one, verifying that the denial record reports
laddr/lport from the bound socket in addition to the connect
destination.
Cc: Günther Noack <gnoack@google.com>
Cc: Tingmao Wang <m@maowtm.org>
Cc: stable@vger.kernel.org
Fixes: 9f74411a40ce ("landlock: Log TCP bind and connect denials")
Signed-off-by: Mickaël Salaün <mic@digikod.net>
---
Changes since v1:
https://lore.kernel.org/r/20260406143717.1815792-11-mic@digikod.net
- Move the new socket-audit coverage into the network test fixture,
which sets up an isolated network namespace with a configured
loopback interface; the previous location ran without a network
namespace (reported by Tingmao Wang). Cover the enriched laddr/lport
via a connect-after-bind denial.
---
security/landlock/net.c | 1 +
tools/testing/selftests/landlock/net_test.c | 62 +++++++++++++++++++++
2 files changed, 63 insertions(+)
diff --git a/security/landlock/net.c b/security/landlock/net.c
index c368649985c5..a38bdfcffc22 100644
--- a/security/landlock/net.c
+++ b/security/landlock/net.c
@@ -198,6 +198,7 @@ static int current_check_access_socket(struct socket *const sock,
return 0;
audit_net.family = address->sa_family;
+ audit_net.sk = sock->sk;
landlock_log_denial(subject,
&(struct landlock_request){
.type = LANDLOCK_REQUEST_NET_ACCESS,
diff --git a/tools/testing/selftests/landlock/net_test.c b/tools/testing/selftests/landlock/net_test.c
index 4c528154ea92..0c256e7c8675 100644
--- a/tools/testing/selftests/landlock/net_test.c
+++ b/tools/testing/selftests/landlock/net_test.c
@@ -2026,4 +2026,66 @@ TEST_F(audit, connect)
EXPECT_EQ(0, close(sock_fd));
}
+static int matches_log_tcp_bound(int audit_fd, const char *const addr,
+ __u16 lport, __u16 dport)
+{
+ static const char log_template[] = REGEX_LANDLOCK_PREFIX
+ " blockers=net\\.connect_tcp laddr=%s lport=%u daddr=%s dest=%u$";
+ /* Slack for two addresses and two port numbers. */
+ char log_match[sizeof(log_template) + 40];
+ int log_match_len;
+
+ log_match_len = snprintf(log_match, sizeof(log_match), log_template,
+ addr, lport, addr, dport);
+ if (log_match_len > sizeof(log_match))
+ return -E2BIG;
+
+ return audit_match_record(audit_fd, AUDIT_LANDLOCK_ACCESS, log_match,
+ NULL);
+}
+
+/*
+ * After a bind() to an allowed port, a denied connect must report laddr/lport
+ * from the bound socket (made available through audit_net.sk) in addition to
+ * the connect sockaddr's daddr/dest.
+ */
+TEST_F(audit, connect_tcp_bound)
+{
+ const struct landlock_ruleset_attr ruleset_attr = {
+ .handled_access_net = LANDLOCK_ACCESS_NET_BIND_TCP |
+ LANDLOCK_ACCESS_NET_CONNECT_TCP,
+ };
+ const struct landlock_net_port_attr rule_bind = {
+ .allowed_access = LANDLOCK_ACCESS_NET_BIND_TCP,
+ .port = self->srv0.port,
+ };
+ struct service_fixture srv_remote;
+ struct audit_records records;
+ int ruleset_fd, sock_fd;
+
+ /* Uses a second port as the denied connect target. */
+ ASSERT_EQ(0, set_service(&srv_remote, variant->prot, 1));
+
+ ruleset_fd =
+ landlock_create_ruleset(&ruleset_attr, sizeof(ruleset_attr), 0);
+ ASSERT_LE(0, ruleset_fd);
+ ASSERT_EQ(0, landlock_add_rule(ruleset_fd, LANDLOCK_RULE_NET_PORT,
+ &rule_bind, 0));
+ enforce_ruleset(_metadata, ruleset_fd);
+ EXPECT_EQ(0, close(ruleset_fd));
+
+ sock_fd = socket_variant(&self->srv0);
+ ASSERT_LE(0, sock_fd);
+ EXPECT_EQ(0, bind_variant(sock_fd, &self->srv0));
+ EXPECT_EQ(-EACCES, connect_variant(sock_fd, &srv_remote));
+ EXPECT_EQ(0, matches_log_tcp_bound(self->audit_fd, variant->addr,
+ self->srv0.port, srv_remote.port));
+
+ EXPECT_EQ(0, audit_count_records(self->audit_fd, &records));
+ EXPECT_EQ(0, records.access);
+ EXPECT_EQ(1, records.domain);
+
+ EXPECT_EQ(0, close(sock_fd));
+}
+
TEST_HARNESS_MAIN
base-commit: d8dfb4c7faa87c3e41a8678f38f136c2c7c036fa
--
2.54.0
^ permalink raw reply related
* Re: [PATCH bpf-next 0/5] Verify BPF signed loader at load time
From: Paul Moore @ 2026-06-12 20:56 UTC (permalink / raw)
To: Daniel Borkmann
Cc: ast, kpsingh, James.Bottomley, bboscaccy, memxor, torvalds, bpf,
linux-security-module
In-Reply-To: <78107b57-5f4e-42b8-b780-5aebf7362de2@iogearbox.net>
On Fri, Jun 12, 2026 at 5:33 AM Daniel Borkmann <daniel@iogearbox.net> wrote:
> On 6/12/26 12:56 AM, Paul Moore wrote:
> > On Wed, Jun 10, 2026 at 7:03 PM Daniel Borkmann <daniel@iogearbox.net> wrote:
> >>
> >> The BPF signing scheme signs a light skeleton's loader program and lets
> >> the loader vouch for everything else: bpftool bakes the SHA256 of the
> >> metadata map into the loader's instructions, signs the instructions, and
> >> the loader compares the (frozen, exclusive) map against that hash from
> >> within BPF once it runs. The construction is sound as a trusted hash
> >> chain, but the kernel itself never attests the metadata, and that split
> >> has been the recurring objection from the LSM / integrity side since the
> >> scheme was proposed.
> >>
> >> This proposal closes both gaps by having the kernel verify the metadata
> >> at BPF_PROG_LOAD time, before the LSM admission hook and before the
> >> verifier, /without/ growing the UAPI. A signed loader binds its metadata
> >> map(s) through the existing fd_array/fd_array_cnt, and exclusive maps
> >> are already bound to the loader's digest via excl_prog_hash. When a
> >> signature is present, the kernel collects the exclusive maps from the
> >> fd_array and appends their frozen contents to the instructions before
> >> PKCS#7 verification, so the signature covers ...
> >>
> >> insns || metadata_0 || metadata_1 || [...]
> >>
> >> ... in fd_array order. The in-loader hash check is dropped from the
> >> gen_loader entirely: generated loaders carry no verification logic
> >> anymore, and signing or verifying a skeleton becomes an ordinary CMS
> >> operation over bytes that sit verbatim in the skeleton, reproducible
> >> offline. A signed program is either BPF_SIG_UNSIGNED or BPF_SIG_VERIFIED
> >> with nothing in between.
> >
> > I'll be honest and say I'm a bit surprised to see this patchset,
> > especially since KP and Alexei argued so strongly against this
> > signature scheme, preferring KP's scheme where the loader verified the
> > maps. I'd be curious to hear the reason for the change of heart if
> > you can share it. Regardless of the motivation for this change, I
> > obviously think this is a significant improvement over KP's signature
> > scheme which shipped in Linux v6.18.
> >
> > I also think it is worth mentioning the similarities to work Blaise
> > did before the most recent Hornet version:
> >
> > https://lore.kernel.org/linux-security-module/20250929213520.1821223-1-bboscaccy@linux.microsoft.com/
> >
> > While Blaise's patchset added to the UAPI, that was done simply to
> > retain compatibility with KP's signature scheme; your patchset does
> > without any UAPI additions, but loses compatibility with existing
> > signed lskels. Beyond that, the basic signature scheme between
> > Blaise's patchset and what you are proposing appears the same ...
> > which is a good thing as far as I'm concerned.
>
> For the rework, I've mainly been looking at KP's most recent series as
> well as some of the past discussions. Mainly trying to see if we can get
> away with a simpler model and without having to pull in BTF support for
> the signed loader just for the extra kfunc. Over the last couple of weeks,
> I've also build user space tooling on my side to experiment with some
> real world application which the signed loader would have to deal with.
Out of curiosity, have you discussed these changes with Alexei and/or
KP? You surely know the history here, and as I mentioned above,
you're basically proposing the same signature scheme that Blaise
proposed last September and we all know how Alexei and KP reacted. I
believe that Blaise's signature scheme, which you've adopted, is the
better option so I'm happy to see you move forward with this patchset.
However, I don't want to see you spend a lot of time on this if Alexei
and KP are going to react with the same attacks as last September.
> For sending a v2, I'll have to move this slightly deeper into verifier
> side but before the main verifier work happens in order to solve the
> exclusive map race issue, and additionally we could also utilize the
> verifier log to tell the user that the signature validation failed.
>
> I think a couple of things would still stand out imo: i) we sign over the
> raw bytes, not the derived hash anymore, so the hashing is only used in the
> context to tie the map to the loader prog, but not anymore for the signature.
The important part is that the PKCS7 signature covers both the loader
and the maps and it is verified in the native kernel code without
relying on any actions in the loader.
> ii) its one single scheme and not a parallel branch, so the main loader is
> built upon the updated signing scheme rather than having this as an option
> on the side; iow this replaces the in-loader check and there's a single PKCS#7-
> over-bytes path, not an 'if (signature_maps_size)' fork
I think if you look back at Blaise's early efforts you will see that
we've always favored a single signature scheme. Blaise's various
patchsets only shifted to parallel/compatible mechanisms when it
became clear that Alexei had no interest in anything other than KP's
signature scheme. We didn't want to remove KP's signature scheme
because we believed that would be a non-starter for any patchset; this
is one of the reasons why I'm so surprised to see KP's signature
scheme completely removed in your patchset.
I'm happy to see someone in BPF land come around to supporting
Blaise's signature scheme, I only wish it happened a little sooner, we
likely could have saved everyone a lot of time and stress.
> iii) given we
> expose the verification result in the BPF prog, we also don't need a new LSM
> hook and can just piggy back on the existing security_bpf_prog() which also
> has the possibility to still reject late at this point.
If you look at Blaise's patchset from last September (the one I linked
in my previous email) you will notice he didn't add any additional
hooks either.
--
paul-moore.com
^ permalink raw reply
* Re: [PATCH 09/10] docs/zh_CN: add LSM/ipe Chinese translation
From: Fan Wu @ 2026-06-13 2:54 UTC (permalink / raw)
To: Yan Zhu
Cc: alexs, si.yanteng, corbet, mic, dzm91, skhan, gnoack, linux-doc,
linux-security-module
In-Reply-To: <tencent_DADDE291CA580302EB7BB40B83A552D6F006@qq.com>
On Fri, Jun 12, 2026 at 8:59 AM Yan Zhu <zhuyan2015@qq.com> wrote:
>
> Translate Documentation/admin-guide/LSM/ipe.rst into Chinese.
>
> Update the translation through commit d7ba853c0e47
> ("ipe: Update documentation for script enforcement")
>
> Assisted-by: Claude:deepseek-4-pro
> Signed-off-by: Yan Zhu <zhuyan2015@qq.com>
> ---
Have you tried to refine the AI translation? IMO some are really bad translated.
Also how does the doc translation project work? I do notice there is
another IPE design doc translation,
https://docs.kernel.org/next/translations/zh_CN/security/ipe.html
which has a wrong "original link".
-Fan
^ permalink raw reply
* Re: [PATCH RESEND] apparmor: Fix string overrun due to missing termination
From: John Johansen @ 2026-06-13 4:40 UTC (permalink / raw)
To: Daniel J Blueman, Paul Moore, James Morris, Serge E. Hallyn,
Thorsten Blum, apparmor, linux-security-module
Cc: linux-kernel, stable
In-Reply-To: <20260327115833.7572-1-daniel@quora.org>
On 3/27/26 04:58, Daniel J Blueman wrote:
> When booting Ubuntu 26.04 with Linux 7.0-rc4 on an ARM64 Qualcomm
> Snapdragon X1 we see a string buffer overrun:
>
> BUG: KASAN: slab-out-of-bounds in aa_dfa_match (security/apparmor/match.c:535)
> Read of size 1 at addr ffff0008901cc000 by task snap-update-ns/2120
>
> CPU: 5 UID: 60578 PID: 2120 Comm: snap-update-ns Not tainted 7.0.0-rc4+ #22 PREEMPTLAZY
> Hardware name: LENOVO 83ED/LNVNB161216, BIOS NHCN60WW 09/11/2025
> Call trace:
> show_stack (arch/arm64/kernel/stacktrace.c:501) (C)
> dump_stack_lvl (lib/dump_stack.c:122)
> print_report (mm/kasan/report.c:379 mm/kasan/report.c:482)
> kasan_report (mm/kasan/report.c:597)
> __asan_report_load1_noabort (mm/kasan/report_generic.c:378)
> aa_dfa_match (security/apparmor/match.c:535)
> match_mnt_path_str (security/apparmor/mount.c:244 security/apparmor/mount.c:336)
> match_mnt (security/apparmor/mount.c:371)
> aa_bind_mount (security/apparmor/mount.c:447 (discriminator 4))
> apparmor_sb_mount (security/apparmor/lsm.c:719 (discriminator 1))
> security_sb_mount (security/security.c:1062 (discriminator 31))
> path_mount (fs/namespace.c:4101)
> __arm64_sys_mount (fs/namespace.c:4172 fs/namespace.c:4361 fs/namespace.c:4338 fs/namespace.c:4338)
> invoke_syscall.constprop.0 (arch/arm64/kernel/syscall.c:35 arch/arm64/kernel/syscall.c:49)
> el0_svc_common.constprop.0 (./include/linux/thread_info.h:142 (discriminator 2) arch/arm64/kernel/syscall.c:140 (discriminator 2))
> do_el0_svc (arch/arm64/kernel/syscall.c:152)
> el0_svc (arch/arm64/kernel/entry-common.c:80 arch/arm64/kernel/entry-common.c:725)
> el0t_64_sync_handler (arch/arm64/kernel/entry-common.c:744)
> el0t_64_sync (arch/arm64/kernel/entry.S:596)
>
> Allocated by task 2120:
> kasan_save_stack (mm/kasan/common.c:58)
> kasan_save_track (./arch/arm64/include/asm/current.h:19 mm/kasan/common.c:70 mm/kasan/common.c:79)
> kasan_save_alloc_info (mm/kasan/generic.c:571)
> __kasan_kmalloc (mm/kasan/common.c:419)
> __kmalloc_noprof (./include/linux/kasan.h:263 mm/slub.c:5260 mm/slub.c:5272)
> aa_get_buffer (security/apparmor/lsm.c:2201)
> aa_bind_mount (security/apparmor/mount.c:442)
> apparmor_sb_mount (security/apparmor/lsm.c:719 (discriminator 1))
> security_sb_mount (security/security.c:1062 (discriminator 31))
> path_mount (fs/namespace.c:4101)
> __arm64_sys_mount (fs/namespace.c:4172 fs/namespace.c:4361 fs/namespace.c:4338 fs/namespace.c:4338)
> invoke_syscall.constprop.0 (arch/arm64/kernel/syscall.c:35 arch/arm64/kernel/syscall.c:49)
> el0_svc_common.constprop.0 (./include/linux/thread_info.h:142 (discriminator 2) arch/arm64/kernel/syscall.c:140 (discriminator 2))
> do_el0_svc (arch/arm64/kernel/syscall.c:152)
> el0_svc (arch/arm64/kernel/entry-common.c:80 arch/arm64/kernel/entry-common.c:725)
> el0t_64_sync_handler (arch/arm64/kernel/entry-common.c:744)
> el0t_64_sync (arch/arm64/kernel/entry.S:596)
>
> The buggy address belongs to the object at ffff0008901ca000
> which belongs to the cache kmalloc-rnd-06-8k of size 8192
> The buggy address is located 0 bytes to the right of
> allocated 8192-byte region [ffff0008901ca000, ffff0008901cc000)
>
> The buggy address belongs to the physical page:
> page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x9101c8
> head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:-1 pincount:0
> flags: 0x8000000000000040(head|zone=2)
> page_type: f5(slab)
> raw: 8000000000000040 ffff000800016c40 fffffdffe2d14e10 ffff000800015c70
> raw: 0000000000000000 0000000800010001 00000000f5000000 0000000000000000
> head: 8000000000000040 ffff000800016c40 fffffdffe2d14e10 ffff000800015c70
> head: 0000000000000000 0000000800010001 00000000f5000000 0000000000000000
> head: 8000000000000003 fffffdffe2407201 fffffdffffffffff 00000000ffffffff
> head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000008
> page dumped because: kasan: bad access detected
>
> Memory state around the buggy address:
> ffff0008901cbf00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> ffff0008901cbf80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>> ffff0008901cc000: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> ^
> ffff0008901cc080: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> ffff0008901cc100: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>
> This was introduced by previous incorrect conversion from strcpy(). Fix it
> by adding the missing terminator.
>
> Cc: stable@vger.kernel.org
> Signed-off-by: Daniel J Blueman <daniel@quora.org>
> Fixes: 93d4dbdc8da0 ("apparmor: Replace deprecated strcpy in d_namespace_path")
sorry for the lateness of my reply, my email wasn't working when I pulled this
in for 7.1
just for the record
Acked-by: John Johansen <john.johansen@canonical.com>
> ---
> security/apparmor/path.c | 8 +++++---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/security/apparmor/path.c b/security/apparmor/path.c
> index 65a0ca5cc1bd..2494e8101538 100644
> --- a/security/apparmor/path.c
> +++ b/security/apparmor/path.c
> @@ -164,14 +164,16 @@ static int d_namespace_path(const struct path *path, char *buf, char **name,
> }
>
> out:
> - /* Append "/" to directory paths, except for root "/" which
> - * already ends in a slash.
> + /* Append "/" to directory paths and reterminate string, except for
> + * root "/" which already ends in a slash.
> */
> if (!error && isdir) {
> bool is_root = (*name)[0] == '/' && (*name)[1] == '\0';
>
> - if (!is_root)
> + if (!is_root) {
> buf[aa_g_path_max - 2] = '/';
> + buf[aa_g_path_max - 1] = '\0';
> + }
> }
>
> return error;
^ permalink raw reply
* Re: [PATCH] apparmor/lsm: Fix aa_dfa_unpack's error handling in aa_setup_dfa_engine
From: John Johansen @ 2026-06-13 4:42 UTC (permalink / raw)
To: GONG Ruiqi, Paul Moore, James Morris, Serge E . Hallyn,
Georgia Garcia
Cc: apparmor, linux-security-module, linux-kernel, lujialin4,
zhaoyipeng5
In-Reply-To: <20260423031056.563527-1-gongruiqi1@huawei.com>
On 4/22/26 20:10, GONG Ruiqi wrote:
> aa_dfa_unpack returns ERR_PTR not NULL when it fails, but aa_put_dfa
> only checks NULL for its input, which would cause invalid memory access
> in aa_put_dfa. Set nulldfa to NULL explicitly to fix that.
>
> Fixes: 98b824ff8984 ("apparmor: refcount the pdb")
> Signed-off-by: GONG Ruiqi <gongruiqi1@huawei.com>
sorry for the lateness of the reply my mail wasn't working when I pulled
this in for 7.1
Acked-by: John Johansen <john.johansen@canonical.com>
> ---
> security/apparmor/lsm.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/security/apparmor/lsm.c b/security/apparmor/lsm.c
> index c1d42fc72fdb..ead2f07982b6 100644
> --- a/security/apparmor/lsm.c
> +++ b/security/apparmor/lsm.c
> @@ -2465,6 +2465,7 @@ static int __init aa_setup_dfa_engine(void)
> TO_ACCEPT2_FLAG(YYTD_DATA32));
> if (IS_ERR(nulldfa)) {
> error = PTR_ERR(nulldfa);
> + nulldfa = NULL;
> goto fail;
> }
> nullpdb->dfa = aa_get_dfa(nulldfa);
^ permalink raw reply
* Re: [PATCH 1/3] apparmor: Fix return in ns_mkdir_op
From: John Johansen @ 2026-06-13 7:13 UTC (permalink / raw)
To: Hongling Zeng, paul, jmorris, serge, neil, brauner, jlayton, jack
Cc: apparmor, linux-security-module, linux-kernel, zhongling0719
In-Reply-To: <20260503041243.200895-1-zenghongling@kylinos.cn>
On 5/2/26 21:12, Hongling Zeng wrote:
> Return NULL instead of passing to ERR_PTR while error is zero.
> Fixes smatch warning:
> - security/apparmor/apparmorfs.c:1846 ns_mkdir_op() warn:
> passing zero to 'ERR_PTR'
>
> Fixes: 88d5baf69082 ("Change inode_operations.mkdir to return struct dentry *")
> Signed-off-by: Hongling Zeng <zenghongling@kylinos.cn>
Acked-by: John Johansen <john.johansen@canonical.com>
this has been pulled in to my tree
> ---
> security/apparmor/apparmorfs.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/security/apparmor/apparmorfs.c b/security/apparmor/apparmorfs.c
> index ededaf46f3ca..1d7b1c70f22a 100644
> --- a/security/apparmor/apparmorfs.c
> +++ b/security/apparmor/apparmorfs.c
> @@ -1922,7 +1922,7 @@ static struct dentry *ns_mkdir_op(struct mnt_idmap *idmap, struct inode *dir,
> mutex_unlock(&parent->lock);
> aa_put_ns(parent);
>
> - return ERR_PTR(error);
> + return error ? ERR_PTR(error) : NULL;
> }
>
> static int ns_rmdir_op(struct inode *dir, struct dentry *dentry)
^ permalink raw reply
* Re: [PATCH] apparmor: fix use-after-free in policy replacement path
From: John Johansen @ 2026-06-13 9:42 UTC (permalink / raw)
To: Junxiao Chang, paul, jmorris, serge, apparmor,
linux-security-module, linux-kernel
In-Reply-To: <20260613060424.2213712-1-junxiao.chang@intel.com>
On 6/12/26 23:04, Junxiao Chang wrote:
> A use-after-free issue can be triggered when running the
> following stress-ng workload:
>
> ```
> sudo stress-ng --apparmor 0 --timeout 30 \
> --oom-avoid-bytes 10% --skip-silent --verbose
> ```
>
> The warning looks like:
>
> ```
> refcount_t: addition on 0; use-after-free
> aa_replace_profiles+0xbe5/0x12a0
> policy_update+0xdb/0x170
> profile_replace+0x4b/0xb0
> ```
>
> The issue can be reproduced on both v7.1-rc7 and Ubuntu
> 6.17.0-35-generic kernels.
>
> aa_get_profile_loaddata() requires the supplied loaddata object
> to hold a valid reference. However, the loaddata reference count
> may already have reached zero in the replacement loop, resulting
> in a use-after-free condition.
>
> Avoid calling aa_get_profile_loaddata() on loaddata objects with
> a zero reference count and skip those entries instead.
>
> Fixes: a0b7091c4de4 ("apparmor: fix race on rawdata dereference")
> Signed-off-by: Junxiao Chang <junxiao.chang@intel.com>
sorry I went with Ruslan Valiyev's earlier patch that fixes the same
issue
apparmor: fix use-after-free in rawdata dedup loop
> ---
> security/apparmor/policy.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/security/apparmor/policy.c b/security/apparmor/policy.c
> index b6a5eb4021dbd..98f84d4552697 100644
> --- a/security/apparmor/policy.c
> +++ b/security/apparmor/policy.c
> @@ -1220,7 +1220,7 @@ ssize_t aa_replace_profiles(struct aa_ns *policy_ns, struct aa_label *label,
> /* check for duplicate rawdata blobs: space and file dedup */
> if (!list_empty(&ns->rawdata_list)) {
> list_for_each_entry(rawdata_ent, &ns->rawdata_list, list) {
> - if (aa_rawdata_eq(rawdata_ent, udata)) {
> + if (kref_read(&rawdata_ent->pcount) && aa_rawdata_eq(rawdata_ent, udata)) {
> struct aa_loaddata *tmp;
>
> tmp = aa_get_profile_loaddata(rawdata_ent);
^ permalink raw reply
* [PATCH 0/2] security/keys: replace BUG() in unreachable default cases
From: Mohammed EL Kadiri @ 2026-06-13 13:04 UTC (permalink / raw)
To: jarkko, dhowells
Cc: paul, jmorris, serge, kees, keyrings, linux-security-module,
linux-kernel, linux-hardening, Mohammed EL Kadiri
Replace BUG() in two switch default cases with proper error
returns.
Mohammed EL Kadiri (2):
keys: request_key: replace BUG with return -EINVAL
keys: keyctl_pkey: replace BUG with return -EOPNOTSUPP
security/keys/keyctl_pkey.c | 5 +++--
security/keys/request_key.c | 2 +-
2 files changed, 4 insertions(+), 3 deletions(-)
--
2.43.0
^ permalink raw reply
* [PATCH 1/2] keys: request_key: replace BUG with return -EINVAL
From: Mohammed EL Kadiri @ 2026-06-13 13:04 UTC (permalink / raw)
To: jarkko, dhowells
Cc: paul, jmorris, serge, kees, keyrings, linux-security-module,
linux-kernel, linux-hardening, Mohammed EL Kadiri
In-Reply-To: <20260613130408.13709-1-med08elkadiri@gmail.com>
Replace BUG() in construct_get_dest_keyring() default case
with return -EINVAL to handle the unimplemented group keyring
destination gracefully.
Signed-off-by: Mohammed EL Kadiri <med08elkadiri@gmail.com>
---
security/keys/request_key.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/security/keys/request_key.c b/security/keys/request_key.c
index a7673ad86d18..fa2bb9f2f538 100644
--- a/security/keys/request_key.c
+++ b/security/keys/request_key.c
@@ -332,7 +332,7 @@ static int construct_get_dest_keyring(struct key **_dest_keyring)
case KEY_REQKEY_DEFL_GROUP_KEYRING:
default:
- BUG();
+ return -EINVAL;
}
/*
--
2.43.0
^ permalink raw reply related
* [PATCH 2/2] keys: keyctl_pkey: replace BUG with return -EOPNOTSUPP
From: Mohammed EL Kadiri @ 2026-06-13 13:04 UTC (permalink / raw)
To: jarkko, dhowells
Cc: paul, jmorris, serge, kees, keyrings, linux-security-module,
linux-kernel, linux-hardening, Mohammed EL Kadiri
In-Reply-To: <20260613130408.13709-1-med08elkadiri@gmail.com>
Replace two BUG() calls in keyctl_pkey_params_get_2() and
keyctl_pkey_e_d_s() default cases with -EOPNOTSUPP, matching
the error style already used in these functions.
Signed-off-by: Mohammed EL Kadiri <med08elkadiri@gmail.com>
---
security/keys/keyctl_pkey.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/security/keys/keyctl_pkey.c b/security/keys/keyctl_pkey.c
index 97bc27bbf079..6b2821ffeb6c 100644
--- a/security/keys/keyctl_pkey.c
+++ b/security/keys/keyctl_pkey.c
@@ -155,7 +155,7 @@ static int keyctl_pkey_params_get_2(const struct keyctl_pkey_params __user *_par
return -EINVAL;
break;
default:
- BUG();
+ return -EOPNOTSUPP;
}
params->in_len = uparams.in_len;
@@ -238,7 +238,8 @@ long keyctl_pkey_e_d_s(int op,
params.op = kernel_pkey_sign;
break;
default:
- BUG();
+ ret = -EOPNOTSUPP;
+ goto error_params;
}
in = memdup_user(_in, params.in_len);
--
2.43.0
^ permalink raw reply related
* Re: [PATCH 09/10] docs/zh_CN: add LSM/ipe Chinese translation
From: Yan Zhu @ 2026-06-13 15:08 UTC (permalink / raw)
To: Fan Wu
Cc: alexs, si.yanteng, corbet, mic, dzm91, skhan, gnoack, linux-doc,
linux-security-module
In-Reply-To: <CAKtyLkE3unhxMsH1LpqvjHQoKVgz1tcTsZWUxNHs+R6v2amf6w@mail.gmail.com>
On 6/13/2026 10:54 AM, Fan Wu wrote:
> On Fri, Jun 12, 2026 at 8:59 AM Yan Zhu <zhuyan2015@qq.com> wrote:
>>
>> Translate Documentation/admin-guide/LSM/ipe.rst into Chinese.
>>
>> Update the translation through commit d7ba853c0e47
>> ("ipe: Update documentation for script enforcement")
>>
>> Assisted-by: Claude:deepseek-4-pro
>> Signed-off-by: Yan Zhu <zhuyan2015@qq.com>
>> ---
>
> Have you tried to refine the AI translation? IMO some are really bad translated.
I have double-checked it several times and manually corrected the
formatting and the accuracy of the translation.
>
> Also how does the doc translation project work? I do notice there is
> another IPE design doc translation,
> https://docs.kernel.org/next/translations/zh_CN/security/ipe.html
> which has a wrong "original link".>
> -Fan
The documents in the "admin-guide" directory are intended for both
administrators and users, focusing on usage; the documents in the
"security" directory are targeted at developers, emphasizing design and
development.
--
Thanks
Yan Zhu
^ permalink raw reply
* Re: [PATCH] Add LoadPin support for eBPF program loading
From: Alex Roberts @ 2026-06-13 18:54 UTC (permalink / raw)
To: Alexei Starovoitov, David Windsor
Cc: Kees Cook, Paul Moore, James Morris, Serge E . Hallyn, LKML,
LSM List, bpf, Alexei Starovoitov, KP Singh
In-Reply-To: <CAADnVQL9CJMY9h8haj5+99x-0GmiaHv3wDWuZ_YCYETKTznBbw@mail.gmail.com>
>Why are we checking current here? IIUC this will be whoever calls
bpf(2), which would be the loader, which would then be able to load bpf
programs from an untrusted source.
The loader's filesystem would be pinned. If the filesystem is trusted, e.g., dm-verity with signed root hash, the loader is implicitly trusted. Would this not be similar unsigned kmodules from a load-pinned dm-verity filesystem?
Obviously, this would have to exclude the usecase of dynamically generated BPF programs from bpftrace.
________________________________________
From: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Sent: Friday, June 12, 2026 10:20 AM
To: David Windsor <dwindsor@gmail.com>
Cc: alex.roberts109@outlook.com <alex.roberts109@outlook.com>; Kees Cook <kees@kernel.org>; Paul Moore <paul@paul-moore.com>; James Morris <jmorris@namei.org>; Serge E . Hallyn <serge@hallyn.com>; LKML <linux-kernel@vger.kernel.org>; LSM List <linux-security-module@vger.kernel.org>; bpf <bpf@vger.kernel.org>; Alexei Starovoitov <ast@kernel.org>; KP Singh <kpsingh@kernel.org>
Subject: Re: [PATCH] Add LoadPin support for eBPF program loading
On Thu, Jun 11, 2026 at 5:08 PM David Windsor <dwindsor@gmail.com> wrote:
>
> On Thu, Jun 11, 2026 at 01:59:10PM -0500, Alex Roberts wrote:
> > +static int loadpin_bpf_prog_load(struct bpf_prog *prog, union bpf_attr *attr,
> > + struct bpf_token *token, bool is_kernel)
> > +{
> > + int res = 0;
> > + struct file *exe_file = NULL;
> > + struct mm_struct *mm = current->mm;
> > +
> > + if (is_kernel || !mm)
> > + return 0;
> > +
> > + exe_file = get_mm_exe_file(mm);
> > + if (!exe_file)
> > + return 0;
> > +
> > + res = loadpin_check(exe_file, READING_EBPF);
>
> Why are we checking current here? IIUC this will be whoever calls
> bpf(2), which would be the loader, which would then be able to load bpf
> programs from an untrusted source.
>
> In the kmod case loadpin_check() sees the .ko itself.
See sashiko comments:
- [High] The LoadPin eBPF trust mechanism can be trivially bypassed
using standard system interpreters like the dynamic linker (`ld.so`).
- [High] The LoadPin eBPF trust mechanism can be bypassed by a
privileged attacker using prctl(PR_SET_MM_EXE_FILE).
and the bot is correct.
This patch is pointless.
^ permalink raw reply
* Re: [PATCH] Add LoadPin support for eBPF program loading
From: Alex Roberts @ 2026-06-13 18:59 UTC (permalink / raw)
To: Alexei Starovoitov, David Windsor
Cc: Kees Cook, Paul Moore, James Morris, Serge E . Hallyn, LKML,
LSM List, bpf, Alexei Starovoitov, KP Singh
In-Reply-To: <CAADnVQL9CJMY9h8haj5+99x-0GmiaHv3wDWuZ_YCYETKTznBbw@mail.gmail.com>
>This patch is pointless.
This was supposed to an RFC, but b4 complained when adding presubject "[RFC]".
Sorry about the bot build errors, tested against WSL config. Is there a standard config to build against for patches?
>- [High] The LoadPin eBPF trust mechanism can be trivially bypassed
>using standard system interpreters like the dynamic linker (`ld.so`).
>- [High] The LoadPin eBPF trust mechanism can be bypassed by a
>privileged attacker using prctl(PR_SET_MM_EXE_FILE).
As the intent was an RFC, is there any value in pursuing LoadPin for eBPF or is it so trivially bypassable its not worth it?
________________________________________
From: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Sent: Friday, June 12, 2026 10:20 AM
To: David Windsor <dwindsor@gmail.com>
Cc: alex.roberts109@outlook.com <alex.roberts109@outlook.com>; Kees Cook <kees@kernel.org>; Paul Moore <paul@paul-moore.com>; James Morris <jmorris@namei.org>; Serge E . Hallyn <serge@hallyn.com>; LKML <linux-kernel@vger.kernel.org>; LSM List <linux-security-module@vger.kernel.org>; bpf <bpf@vger.kernel.org>; Alexei Starovoitov <ast@kernel.org>; KP Singh <kpsingh@kernel.org>
Subject: Re: [PATCH] Add LoadPin support for eBPF program loading
On Thu, Jun 11, 2026 at 5:08 PM David Windsor <dwindsor@gmail.com> wrote:
>
> On Thu, Jun 11, 2026 at 01:59:10PM -0500, Alex Roberts wrote:
> > +static int loadpin_bpf_prog_load(struct bpf_prog *prog, union bpf_attr *attr,
> > + struct bpf_token *token, bool is_kernel)
> > +{
> > + int res = 0;
> > + struct file *exe_file = NULL;
> > + struct mm_struct *mm = current->mm;
> > +
> > + if (is_kernel || !mm)
> > + return 0;
> > +
> > + exe_file = get_mm_exe_file(mm);
> > + if (!exe_file)
> > + return 0;
> > +
> > + res = loadpin_check(exe_file, READING_EBPF);
>
> Why are we checking current here? IIUC this will be whoever calls
> bpf(2), which would be the loader, which would then be able to load bpf
> programs from an untrusted source.
>
> In the kmod case loadpin_check() sees the .ko itself.
See sashiko comments:
- [High] The LoadPin eBPF trust mechanism can be trivially bypassed
using standard system interpreters like the dynamic linker (`ld.so`).
- [High] The LoadPin eBPF trust mechanism can be bypassed by a
privileged attacker using prctl(PR_SET_MM_EXE_FILE).
and the bot is correct.
This patch is pointless.
^ permalink raw reply
* Re: [PATCH v5 2/6] landlock: Add UDP send+connect access control
From: Mickaël Salaün @ 2026-06-13 20:55 UTC (permalink / raw)
To: Matthieu Buffet
Cc: Günther Noack, linux-security-module, Mikhail Ivanov,
konstantin.meskhidze, Tingmao Wang, netdev
In-Reply-To: <20260611162107.49278-3-matthieu@buffet.re>
A few issues were identified by Sashiko:
https://sashiko.dev/#/patchset/20260611162107.49278-1-matthieu%40buffet.re
I squashed this patch:
diff --git a/security/landlock/net.c b/security/landlock/net.c
index 9273cdbbf844..b12568666a9e 100644
--- a/security/landlock/net.c
+++ b/security/landlock/net.c
@@ -261,10 +261,17 @@ static int current_check_access_socket(struct socket *const sock,
static int current_check_autobind_udp_socket(struct socket *const sock)
{
+ const struct access_masks bind_udp = {
+ .net = LANDLOCK_ACCESS_NET_BIND_UDP,
+ };
struct sockaddr_storage port0 = {};
unsigned short num;
bool slow;
+ /* Quick return for non-Landlocked tasks. */
+ if (!landlock_get_applicable_subject(current_cred(), bind_udp, NULL))
+ return 0;
+
/*
* On UDP sockets, if a local port has not already been bound, calling
* connect() or sending a first datagram has the side effect of
@@ -287,8 +294,7 @@ static int current_check_autobind_udp_socket(struct socket *const sock)
port0.ss_family = READ_ONCE(sock->sk->sk_family);
return current_check_access_socket(sock, (struct sockaddr *)&port0,
- sizeof(port0),
- LANDLOCK_ACCESS_NET_BIND_UDP, false);
+ sizeof(port0), bind_udp.net, false);
}
static int hook_socket_bind(struct socket *const sock,
@@ -328,7 +334,9 @@ static int hook_socket_connect(struct socket *const sock,
* connect()ing to an AF_UNSPEC address does not trigger an autobind and
* should never be restricted.
*/
- if (ret == 0 && sk_is_udp(sock->sk) && address->sa_family != AF_UNSPEC)
+ if (ret == 0 && sk_is_udp(sock->sk) &&
+ addrlen >= offsetofend(typeof(*address), sa_family) &&
+ address->sa_family != AF_UNSPEC)
ret = current_check_autobind_udp_socket(sock);
return ret;
We might want to factor out some code, but that should be good for now.
On Thu, Jun 11, 2026 at 06:21:02PM +0200, Matthieu Buffet wrote:
> Add support for a second fine-grained UDP access right.
> LANDLOCK_ACCESS_NET_CONNECT_SEND_UDP controls the ability to set the
> remote port of a socket (via connect()) and to specify an explicit
> destination when sending a datagram, to override any remote peer set on
> a UDP socket (e.g. in sendto() or sendmsg()).
> It will be useful for applications that send datagrams, and for some
> servers too (those creating per-client sockets, which want to receive
> traffic only from a specific address).
>
> Similarly as for bind(), this access control is performed when
> configuring sockets, not in hot code paths.
>
> Add detection of when autobind is about to be required, and deny the
> operation if the process would not be allowed to call bind(0)
> explicitly. Autobind can only be performed in udp_lib_get_port() from
> code paths already controlled by LSM hooks: when connect()ing,
> sending a first datagram, and in some splice() EOF edge case which,
> afaiu, can only happen after a remote peer has been set. This invariant
> needs to be preserved to keep bind policies actually enforced.
>
> Signed-off-by: Matthieu Buffet <matthieu@buffet.re>
> ---
> include/uapi/linux/landlock.h | 23 ++++
> security/landlock/audit.c | 2 +
> security/landlock/limits.h | 2 +-
> security/landlock/net.c | 137 +++++++++++++++++---
> tools/testing/selftests/landlock/net_test.c | 5 +-
> 5 files changed, 151 insertions(+), 18 deletions(-)
>
> diff --git a/include/uapi/linux/landlock.h b/include/uapi/linux/landlock.h
> index 045b251ff1b4..b147223efc97 100644
> --- a/include/uapi/linux/landlock.h
> +++ b/include/uapi/linux/landlock.h
> @@ -378,11 +378,34 @@ struct landlock_net_port_attr {
> *
> * - %LANDLOCK_ACCESS_NET_BIND_UDP: Bind UDP sockets to the given local
> * port. Support added in Landlock ABI version 10.
> + * - %LANDLOCK_ACCESS_NET_CONNECT_SEND_UDP: Set the remote port of UDP
> + * sockets to the given port, or send datagrams to the given remote port
> + * ignoring any destination pre-set on a socket. Support added in
> + * Landlock ABI version 10.
> + *
> + * .. note:: Setting a remote address or sending a first datagram
> + * auto-binds UDP sockets to an ephemeral local source port if not
> + * already bound. To allow this if both %LANDLOCK_ACCESS_NET_BIND_UDP
> + * and %LANDLOCK_ACCESS_NET_CONNECT_SEND_UDP are handled, you need to
> + * either:
> + *
> + * - use a socket already bound to a port before the ruleset started
> + * being enforced;
> + * - or grant %LANDLOCK_ACCESS_NET_BIND_UDP on port 0, meaning "any
> + * port in the ephemeral port range";
> + * - or grant %LANDLOCK_ACCESS_NET_BIND_UDP on a specific port, and
> + * call :manpage:`bind(2)` on that port before trying to
> + * :manpage:`connect(2)` or send datagrams.
> + *
> + * .. note:: Sending datagrams to an ``AF_UNSPEC`` destination address
> + * family is not supported for IPv6 UDP sockets: you will need to use a
> + * ``NULL`` address instead.
> */
> /* clang-format off */
> #define LANDLOCK_ACCESS_NET_BIND_TCP (1ULL << 0)
> #define LANDLOCK_ACCESS_NET_CONNECT_TCP (1ULL << 1)
> #define LANDLOCK_ACCESS_NET_BIND_UDP (1ULL << 2)
> +#define LANDLOCK_ACCESS_NET_CONNECT_SEND_UDP (1ULL << 3)
> /* clang-format on */
>
> /**
> diff --git a/security/landlock/audit.c b/security/landlock/audit.c
> index e676ebffeebe..851647197a01 100644
> --- a/security/landlock/audit.c
> +++ b/security/landlock/audit.c
> @@ -46,6 +46,8 @@ static const char *const net_access_strings[] = {
> [BIT_INDEX(LANDLOCK_ACCESS_NET_BIND_TCP)] = "net.bind_tcp",
> [BIT_INDEX(LANDLOCK_ACCESS_NET_CONNECT_TCP)] = "net.connect_tcp",
> [BIT_INDEX(LANDLOCK_ACCESS_NET_BIND_UDP)] = "net.bind_udp",
> + [BIT_INDEX(LANDLOCK_ACCESS_NET_CONNECT_SEND_UDP)] =
> + "net.connect_send_udp",
> };
>
> static_assert(ARRAY_SIZE(net_access_strings) == LANDLOCK_NUM_ACCESS_NET);
> diff --git a/security/landlock/limits.h b/security/landlock/limits.h
> index c0f30a4591b8..a4d908b240a2 100644
> --- a/security/landlock/limits.h
> +++ b/security/landlock/limits.h
> @@ -23,7 +23,7 @@
> #define LANDLOCK_MASK_ACCESS_FS ((LANDLOCK_LAST_ACCESS_FS << 1) - 1)
> #define LANDLOCK_NUM_ACCESS_FS __const_hweight64(LANDLOCK_MASK_ACCESS_FS)
>
> -#define LANDLOCK_LAST_ACCESS_NET LANDLOCK_ACCESS_NET_BIND_UDP
> +#define LANDLOCK_LAST_ACCESS_NET LANDLOCK_ACCESS_NET_CONNECT_SEND_UDP
> #define LANDLOCK_MASK_ACCESS_NET ((LANDLOCK_LAST_ACCESS_NET << 1) - 1)
> #define LANDLOCK_NUM_ACCESS_NET __const_hweight64(LANDLOCK_MASK_ACCESS_NET)
>
> diff --git a/security/landlock/net.c b/security/landlock/net.c
> index 8da40614c452..0e697403eca9 100644
> --- a/security/landlock/net.c
> +++ b/security/landlock/net.c
> @@ -44,7 +44,8 @@ int landlock_append_net_rule(struct landlock_ruleset *const ruleset,
> static int current_check_access_socket(struct socket *const sock,
> struct sockaddr *const address,
> const int addrlen,
> - access_mask_t access_request)
> + access_mask_t access_request,
> + bool connecting)
> {
> unsigned short sock_family;
> __be16 port;
> @@ -75,19 +76,51 @@ static int current_check_access_socket(struct socket *const sock,
>
> switch (address->sa_family) {
> case AF_UNSPEC:
> - if (access_request == LANDLOCK_ACCESS_NET_CONNECT_TCP) {
> + if (access_request == LANDLOCK_ACCESS_NET_CONNECT_TCP ||
> + (access_request == LANDLOCK_ACCESS_NET_CONNECT_SEND_UDP &&
> + connecting)) {
> /*
> * Connecting to an address with AF_UNSPEC dissolves
> - * the TCP association, which have the same effect as
> - * closing the connection while retaining the socket
> - * object (i.e., the file descriptor). As for dropping
> - * privileges, closing connections is always allowed.
> - *
> - * For a TCP access control system, this request is
> - * legitimate. Let the network stack handle potential
> + * the remote association while retaining the socket
> + * object (i.e., the file descriptor). For TCP, it has
> + * the same effect as closing the connection. For UDP,
> + * it removes any preset remote address. As for
> + * dropping privileges, these actions are always
> + * allowed.
> + * Let the network stack handle potential
> * inconsistencies and return -EINVAL if needed.
> */
> return 0;
> + } else if (access_request ==
> + LANDLOCK_ACCESS_NET_CONNECT_SEND_UDP) {
> + if (sock_family == AF_INET6) {
> + /*
> + * We cannot allow sending UDP datagrams to an
> + * explicit AF_UNSPEC address on IPv6 sockets,
> + * even if AF_UNSPEC is treated as "no address"
> + * on such sockets (so it should always be allowed).
> + * That's because the socket's family can change under
> + * our feet (if another thread calls setsockopt(IPV6_ADDRFORM))
> + * to IPv4, which would then treat AF_UNSPEC as
> + * AF_INET.
> + */
> + audit_net.family = AF_UNSPEC;
> + audit_net.sk = sock->sk;
> + landlock_init_layer_masks(
> + subject->domain, access_request,
> + &layer_masks, LANDLOCK_KEY_NET_PORT);
> + landlock_log_denial(
> + subject,
> + &(struct landlock_request){
> + .type = LANDLOCK_REQUEST_NET_ACCESS,
> + .audit.type =
> + LSM_AUDIT_DATA_NET,
> + .audit.u.net = &audit_net,
> + .access = access_request,
> + .layer_masks = &layer_masks,
> + });
> + return -EACCES;
> + }
> } else if (access_request == LANDLOCK_ACCESS_NET_BIND_TCP ||
> access_request == LANDLOCK_ACCESS_NET_BIND_UDP) {
> /*
> @@ -130,7 +163,11 @@ static int current_check_access_socket(struct socket *const sock,
> } else {
> WARN_ON_ONCE(1);
> }
> - /* Only for bind(AF_UNSPEC+INADDR_ANY) on IPv4 socket. */
> + /*
> + * AF_UNSPEC is treated as AF_INET only in
> + * bind(AF_UNSPEC+INADDR_ANY) on IPv4 sockets and
> + * when sending to AF_UNSPEC addresses on IPv4 sockets.
> + */
> fallthrough;
> case AF_INET: {
> const struct sockaddr_in *addr4;
> @@ -141,7 +178,8 @@ static int current_check_access_socket(struct socket *const sock,
> addr4 = (struct sockaddr_in *)address;
> port = addr4->sin_port;
>
> - if (access_request == LANDLOCK_ACCESS_NET_CONNECT_TCP) {
> + if (access_request == LANDLOCK_ACCESS_NET_CONNECT_TCP ||
> + access_request == LANDLOCK_ACCESS_NET_CONNECT_SEND_UDP) {
> audit_net.dport = port;
> audit_net.v4info.daddr = addr4->sin_addr.s_addr;
> } else if (access_request == LANDLOCK_ACCESS_NET_BIND_TCP ||
> @@ -164,7 +202,8 @@ static int current_check_access_socket(struct socket *const sock,
> addr6 = (struct sockaddr_in6 *)address;
> port = addr6->sin6_port;
>
> - if (access_request == LANDLOCK_ACCESS_NET_CONNECT_TCP) {
> + if (access_request == LANDLOCK_ACCESS_NET_CONNECT_TCP ||
> + access_request == LANDLOCK_ACCESS_NET_CONNECT_SEND_UDP) {
> audit_net.dport = port;
> audit_net.v6info.daddr = addr6->sin6_addr;
> } else if (access_request == LANDLOCK_ACCESS_NET_BIND_TCP ||
> @@ -221,6 +260,38 @@ static int current_check_access_socket(struct socket *const sock,
> return -EACCES;
> }
>
> +static int current_check_autobind_udp_socket(struct socket *const sock)
> +{
> + struct sockaddr_storage port0 = {};
> + unsigned short num;
> + bool slow;
> +
> + /*
> + * On UDP sockets, if a local port has not already been bound,
> + * calling connect() or sending a first datagram has the side
> + * effect of autobinding an ephemeral port: we also have to check
> + * that the process would have had the right to bind(0) explicitly.
> + * Hold the socket lock around the inet_num read to exclude
> + * udp_lib_get_port()'s transient inet_num = snum write that is
> + * reverted to 0 on a failing reuseport bind.
> + */
> + slow = lock_sock_fast(sock->sk);
> + num = inet_sk(sock->sk)->inet_num;
> + unlock_sock_fast(sock->sk, slow);
> + if (num != 0)
> + return 0;
> +
> + /*
> + * Construct a struct sockaddr* with port 0 to pretend the
> + * process tried to bind() on that address.
> + */
> + port0.ss_family = READ_ONCE(sock->sk->sk_family);
> +
> + return current_check_access_socket(sock, (struct sockaddr *)&port0,
> + sizeof(port0),
> + LANDLOCK_ACCESS_NET_BIND_UDP, false);
> +}
> +
> static int hook_socket_bind(struct socket *const sock,
> struct sockaddr *const address, const int addrlen)
> {
> @@ -234,7 +305,7 @@ static int hook_socket_bind(struct socket *const sock,
> return 0;
>
> return current_check_access_socket(sock, address, addrlen,
> - access_request);
> + access_request, false);
> }
>
> static int hook_socket_connect(struct socket *const sock,
> @@ -242,19 +313,55 @@ static int hook_socket_connect(struct socket *const sock,
> const int addrlen)
> {
> access_mask_t access_request;
> + int ret = 0;
>
> if (sk_is_tcp(sock->sk))
> access_request = LANDLOCK_ACCESS_NET_CONNECT_TCP;
> + else if (sk_is_udp(sock->sk))
> + access_request = LANDLOCK_ACCESS_NET_CONNECT_SEND_UDP;
> else
> return 0;
>
> - return current_check_access_socket(sock, address, addrlen,
> - access_request);
> + ret = current_check_access_socket(sock, address, addrlen,
> + access_request, true);
> +
> + /*
> + * connect()ing to an AF_UNSPEC address does not trigger an
> + * autobind and should never be restricted.
> + */
> + if (ret == 0 && sk_is_udp(sock->sk) && address->sa_family != AF_UNSPEC)
> + ret = current_check_autobind_udp_socket(sock);
> +
> + return ret;
> +}
> +
> +static int hook_socket_sendmsg(struct socket *const sock,
> + struct msghdr *const msg, const int size)
> +{
> + struct sockaddr *const address = msg->msg_name;
> + const int addrlen = msg->msg_namelen;
> + access_mask_t access_request;
> + int ret = 0;
> +
> + if (sk_is_udp(sock->sk))
> + access_request = LANDLOCK_ACCESS_NET_CONNECT_SEND_UDP;
> + else
> + return 0;
> +
> + if (address != NULL)
> + ret = current_check_access_socket(sock, address, addrlen,
> + access_request, false);
> +
> + if (ret == 0)
> + ret = current_check_autobind_udp_socket(sock);
> +
> + return ret;
> }
>
> static struct security_hook_list landlock_hooks[] __ro_after_init = {
> LSM_HOOK_INIT(socket_bind, hook_socket_bind),
> LSM_HOOK_INIT(socket_connect, hook_socket_connect),
> + LSM_HOOK_INIT(socket_sendmsg, hook_socket_sendmsg),
> };
>
> __init void landlock_add_net_hooks(void)
> diff --git a/tools/testing/selftests/landlock/net_test.c b/tools/testing/selftests/landlock/net_test.c
> index ec392d971ea3..016c7277e370 100644
> --- a/tools/testing/selftests/landlock/net_test.c
> +++ b/tools/testing/selftests/landlock/net_test.c
> @@ -1326,12 +1326,13 @@ FIXTURE_TEARDOWN(mini)
>
> /* clang-format off */
>
> -#define ACCESS_LAST LANDLOCK_ACCESS_NET_BIND_UDP
> +#define ACCESS_LAST LANDLOCK_ACCESS_NET_CONNECT_SEND_UDP
>
> #define ACCESS_ALL ( \
> LANDLOCK_ACCESS_NET_BIND_TCP | \
> LANDLOCK_ACCESS_NET_CONNECT_TCP | \
> - LANDLOCK_ACCESS_NET_BIND_UDP)
> + LANDLOCK_ACCESS_NET_BIND_UDP | \
> + LANDLOCK_ACCESS_NET_CONNECT_SEND_UDP)
>
> /* clang-format on */
>
> --
> 2.47.3
>
>
^ permalink raw reply related
* Re: [PATCH] lsm: hold cred_guard_mutex for lsm_set_self_attr()
From: John Johansen @ 2026-06-13 23:29 UTC (permalink / raw)
To: Paul Moore, Stephen Smalley, selinux
Cc: omosnace, casey, serge, linux-security-module
In-Reply-To: <b99c011e6d988fb98ad017265115b323@paul-moore.com>
On 5/14/26 13:47, Paul Moore wrote:
> On May 13, 2026 Stephen Smalley <stephen.smalley.work@gmail.com> wrote:
>>
>> Just as proc_pid_attr_write() already does before calling the LSM
>> hook. This only matters for SELinux and AppArmor which check
>> whether the process is being ptraced and if so, whether to
>> allow the transition.
>>
>> Signed-off-by: Stephen Smalley <stephen.smalley.work@gmail.com>
>> Acked-by: Casey Schaufler <casey@schaufler-ca.com>
>> ---
>> security/lsm_syscalls.c | 9 ++++++++-
>> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> Thanks Stephen. I'm going to merge this into lsm/stable-7.1 now, but
> hold on to it until next week before sending it to Linus. While I
> can't see why John would have any objections to this, the extra time
> should give him a chance to respond.
>
you would think?
well finally getting this far back the backlog (sorry)
no objections
^ permalink raw reply
* [PATCH] KEYS: avoid filesystem reclaim while holding keyring->sem
From: Mohammed EL Kadiri @ 2026-06-14 15:00 UTC (permalink / raw)
To: dhowells, jarkko, paul
Cc: jmorris, serge, ebiggers, keyrings, linux-security-module,
linux-kernel, stable, syzkaller-bugs, Mohammed EL Kadiri,
syzbot+f55b043dacf43776b50c
__key_link_begin() runs with keyring->sem held and calls
assoc_array_insert(), which does GFP_KERNEL allocations. Those
allocations may enter filesystem reclaim, evict an fscrypt-protected
inode, and reach keyring_clear() via fscrypt_put_master_key() --
taking a keyring semaphore of the same lockdep class and closing a
keyring->sem -> fs_reclaim -> keyring->sem cycle reported by syzbot.
Wrap the assoc_array_insert() call with memalloc_nofs_save() /
memalloc_nofs_restore() so reclaim cannot recurse into the keys
subsystem while keyring->sem is held.
Reported-by: syzbot+f55b043dacf43776b50c@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=f55b043dacf43776b50c
Fixes: d7e7b9af104c ("fscrypt: stop using keyrings subsystem for fscrypt_master_key")
Cc: stable@vger.kernel.org
Signed-off-by: Mohammed EL Kadiri <med08elkadiri@gmail.com>
---
security/keys/keyring.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/security/keys/keyring.c b/security/keys/keyring.c
index 5a9887d6b7be..21bb2e7e7cca 100644
--- a/security/keys/keyring.c
+++ b/security/keys/keyring.c
@@ -12,6 +12,7 @@
#include <linux/security.h>
#include <linux/seq_file.h>
#include <linux/err.h>
+#include <linux/sched/mm.h>
#include <linux/user_namespace.h>
#include <linux/nsproxy.h>
#include <keys/keyring-type.h>
@@ -1298,6 +1299,7 @@ int __key_link_begin(struct key *keyring,
struct assoc_array_edit **_edit)
{
struct assoc_array_edit *edit;
+ unsigned int nofs_flags;
int ret;
kenter("%d,%s,%s,",
@@ -1315,10 +1317,12 @@ int __key_link_begin(struct key *keyring,
/* Create an edit script that will insert/replace the key in the
* keyring tree.
*/
+ nofs_flags = memalloc_nofs_save();
edit = assoc_array_insert(&keyring->keys,
&keyring_assoc_array_ops,
index_key,
NULL);
+ memalloc_nofs_restore(nofs_flags);
if (IS_ERR(edit)) {
ret = PTR_ERR(edit);
goto error;
--
2.43.0
^ permalink raw reply related
* Re: [PATCH] lsm: hold cred_guard_mutex for lsm_set_self_attr()
From: Paul Moore @ 2026-06-14 20:25 UTC (permalink / raw)
To: John Johansen
Cc: Stephen Smalley, selinux, omosnace, casey, serge,
linux-security-module
In-Reply-To: <1c87912e-7d7c-49a9-b964-3568e63e74a0@canonical.com>
On Sat, Jun 13, 2026 at 7:29 PM John Johansen
<john.johansen@canonical.com> wrote:
> On 5/14/26 13:47, Paul Moore wrote:
> > On May 13, 2026 Stephen Smalley <stephen.smalley.work@gmail.com> wrote:
> >>
> >> Just as proc_pid_attr_write() already does before calling the LSM
> >> hook. This only matters for SELinux and AppArmor which check
> >> whether the process is being ptraced and if so, whether to
> >> allow the transition.
> >>
> >> Signed-off-by: Stephen Smalley <stephen.smalley.work@gmail.com>
> >> Acked-by: Casey Schaufler <casey@schaufler-ca.com>
> >> ---
> >> security/lsm_syscalls.c | 9 ++++++++-
> >> 1 file changed, 8 insertions(+), 1 deletion(-)
> >
> > Thanks Stephen. I'm going to merge this into lsm/stable-7.1 now, but
> > hold on to it until next week before sending it to Linus. While I
> > can't see why John would have any objections to this, the extra time
> > should give him a chance to respond.
> >
> you would think?
> well finally getting this far back the backlog (sorry)
>
> no objections
A review is almost always better late than never ;) Thanks for taking a look.
--
paul-moore.com
^ permalink raw reply
* Re: [PATCH v2 v2] evm: check return values of crypto_shash functions
From: Roberto Sassu @ 2026-06-15 7:25 UTC (permalink / raw)
To: Mimi Zohar, Daniel Hodges
Cc: roberto.sassu, dmitry.kasatkin, eric.snowberg, paul, jmorris,
serge, linux-integrity, linux-security-module, linux-kernel
In-Reply-To: <c1d570271884159e6c14617fa7dcd39bc2103e45.camel@linux.ibm.com>
On 3/9/2026 4:03 PM, Mimi Zohar wrote:
> On Thu, 2026-02-19 at 10:26 +0100, Roberto Sassu wrote:
>> On Thu, 2026-02-05 at 21:42 -0500, Daniel Hodges wrote:
>>> The crypto_shash_update() and crypto_shash_final() functions can fail
>>> and return error codes, but their return values were not being checked
>>> in several places in security/integrity/evm/evm_crypto.c:
>>>
>>> - hmac_add_misc() ignored returns from crypto_shash_update() and
>>> crypto_shash_final()
>>> - evm_calc_hmac_or_hash() ignored returns from crypto_shash_update()
>>> - evm_init_hmac() ignored returns from crypto_shash_update()
>>>
>>> If these hash operations fail silently, the resulting HMAC could be
>>> invalid or incomplete, which could weaken the integrity verification
>>> security that EVM provides.
>>>
>>> This patch converts hmac_add_misc() from void to int return type and
>>> adds proper error checking and propagation for all crypto_shash_*
>>> function calls. All callers are updated to handle the new return values.
>>> Additionally, error messages are logged when cryptographic operations
>>> fail to provide visibility into the failure rather than silently
>>> returning error codes.
>>>
>>> Fixes: 66dbc325afce ("evm: re-release")
>>> Signed-off-by: Daniel Hodges <git@danielhodges.dev>
>>
>> After fixing the minor issue below:
>>
>> Reviewed-by: Roberto Sassu <roberto.sassu@huawei.com>
>
> Thanks Daniel, Roberto. Daniel there are a couple of places where the line
> length is greater than 80. To see them, add "--max-line-length=80" to
> scripts/checkpatch.pl. I'd appreciate your fixing them. Otherwise, the patch
> looks good.
Daniel, do you have time to fix the style issues, so that we upstream
your patch?
Thanks
Roberto
^ permalink raw reply
* Re: [PATCH] keys: allow request-key path to be configured via Kconfig
From: Jarkko Sakkinen @ 2026-06-15 11:49 UTC (permalink / raw)
To: Gary Guo
Cc: David Howells, Paul Moore, James Morris, Serge E. Hallyn,
keyrings, linux-security-module, linux-kernel
In-Reply-To: <DJ5ES5DZ15W8.2KLL7VS1JMQOE@garyguo.net>
On Wed, Jun 10, 2026 at 02:37:41PM +0100, Gary Guo wrote:
> On Wed Jun 10, 2026 at 1:57 PM BST, Jarkko Sakkinen wrote:
> > On Mon, Jun 08, 2026 at 11:30:06AM +0100, Gary Guo wrote:
> >>
> >> This is really just for distros to be able to configure where /sbin is located.
> >> Given usr merge and (some distros) bin/sbin merge, the canonical path of
> >> request-key binary is very likely not /sbin/request-key anymore, so it seems to
> >> make sense to me to allow this to be changed rather than always go through
> >> compatibility symlinks.
> >
> > I doubt there's a huge demand other than NixOS. Just basing this on that
> > no other noise have been made so far.
>
> Just to add on this, both Fedora and openSUSE for example changes their
> CONFIG_MODPROBE_PATH to be /usr/sbin/modprobe after /usr merge. They still have
> the /sbin -> /usr/sbin symlink available, so it's not like they cannot work with
> /sbin/request-key, but I would think that if the option is available then they
> might switch to use /usr/sbin/request-key, too.
>
> After all, why would one perform a symlink walk for no reason?
>
> Best,
> Gary
It's not who is right or who is wrong. "The representation
of the argument" is not working here.
Back to the drawing board...
BR, Jarkko
^ permalink raw reply
* Re: [PATCH] keys: Pin request_key_auth payload in instantiate paths
From: Jarkko Sakkinen @ 2026-06-15 11:53 UTC (permalink / raw)
To: eee sss
Cc: keyrings, linux-security-module, linux-kernel, David Howells,
Paul Moore, James Morris, Serge E. Hallyn
In-Reply-To: <CA+TOyfjifw5yiZwUmd3y7t227cTMpXxT_JNe0FSO-NYzhqE75Q@mail.gmail.com>
Awesome, no worries, great to hear, and thank you for responding.
And great collaboration :-)
BR, Jarkko
On Wed, Jun 10, 2026 at 10:21:13AM -0500, eee sss wrote:
> Thanks, Jarkko. Sorry for the delayed response.
>
> I checked the commit in for-next-keys. The updated commit message and the
> cleanup look good to me.
>
> Best,
> Shaomin
>
> On Wed, 10 Jun 2026 13:16:01 +0300, Jarkko Sakkinen <jarkko@kernel.org> wrote:
> > On Mon, Jun 08, 2026 at 08:42:21AM +0300, Jarkko Sakkinen wrote:
> > > On Mon, Jun 08, 2026 at 08:29:11AM +0300, Jarkko Sakkinen wrote:
> > > > On Mon, Jun 08, 2026 at 06:10:23AM +0300, Jarkko Sakkinen wrote:
> > > > > On Mon, Jun 08, 2026 at 06:06:21AM +0300, Jarkko Sakkinen wrote:
> > > > > > On Tue, May 26, 2026 at 10:48:38AM +0800, Shaomin Chen wrote:
> > > > > > > keyctl_instantiate_key_common() reads request_key_auth from the assumed
> > > > > > > auth key before copying an instantiation payload from userspace. The copy
> > > > > > > can fault and sleep. If the request completes and revokes the auth key in
> > > > > > > that window, the auth payload can be detached and freed before the
> > > > > > > instantiate path uses it again.
> > > > > > >
> > > > > > > A request-key helper reproducer can trigger this race. One helper child
> > > > > > > blocks in KEYCTL_INSTANTIATE_IOV while the original helper instantiates the
> > > > > > > requested key and returns. KASAN then reports a use-after-free from the
> > > > > > > stale request_key_auth payload in keyctl_instantiate_key_common().
> > > > > > >
> > > > > > > Give request_key_auth payloads a refcount. Take a payload reference while
> > > > > >
> > > > > > Please, name concrete things accurately. I.e. 'usage' in this case. If
> > > > > > you have a name, use it instead of obfuscating generalizations.
> > > > > >
> > > > > > > authkey->sem stabilizes the payload and revocation state. Hold that
> > > > > > > reference across the instantiate and reject paths. Drop the auth key
> > > > > > > owning reference from revoke and destroy.
> > > > > > >
> > > > > > > Reported-by: Shaomin Chen <eeesssooo020@gmail.com>
> > > > > > > Closes: https://lore.kernel.org/r/20260519144403.436694-1-eeesssooo020@gmail.com
> > > > > > > Signed-off-by: Shaomin Chen <eeesssooo020@gmail.com>
> > > > > > > ---
> > > > > > > include/keys/request_key_auth-type.h | 2 ++
> > > > > > > security/keys/internal.h | 2 ++
> > > > > > > security/keys/keyctl.c | 24 +++++++++++++++-----
> > > > > > > security/keys/request_key_auth.c | 33 ++++++++++++++++++++++++++--
> > > > > > > 4 files changed, 53 insertions(+), 8 deletions(-)
> > > > > >
> > > > > > So first, couple of things.
> > > > > >
> > > > > > I'm not going to test not that well documented involving OOT driver.
> > > > >
> > > > > Oops, sorry typo. "not that well documented reproducer" :-)
> > > > >
> > > > > But it is cool we just then need to draw the picture.
> > > >
> > > > I think I got this:
> > > >
> > > > A: request_key() B: KEYCTL_INSTANTIATE_IOV
> > > > ---------------- -------------------------
> > > > create auth key
> > > > store rka in auth key
> > > > wait for helper
> > > > get auth key
> > > > load rka from auth key
> > > > copy user payload
> > > > sleep on #PF
> > > > helper completed
> > > > detach and free rka
> > > > destroy auth key
> > > > wake up
> > > > use rka->target_key
> > > > **USE-AFTER-FREE**
> > > >
> > > > So nothing really complicated here, is there?
> > >
> > > Send v2 with the code changes that I proposed as we want to the change
> > > as ergonomic as possible.
> > >
> > > Use this as the commit message:
> > >
> > > keys: Pin request_key_auth payload in instantiate paths
> > >
> > > A: request_key() B: KEYCTL_INSTANTIATE_IOV
> > > ---------------- -------------------------
> > > create auth key
> > > store rka in auth key
> > > wait for helper
> > > get auth key
> > > load rka from auth key
> > > copy user payload
> > > sleep on #PF
> > >
> > > helper completed
> > > detach and free rka
> > > destroy auth key
> > > wake up
> > > use rka->target_key
> > > **USE-AFTER-FREE**
> > >
> > > Give request_key_auth payloads a refcount. Take a payload reference while
> > > authkey->sem stabilizes the payload and revocation state. Hold that
> > > reference across the instantiate and reject paths. Drop the auth key
> > > owning reference from revoke and destroy.
> > >
> > > [jarkko: Replaced the first two paragraphs of text with a concurrency scenario.]
> > >
> > > And it includes also the remark at the end.
> > >
> > > BR, Jarkko
> >
> > Nothing heard so I pushed:
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd.git/commit/?h=for-next-keys&id=9feb0bb3468e863b2b82a2eabfaeec4c7c44b90c
> >
> > It has the commit message change.
> >
> > BR, Jarkko
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox