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

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


                 的内核变量和数据结构实例, 从而导致对其他容器的                 DoS  攻击. 他们还在多个共享内核容器环境中进行了攻击实
                 验, 结果表明所有环境都容易受到抽象资源攻击.

                                                                 80
                            FCFS                   183.12  203.71  60  71.83  66.73  64.48      FCFS
                     Normalized overhead (%)  160  86.96  93.81  104.74  138.14  153.15  Normalized overhead (%)  40  42.45  33.1  21.84
                                                                                                Patches
                            Patches
                      200
                      120
                       80
                       40
                          3.01  7.31    1.84  1.96  1.66  3.37   20  1.37  1.25  1.12  1.37  1.2  1.24  1.36 18.48
                        0          0.18                           0
                           1 MB 5 MB 10 MB 50 MB 100 MB500 MB 1 GB   1 MB 5 MB 10 MB 50 MB 100 MB500 MB 1 GB
                                    (a) docker cp 开销                          (b) podman cp 开销
                                       图 13 docker cp  和  podman cp  的开销与  FCFS  开销对比

                    Jian  等人  [49] 研究了  Docker 的容器逃逸攻击并试图在进程执行过程中基于命名空间状态检查来解决逃逸攻
                 击. 他们认为, 攻击者程序获得了         root 访问权限后会尝试更改命名空间, 因此提出的解决方案会检测命名空间状
                 态, 并标记可能表明容器遭到入侵的任何更改, 这有助于检测异常并进一步防止逃逸攻击, 但是并不能提高容器隔
                 离的完整性. Wang    等人  [50] 从页面缓存隔离入手, 提出将页面缓存分为私有缓存和共享缓存两种, 并利用技术精准
                 控制两种页面缓存, 增强容器的内存隔离能力. Abbas 等人              [51] 提出的跨命名空间检测方法可以识别大多数已经存
                 在的符号链接欺骗漏洞, 但是在检测到威胁后               PACED  不会采用任何相关的防御策略来保护系统, 并且不能从根
                 本上消除此类恶意攻击. Li 等人        [8] 尝试增强容器文件系统的隔离, 但是只涉及           dentry  层, 当攻击者通过主机文件描
                 述符访问文件时, 不需要经过         dentry  安全检查, 不会触发   Patrol 的访问控制策略, 也即无法防御住主机文件描述符
                 泄露漏洞. vKernel [41] 根据  AppArmor 配置文件来标识文件    inode 是否是敏感文件, 在容器访问文件时拦截通用的
                 权限检查函数并检查访问对象是否敏感文件. 这种方法只有在容器访问                        AppArmor 配置中的文件时才能发挥作
                 用, 无法防御如    CVE-2019-14271  这类原理是宿主机进程被欺骗执行了容器内的恶意文件的漏洞. 而                   FCFS  能够精
                 准判断出文件属于主机还是容器, 利用            inode 标签和访问控制策略杜绝了容器越权访问主机文件、主机进程被欺
                 骗执行恶意容器文件等漏洞的产生, 对跨命名空间文件访问进行全面、严格的权限检查, 守护主机容器的交互行
                 为安全, 并且不需要修改任何硬件.
                    容器社区还提出了安全容器的方案来隔离内核漏洞, 比如                    Kata 容器  [52] 和  gVisor [53] . Kata 容器通过硬件虚拟
                 化来达到容器隔离, 它在虚拟机实例内运行容器实例. 虚拟机保证了强大的隔离性, 同时对客户机内核进行了修
                 剪, 以减少性能开销. 但是      Kata 容器的隔离仍然存在问题. 它不强制执行设备              cgroup, 攻击者有机会访问客户机虚
                 拟机上的 /dev  文件  [54] . Yang  等人  [55] 提出  Kata 运行时不检查共享卷中挂载点的有效性, 容器内的攻击者可以利用
                 多个漏洞实施攻击, 例如伪装成          Kata-agent 并在挂载点创建符号链接, 将新容器的根文件系统挂载到符号链接指
                 向的主机上的任何位置. 尽管         gVisor 容器通常采用的虚拟文件系统无法直接从主机访问, 但容器和主机之间的共
                 享卷驻留在主机文件系统上. 当容器工具利用复制功能将符号链接文件从                        gVisor 容器复制给其用户时, 该卷中存
                 在的恶意符号链接将在主机上解析, 从而可能导致主机文件泄露. 因此为了守护主机和容器交互的安全性, 需要设
                 计和实现更稳健的文件系统隔离机制.
                  6   总结及未来工作

                    容器依赖于命名空间和         cgroup  来实现隔离, 但容器与宿主机之间的文件系统隔离仍然存在安全漏洞, 例如路
                 径解析错误漏洞和文件描述符泄露漏洞. 本文介绍了一种文件描述符泄露漏洞的攻击过程, 并分析了上述两类漏
                 洞的修复手段, 认为在容器工具层面无法根本性地解决问题. 为此提出了一种基于内核的容器文件系统隔离机制
                 FCFS, 将文件系统隔离拓展到        inode 级别, 实现更细粒度的隔离, 并不需要修改任何硬件. 此外还通过测试验证了
   476   477   478   479   480   481   482   483   484