procfs路径重定向为何危险?

procfs 路径重定向的危险，不在于容器简单获得了某个额外权限，而在于它可能改变宿主机运行时“实际写入了什么”。容器启动时，runC 会通过 /proc/self/attr/ 相关接口为初始进程设置 LSM 安全标签。若攻击者利用竞态条件、符号链接或共享挂载，在路径检查与写入之间改变目标，runC 以为自己正在写入安全属性，实际却可能把内容发送到另一个 procfs 接口。

从“设置标签”到影响内核状态

这构成了一条特殊的攻击链：攻击者先影响容器中的挂载或路径布局，再干扰 runC 代表宿主机执行的初始化操作。即使运行时确认目标属于 procfs，也不能证明目标仍是预期的 LSM 属性接口，更不能证明写入不会触发其他内核行为。

例如，/proc/sysrq-trigger 是具有高影响力的内核控制接口。若写入被重定向到这里，可能造成宿主机拒绝服务；具体结果仍取决于内核配置、权限控制以及写入内容是否能被接口识别。/proc/sys/kernel/core_pattern 同样需要重点审计，因为它影响进程崩溃时核心转储的处理方式。若其配置被篡改，后续崩溃可能引发信息泄露、拒绝服务，或在特定条件下扩大宿主机影响。

因此，procfs 安全检查至少包含三层：确认目标属于 procfs，确认路径完整性未被竞态改变，以及评估目标接口的语义风险。只做文件类型检查，无法阻止“真实的 procfs 文件之间”发生危险重定向。

风险判断不能只看容器权限

CVE-2025-52881 的关键影响因素包括底层 runC 版本、共享挂载策略，以及宿主机对敏感 procfs 接口的暴露程度。受影响版本包括 1.2.7、1.3.2 和 1.4.0-rc.2，对应修复版本分别为 1.2.8、1.3.3 和 1.4.0-rc.3。使用 Docker、containerd、CRI-O 或 Kubernetes 时，不能只查看业务镜像版本，而应确认节点实际携带并调用的 runC 版本。

防御应先完成运行时升级，再收紧特权容器、额外 capabilities、宿主机目录共享和可变挂载结构。与此同时，应将 /proc/sysrq-trigger、core_pattern 与 /proc/self/attr/ 纳入节点基线，持续核验 LSM 标签是否按预期应用。只要仍存在未修复节点，容器隔离就不应被视为可靠的宿主机边界。