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

1428 软件学报 2026 年第 37 卷第 3 期

Abstract: With the widespread application of container technology, the security and isolation of containers have attracted significant
attention. Currently, a large number of container escape vulnerabilities persist in various container tools, with the security vulnerabilities
due to inadequate container file system isolation becoming a type of security threat that occupies a significant proportion. This kind of
vulnerability allows attackers to manipulate file path resolution processes within containers or steal file descriptors from the host machine
during interactions between containers and the host machine. Although multiple fix methods have been practiced by various container tool
communities, these vulnerabilities cannot be thoroughly eliminated, and even new similar vulnerabilities are introduced due to the
incomplete fix. It is necessary to improve container file system isolation mechanisms at the kernel level to thoroughly eliminate these
vulnerabilities. Therefore, this study proposes a fine-grained isolation enhancement mechanism for container file systems, which extends
container file system isolation from merely isolating file system mount points to the inode level. This mechanism involves marking the
inode of files within containers to distinguish the file objects of containers and the host machine, followed by designing and implementing
access control between containers and the host machine based on these markings to enhance file system isolation between containers and
the host machine. Experimental results demonstrate that this mechanism can effectively prevent all file system-related container escape
vulnerabilities, and the introduced average overhead is less than 2%, significantly lower than the overhead introduced by vulnerability
patches provided by container tools.
Key words: container security; vulnerability fix; container isolation; filesystem isolation; container escape
容器技术是一种操作系统级别 (OS-level) 的虚拟化技术, 可为云应用提供轻量、高效、标准化的运行环境,
广泛用于云原生服务的构建、测试与部署. 容器技术的实现依赖于多种 Linux 内核机制, 命名空间 (namespaces) [1]
[2]
和控制组 (cgroup) 两种机制是保障容器与宿主机间、容器与容器间隔离的基础. 命名空间为容器实例提供独立
[3]
的资源视图, 容器内文件系统挂载点 (mountpoint) 、网络设备及协议栈、进程间通信、用户组等资源经命名空
间隔离后仅容器中进程可见. 控制组用于统计与限制容器实例中的资源用量, 确保不会因单一容器消耗过多资源
而影响主机或其他容器. 然而, 命名空间与控制组对系统资源的隔离仍不完备, 引发了多种安全问题.
容器逃逸是一类典型的安全问题, 由于容器与宿主机间文件系统隔离不彻底, 文件路径解析错误和文件描述
符 (file descriptor) 泄露等两类漏洞常被利用于容器逃逸. 这两类漏洞在流行的容器工具中占据相当高的比例, 包
[4]
[5]
[7]
括 Docker 、Podman 等管理引擎, Containerd 等运行时 (runtime) 和 Kubernetes 等容器编排引擎. 据统计, 常用
[6]
的容器工具 2017–2023 年报告的 27 个高危性漏洞中有近一半是文件路径解析错误漏洞 [8] . 路径解析错误漏洞指
容器中的攻击者能够在容器工具访问容器内文件时将目标文件替换为符号链接 (symbolic link, symlink), 诱导容器
工具解析并访问符号链接所指向的宿主机文件, 从而实施逃逸. 例如, 当容器用户请求 Docker 将特定文件 (user-
file) 复制到容器中指定路径 (container-dir) 时 (docker cp user-file [container-ID]:/container-dir), 实施复制行为的
Docker 进程会以宿主机的上下文解析容器中的路径 (container-dir), 若容器中的攻击者将该路径 (container-dir) 替
换为一个指向敏感路径 (如/etc/passwd) 的符号链接, Docker 进程则会将容器用户指定的文件 (user-file) 复制到符
号链接所指向的宿主机目录, 从而覆盖目录中的重要文件 [9] . 文件描述符泄露漏洞主要源于攻击者在容器中获得
了泄露在容器环境的主机文件的文件描述符, 然后利用该文件描述符进行逃逸. 具体而言, 攻击者可以在宿主机进
程与容器交互时从容器内部获取宿主机进程所打开文件的文件描述符, 进而通过该文件描述符访问和修改主机上
的文件, 破坏了容器与主机之间的隔离性.
当前容器工具对上述两类漏洞的修复方案并未彻底解决问题, 这不仅带来了显著的性能开销, 同时容易被绕
过, 进而引发了多个新漏洞. 例如 CVE-2021-25741 漏洞 [10] 的成因就与上段介绍的 CVE-2017-1002101 的修复方案
密切相关. 这是由于修补手段通常针对某一特定漏洞, 没有涉及漏洞产生的根本原因. 经过对漏洞成因的剖析后发
现, 形成上述两类漏洞的根本原因在于容器和主机间文件系统的不完全隔离. 当前文件系统的隔离设计只隔离了
不同挂载命名空间 (mount namespace) [11] 的挂载点视图, 这种隔离手段并未能防止通过虚拟文件系统 (virtual
filesystem, VFS) 层次进行的路径解析过程中的漏洞利用. 只要能通过 VFS 访问文件的步骤将访问路径转化为文
件索引节点 (inode) 或是通过文件描述符直接获取文件对应的 inode, 内核便允许对相关文件的访问. 这种机制在
某种程度上为攻击者提供了绕过隔离的可能性, 使得路径解析错误与文件描述符泄露漏洞成为一种持久且难以彻
底根除的安全威胁.