Page 474 - 《软件学报》2026年第3期
P. 474

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


                 强机制成为系统的一部分, 而非负担, 确保在提升安全性的同时, 系统的稳定性和兼容性不受损害. FCFS                            能够在不
                 改变用户空间应用程序行为并且不更改任何硬件的同时实现安全保护.
                    ● 挑战  3: 性能
                    在无服务器计算场景下, 性能是衡量方案优劣的重要指标. 云服务提供商和用户均期望在享受容器带来的敏
                 捷性与灵活性的同时, 无服务器功能能够实现瞬时部署, 且运行时的安全检查不应成为性能的绊脚石. 因此必须精
                 心设计隔离机制, 确保在提供坚实隔离保障的同时, 不牺牲内核的响应速度和执行效率. 这意味着既要确保安全
                 性, 也要兼顾性能, 使安全防护与高效运行并驾齐驱. FCFS              将渲染过程和访问控制集成到           Linux  路径查找过程中,
                 尽量减少冗余代码, 将性能开销降至最低.
                    下面详细介绍本文提出的容器文件系统隔离增强机制的设计和具体实现.
                  3.1   静态渲染
                    在容器初始化过程中, 需要识别          VFS  中容器文件系统的      inode 对象, 并区分容器文件系统和主机文件系统中
                 的  inode 对象. 这种识别对后续的访问控制至关重要. 这一过程还必须考虑到容器与宿主机之间以及容器之间的
                 文件共享机制, 因为许多现有的容器工具提供了“shared volume”接口               (如“docker run -v”), 允许容器之间或主机与
                 容器之间共享文件. 共享卷允许跨容器甚至与宿主机进行数据交换, 打破了容器原本的封闭边界, 需要额外的安全
                 考量.
                    因此在考虑实际的容器文件访问场景时, 需要设计一套多层次的安全策略, 定义多个安全级别. 具体来说, 可
                 以将目标文件分为       3  类: 容器文件系统内的文件、宿主机文件系统上的文件以及在宿主机和多个容器间共享的文
                 件. 每类文件对应不同的安全级别: 在上述威胁模型中                (第  2.1  节), 容器可能由攻击者操纵, 是不可信的, 所以必须
                 对每个容器的文件系统采用最严格的访问控制策略, 将容器文件的风险等级视为最高, 即安全级别最低; 主机文件
                 被认为是安全的, 具有最低的风险等级            (即最高的安全级别), 只能由主机进程访问; 作为容器文件系统的延伸, 共
                 享卷允许跨容器或与宿主机的数据共享, 因此需要在运行时设置标签以区分有权限访问共享卷的主体, 可以认为
                 其安全性介于容器和宿主机文件之间.
                    其次引入了安全域的概念, 它是一组受特定安全策略约束的                    inode 集合, 属于容器文件系统或共享卷. 为了区
                 分不同的安全域, 在现有的        PID  命名空间结构上进行了扩展——增加了一个枚举类型的变量“security_level”, 用于
                 表示  inode 的所属安全级别. 该标志包含       3  个预定义的值: “strict (−2)”“normal(0)”和“shared(−1)”, 分别对应上述提
                 到的  3  种文件类型. 此外还在     inode 结构中新增一个指向      PID  命名空间的指针, 以此来标识当前         inode 所属的命名
                 空间. 这种渲染策略可以利用命名空间区分不同的容器, 判断文件的危险级别, 防止主机和容器之间的非法访问.
                    作为容器启动初始化过程的一部分, pivot_root 函数将容器进程的根目录切换到容器自身的                         rootfs, 即容器的
                 根文件系统, 这一流程标志着容器环境的创建完成. 切换                 rootfs 成功后, 根据设计, 会从目标目录开始递归地遍历
                 其下的所有    dentry. 系统会追踪每一个     dentry  中指针指向的   inode, 并对其进行标记. 如果遇到的       dentry  是一个挂
                 载点, 即容器文件系统中被映射到其他文件系统的一个特殊目录, 那么, 不仅是这个挂载点, 连同其下整个文件系
                 统的  inode 也需被标记. 容器内    inode 的安全级别标志被设定为“strict”. 这些     inode 的访问将受到最严格的控制, 任
                 何试图访问它们的尝试都将受到严密的检查, 以确保容器的隔离性. 主机文件系统                          inode 分配“normal”, 即被认为
                 是安全的. 然而并非所有的        inode 都能如此简单地划归到容器内部或主机文件系统. 在处理共享卷时, 系统会采取
                 一种更为灵活的策略. FCFS       将共享卷分配到一个专门为共享卷准备的临时                 PID  命名空间中, 并将其安全级别标
                 志设置为“shared”. 在特定条件下容器和宿主机可以访问共享卷, 但这种访问同样受到严格控制, 以防止未经授权
                 的访问和数据泄露. 后文图        6  展示了  3  类目标文件的静态渲染结果.
                  3.2   路径查找渲染
                    在主机进程与容器之间的交互中, 仅依靠基于初始                 PID  命名空间的   inode 标识不足以进行访问控制. 因为静
                 态渲染虽能为文件系统中的          inode 附上标签, 却无法捕捉到路径查找过程中动态变化的情况. 路径查找可能跨越
                 容器与宿主机之间的命名空间, 识别并评估这一过程中的安全风险尤为关键. 如果主机进程访问一个指向主机上
   469   470   471   472   473   474   475   476   477   478   479