Page 472 - 《软件学报》2026年第3期

李志 等: 容器文件系统隔离增强机制 1435

因此容器内具有 SYS_PTRACE 特权的攻击者可以通过访问/proc/[crun-pid]/fd 来修改这个文件描述符指向的
文件, 即 seccomp.bpf 文件 (③). 这会导致禁用 seccomp 过滤, 从而绕过 seccomp 限制, 提升权限. 此外, 在 /proc/[crun-
pid] 目录下存在许多其他可能被利用的途径. 例如, 攻击者可以覆盖/proc/PID/map_files, 通过这种方式, 攻击者可
以从 non-rootless 容器中逃逸, 获得主机系统的访问权限.
这类与伪文件系统相关的漏洞很难通过容器工具彻底修复. CVE-2019-5736 漏洞与 Proc 文件系统相关, 容器
工具的修复只能阻止该漏洞的攻击, 而无法消除 Proc 文件系统中存在的攻击面. 漏洞补丁 (patch) 的原理是在
runC init 进程进入容器命名空间之前生成 runC 可执行文件的副本, 这样就能防止 CVE-2019-5736 利用宿主机中
真正的 runC 文件. “podman top”为了保护非特权容器, 为具有 SYS_PTRACE 特权的容器提供了专用代码, 却为漏
洞攻击提供了机会. Podman 团队目前给出的缓解方法是禁用特权命名空间, 限制容器权限, 但是在某些场景下需
要容器具有 SYS_PTRACE 特权以便能够跟踪和调试容器内的进程. 例如, 在开发和调试过程中, 当需要使用 gdb
或其他调试工具时, 容器需要 SYS_PTRACE 特权才能够跟踪调试其他进程.
此外, 与 cgroup 文件系统接口相关的漏洞 CVE-2022-0492 也无法通过容器工具消除. 它们的解决方案也只是
禁用特权用户命名空间, 降低容器的权限, 以避免 release_agent 文件被容器修改, 但这会影响容器运行. 最终, 为了解
决这个问题, 内核开发者发布了一个补丁 [40] , 对存在漏洞的 cgroup 文件系统接口进行了访问控制. 该补丁增加了一
段代码, 进程若想修改 release_agent 文件, 除了拥有 CAP_SYS_ADMIN 权限外还需要处于根命名空间中, 这意味着
仅仅通过 unshare 命令获得的 CAP_SYS_ADMIN 权限不再能够修改 release_agent 文件, 因为使用 unshare 创建的
新命名空间并不是根命名空间. 但是如果容器本身就存在 CAP_SYS_ADMIN 权限则还可以继续使用此方式逃逸.
2.4 总 结
如前所述, 本文的研究对象是主机和容器间交互产生的路径解析错误漏洞和主机文件描述符泄露漏洞: 攻击
者通过符号链接欺骗、非法文件执行或获得主机文件描述符等手段突破隔离限制, 最终实现容器逃逸.
本文根据不同攻击方式将路径解析错误漏洞分成了两类——符号链接解析欺骗漏洞与诱导非法文件执行漏
洞. 其中符号链接解析欺骗漏洞主要是由于容器将符号链接指向了非法位置, 容器工具解析符号链接时使容器访
问到主机上的敏感目录, 诱导非法文件执行漏洞的原理是主机进程执行了容器内的恶意文件. 现有的漏洞修复手
段局限在用户层, 可能引入高开销并且容易被绕过, 导致多年来类似的漏洞层出不穷.
文件描述符泄露漏洞通常与伪文件系统有关, 容器通过访问 Proc 文件系统内泄露的主机文件描述符直接访
问或操作相关的主机文件实现容器逃逸. 这类漏洞很难通过修改容器工具实现彻底修复, 目前的修复手段只能阻
止某一特定漏洞的攻击, 但无法从根本上消除 Proc 文件系统中的攻击面, 如果只是限制容器权限, 不仅可能影响
容器的使用, 而且如果容器本身具有此权限仍能利用该漏洞逃逸.
seccomp 或 AppArmor 也都无法解决这两类漏洞. 首先, seccomp 是一种针对系统调用的过滤机制, 而这两类
漏洞产生的核心原因不在于容器内的系统调用接口, 并且如果禁用涉及的系统调用 (如 open、write), 因为其过于
常见且必要, 会严重影响容器进程的正常文件操作. 其次, AppArmor 根据路径进行访问检查而非底层的文件
inode 来限制进程对敏感文件的访问, 只有当进程访问到配置文件中所列的敏感文件时才会记录该行为, 本身无法
根绝漏洞的产生, 且如果用户通过主机文件描述符访问文件, 会绕过文件路径校验环节.
现有容器文件系统隔离工作 [8,41] 能够解决部分问题. Patrol 在文件 dentry 上附加标签以进行跨命名空间文件
系统访问检查, 该类方法无法检测到文件描述符泄露漏洞, 通过文件描述符对文件进行操作的流程 (第 1.2 节) 不
会经过文件 dentry, 因此不会触发其访问控制策略. vKernel 利用文件 inode 的 i_opflags 位来标识是否敏感文件:
初始化时根据 AppArmor 配置文件识别敏感文件并设置访问权限哈希表; 访问文件时会拦截通用的权限检查函数
并检查 i_opflags 位. 这种方法对于敏感文件的设置没有脱离 AppArmor 的局限性, 只有在容器访问 AppArmor 配
置中的文件时才能发挥作用, 无法防御住诱导非法文件执行漏洞.

3 容器文件系统隔离增强机制设计和实现

从内核隔离层面来看, 这两类漏洞持续存在的根本原因是容器和主机间不完全的文件系统隔离. 如第 1.2 节