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

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

中所述, 容器文件系统通常通过挂载命名空间和 pivot_root 提供一定程度的隔离, 但它们并不能完全覆盖所有
VFS 对象, 比如文件描述符和 inode. 内核解析用户空间的文件路径后无法区分 inode 对象是否属于容器, 即使访
问可能是通过非法通道 (如“/proc/self/exe”) 进行的, 只要能顺利得到文件 inode 对象便会允许访问. 这种不完全的
隔离意味着如果该进程不受安全检查限制, 则可能将容器文件系统视为受信任的环境. 因此, 为了完全消除风险,
必须重构内核的文件系统隔离机制.
虽然内核中有各种可跨容器共享的文件相关的结构, 例如 dentry、fd_array 等, 但是经过对第 1.2 节中文件操
作流程的分析, 无论是以路径名还是文件描述符对文件进行操作, 最终都需要得到该文件的 inode 对文件进行真
正的操作, 所以从 inode 层面对内核文件系统进行隔离是更深层更有效的方式. 具体来说, 为了提供更精细的控制,
需要将文件系统隔离扩展到 VFS 中的 inode 对象, 确定每个 inode 是属于容器文件系统还是属于主机. 然后, 这种
扩展的隔离机制可以基于进程和 inode 属性强制执行访问控制策略, 以防止容器和主机之间的非法访问. 通过实
现这些措施可以提高容器环境的整体安全性. 这种方法从问题的根源入手, 不仅能消除现有漏洞, 还能预防未来可
能出现的新型攻击.
为了彻底解决容器与主机交互过程中存在的符号链接解析欺骗漏洞以及文件描述符泄露漏洞, 本文提出了一
种增强的容器文件系统隔离机制 FCFS, 其架构如图 5 所示. FCFS 首先通过在文件系统内的文件 inode 上附加特
定标签, 将隔离的范畴进一步延伸至文件 inode 层级, 将该过程称为“静态渲染”, 它赋予文件 inode 以身份标识, 从
而初步区分出文件属于主机环境还是容器文件系统. 又由于在实际运行时, 主机进程可能进入容器文件系统, 面临
被恶意攻击者诱导访问恶意符号链接的风险, 进一步引入了“动态路径查找渲染”的概念. 这一机制会在路径解析
的过程中动态调整对 inode 的访问权限, 确保即便在运行环境中, 也能精准控制对每个 inode 的访问. 在经过了静
态和动态渲染后, 内核可以准确分辨文件 inode 属于主机还是容器文件系统. 基于这种能力, FCFS 能够制定并实
施合适的访问控制策略, 有效阻止试图跨越文件系统的恶意攻击行为. 将渲染过程和访问控制嵌入到 Linux 提供
的路径查找过程中, 强化隔离效果的同时还确保了整个过程的透明度和一致性, 使隔离措施成为系统运行的有机
组成部分, 而不是一个附加的独立安全层.

限制对象
访问结果
添加标记 路径查找 访问控制策略
静态渲染 动态渲染
限制控制
转移行为

图 5 FCFS 隔离机制生效流程

为了有效增强容器文件系统隔离, 需要面对并解决以下挑战.
● 挑战 1: 安全性
首要目标是彻底解决容器与主机交互过程中与文件系统有关的漏洞, 希望从根本上消除可能存在的风险, 不
仅能够防御现有攻击, 还能防止该类问题再次出现. 所以文件系统隔离方案应该能够隔离恶意符号链接, 并保护主
机的文件描述符, 对跨命名空间文件访问进行全面、严格的权限检查, 守护主机容器的交互行为安全. FCFS 从文
件 inode 层有效识别主机文件和容器文件, 加以访问控制策略, 能够有效保护主机文件, 防御容器和主机交互过程
中的恶意行为.
● 挑战 2: 兼容性
Linux 内核设计的一大核心原则是保证兼容性, 这确保了软件与硬件之间的无缝协作, 消除了技术壁垒. 因此
应该为用户应用程序提供透明的保护, 无需对容器工具或容器内的用户空间应用程序做任何修改. 保证在不影响
用户层活动的情况下快速部署隔离增强机制, 同时保持系统原有功能的完整性和操作的流畅性. 目标是让安全增