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

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


                 图中运行.
                    挂载命名空间是容器隔离的重要机制之一. 它允许每个容器拥有独立的挂载点视图, 使容器内的文件系统操
                 作不影响主机或其他容器. 创建一个新挂载命名空间时, 会复制当前命名空间的挂载点列表, 之后任何在该新命名
                 空间内进行的挂载或卸载操作都不会影响其他命名空间. 也就是说, 挂载命名空间实际上隔离的是文件系统挂载
                 点, 使得进程只能看到属于其命名空间的挂载点. 当容器引擎                  (如  Docker 或  Podman) 启动一个容器时, 会为其创建
                 一个新的挂载命名空间. 容器内的文件系统布局               (如根文件系统、挂载的卷) 可以与主机完全不同.
                    chroot 系统调用通过更改程序的根目录, 确保进程只能看到并访问新的根目录及其子目录. chroot 将进程的根
                 目录更改为指定目录, 使进程不能访问该目录之外的文件系统部分. 通过改变根目录, 进程被限制在新的文件系统
                 视图中, 无法访问主机的其他部分. 设置           chroot 环境不改变实际系统文件, 又能实现安全隔离, 因此在容器化环境
                 中用于隔离文件系统.
                    创建和隔离容器文件系统的过程如下. 逻辑容器创建并启动后, 从容器镜像                       (image) 中提取根文件系统     (rootfs)
                 挂载到容器运行根目录下以          ID  为名的容器工作目录      (/var/lib/docker/containers/[ 容器  ID]). rootfs 包含了系统运行
                 有关的文件、配置和目录, 但不包括系统内核. 然后调用设置                   CLONE_NEWNS  参数的   clone 系统调用, 创建一个
                 新的挂载命名空间, 准备挂载文件系统. 新的挂载命名空间从当前命名空间复制挂载点列表, 意味着容器进程此时
                 仍然可以看到主机中的所有挂载点, 这显然达不到预期的隔离要求. 因此还需要利用类似                             chroot 的  pivot_root 系
                 统调用将容器的根目录切换到           rootfs, 确保容器只能访问当前根目录及其子目录, 无法访问主机的其他路径, 至此
                 文件系统隔离完成.
                    除了上述的资源视图隔离方法外, Linux           内核本身也引入了一些安全模块来进行安全检查, 如                  seccomp [15] 和
                 AppArmor [16] . seccomp  主要用来限制某一进程可用的系统调用, 通过编写特定格式的过滤器, 可以对进程执行的
                 系统调用的系统调用号和参数进行检查和过滤. 通过禁止进程调用不必要的系统调用, 减少了内核暴露给用户态
                 进程的接口数量, 从而减少了内核攻击面. Docker 启动时会启用默认的                  seccomp  配置文件, 仅保留部分    Linux  中较
                 为常见且安全的系统调用. 而         AppArmor 通过内核安全模块实现强制访问控制——在自主访问控制之上, 进一步
                 将程序限制在有限的资源集中. 管理员可以为每个进程制定详细的访问控制策略, 以限制对文件、网络资源等接
                 口的访问.
                    目前的容器工具主要依赖于挂载命名空间和安全模块检查来实现文件系统隔离, 辅以不同的隔离技术. 例如,
                 大多数容器工具通过默认不授予容器             CAP_SYS_ADMIN  能力  [17] 来防止容器用户进行系统管理员操作, 如挂载或
                 卸载文件系统等, 限制了受感染的容器对主机的威胁. 此外, Docker 还采用了一种写时复制                       (copy on write) 文件系
                 统  [18] 来保证不同容器间的数据隔离. 当多个容器共享同一镜像时, 只有容器对文件进行写操作时, 才会在容器对
                 应的文件系统内生成文件副本, 并对副本进行修改, 不影响镜像源文件. 但是基于目前的隔离手段, 仍有很多漏洞
                 利用容器和宿主机交互过程绕过容器与宿主机间的隔离, 给主机带来了安全威胁.

                  2   容器漏洞与修复

                  2.1   威胁模型
                    在现代化的云计算和微服务架构中, 容器技术作为轻量级的虚拟化解决方案, 允许多个容器在单一宿主机操
                 作系统上共存. 每个容器都拥有独立的文件系统、网络空间以及进程空间, 这种隔离性为多租户环境提供了必要
                 的安全屏障. 云平台中容器工具          (如  Docker、Podman  或  runC [19] ) 负责管理容器实例从创建到销毁的整个生命周
                 期. 本文的讨论基于一个基本假设: 云平台中宿主机操作系统及容器工具等核心组件均是可信的, 并能正确实施容
                 器实例生命周期的管理. 但云平台无法杜绝外部攻击者利用容器中服务的漏洞入侵容器实例、恶意用户通过正常
                 的接口部署包含恶意代码的容器实例. 攻击者和恶意用户拥有在受感染/恶意容器实例内执行任意代码的能力, 可
                 以操纵容器实例中的进程、文件系统以及网络配置. 恶意用户与正常用户一样可以通过云平台提供的                                  API 与容器
                 实例进行交互, 如请求容器工具将指定文件复制到容器实例中. 攻击者/恶意用户的最终目标是打破容器的隔离边
   463   464   465   466   467   468   469   470   471   472   473