在过去的几年里，可以用来创建容器而不需要特权的各种内核特性已经取得了相当大的进步。如今，大多数容器都以 root 身份运行，这意味着导致从容器中逃逸的漏洞可能会导致系统受损。Stéphane Graber 在 2022 年欧洲 Linux 安全峰会(LSS EU) 上发表了演讲，详细介绍了他和其他人在将容器作为非特权代码运行时所做的一些工作细节。
正如克里斯蒂安·布劳纳（Christian Brauner）计划共同出席的那样，演讲原定有两位发言人；不幸的是，布劳纳在会议期间陷入了困扰都柏林的旅行困境，并且在谈话时正在机场等待他的飞机回家。该演示文稿是他们6 月份在北美 LSS上关于非特权容器的系统调用拦截的讨论的后续 。Graber 是我们最近关注的LXC和LXD容器项目的项目负责人；Brauner 是一名内核开发人员，也是 LXC/LXD 的维护者之一。
用户命名空间
演讲的标题是“用户命名空间中的新功能”，但内容更广泛一些。Graber 首先简要介绍了用户命名空间，该命名空间由 Eric Biederman 于 2013 年添加到内核中；他们“在这一点上已经接近十年了”。简而言之，用户命名空间允许进程及其后代将命名空间内的用户 ID (UID) 和组 ID (GID) 映射到托管命名空间（即“根命名空间”）的真实 Linux 系统中的不同值。所以命名空间可以有一个 UID 0，因此看起来和行为就像命名空间内的 root 用户，它实际上映射到系统上的非特权 ID。
[斯蒂芬·格雷伯]
普通用户可以创建自己的用户命名空间，并将自己的UID/GID映射到命名空间内的root用户；任何更复杂的事情都需要使用特权帮助程序来映射命名空间的 ID 范围。他说，这类似于网络命名空间，它在创建时没有网络设备，需要特权助手在非特权网络命名空间内创建（大多数）网络设备。他做了一个快速演示，展示了使用unshare 命令创建用户命名空间，该命令使用-r选项将他的 UID 映射到命名空间内的根目录。
但是，通常情况下，容器需要的不仅仅是该示例中的单 ID 映射。POSIX 真的希望有 64K 的 UID 和 GID 可用，并且需要有一个“nobody”用户和“nogroup”组，这样事情才能按预期工作；他说，通常将整个范围的 64K ID 映射到用户命名空间中。此外，容器可能需要额外的命名空间，包括mount、进程 ID (PID)、UTS（主要用于单独的主机名）、网络和控制组 (cgroup) 命名空间。根据容器的用例，命名空间类型的一些混合和匹配可能是有意义的。
如前所述，通过使用特权助手（privileged helper）（或者，当然，将命名空间设置为 root），用户命名空间可以映射多个 ID，直至整个主机系统的 ID 范围。可以创建一个实际上没有映射的命名空间，因为它将每个主机 ID 映射到命名空间中的一个 ID，但这不是一个好主意。“你永远不应该将真实的 UID 0 映射到任何东西”在用户命名空间内。
命名空间内的 UID 0 看起来拥有 root 用户的所有权限，但事实并非如此，当然，至少对于主机系统而言是这样。例如，所有 Linux 功能都将授予命名空间内的该 root 用户，但它们对主机系统无效。is_capable () 内核功能检查将仅使用主机映射的 UID 来确定功能；is_ns_capable ()将改为报告命名空间中看到的功能。
他说，如果要在同一主机上运行多个容器，则将每个容器映射到自己的 64K ID 集会提供更好的安全性。这样，如果对特定主机 ID 应用了资源限制，则容器不会对共享该主机 ID 的其他容器造成拒绝服务。Graber 演示了使用 LXC 创建两个具有非重叠 ID 的容器。
文件系统（Filesystem）问题
虽然 ID 映射在命名空间内部，但文件系统对事物的看法却截然不同；它使用主机 ID 进行权限检查和写入文件所有权的 ID。对于具有真实（而不是虚拟）文件系统的用户命名空间来说，这是一个长期存在的问题。一些挂载在挂载和用户命名空间组合内的文件系统，例如 tmpfs 或 FUSE，实际上确实使用映射的 ID，但访问使用不同 ID 编写的现有文件系统仍然存在问题。在多个容器之间共享文件系统也很困难。
解决问题的第一个尝试是shiftfs（“有时我们会忘记 ‘f’，第一个”，他笑着说）。它由 James Bottomley 创建，然后由 Graber 在 Canonical 的团队接手；它没有合并到主线，但它仍然在一些 Ubuntu 版本中提供，因为主线解决方案（接下来的讨论）还不适用于所有感兴趣的文件系统。Shiftfs 的功能很像允许重新映射 UID 和 GID的覆盖文件系统（overlay filesystem）。他说，它存在许多问题，尤其是在处理特定于文件系统的ioctl()命令以及与各种虚拟文件系统 (VFS) 层缓存的交互方面；这些问题清楚地表明 shiftf 的做法"不是正确的做法"。
Graber 说，解决这个问题的正确方法是使用 由 Brauner 开发的ID-mapped mounts 。大部分功能都在 VFS 层实现，但个别文件系统确实需要更改以支持它；目前，ext4、XFS、Btrfs、VFAT、F2FS、overlayfs，可能还有一些其他文件系统支持它。ZFS 和 Ceph 也都处于挂起状态，但目前不支持任何网络文件系统。ID-mapped mounts 在 VFS 层干净利落地解决了这个问题，因此 shiftfs 遇到问题的边缘情况可以顺利处理。
新命名空间
Graber 说他前几天参加了 Linux Plumbers Conference (LPC) 及其内核峰会。他进一步了解了即将推出的新命名空间。有一种趋势是，新的命名空间不会被开发为具有自己的标志的成熟命名空间clone()，而是将它们挂在用户命名空间之外。他说，它们成为可以为给定用户命名空间启用的功能，更易于实现和使用。
其中第一个是完整性测量架构（IMA）命名空间，它已经进行了一段时间的工作；其补丁集的第 14 版已在演讲当天上午发布。它将允许在容器中使用 IMA，以便可以测量容器中使用的每个文件以确保其完整性。不同的命名空间也可以有不同的 IMA 策略。
Graber 说，另一个新的命名空间是由 LPC 的 Mathieu Desnoyers 描述的跟踪命名空间。它将允许在容器内运行一些跟踪工具，这将非常有用，但实现起来会“有趣”。很难使其安全使用，因此这种功能可能需要随着时间的推移而增长；一些简单的东西会在开始的时候允许，其他的会慢慢添加。
再次换档，Graber 说社区中存在关于如何限制用户命名空间功能的问题。它已经存在了近十年，最近发现的错误不在用户命名空间代码中，而是在内核的其他地方，只是被该功能暴露出来，但它仍然是攻击面的增加. 因此，人们正在寻找限制其使用的方法。
没有将功能编译到内核中是一个“大锤”，但现在这并不可行，因为越来越多的应用程序正在使用用户命名空间。可以对可以创建的用户命名空间的数量设置资源限制，但这是系统范围的设置，而不是每个用户或每个进程。类似地，可以使用seccomp() 过滤器来限制可以进行的系统调用，但 seccomp()不能根据 clone3()的指针参数进行过滤， 因此该技术也不是真正可行的。各种发行版都通过sysctl添加了自己的控件，但这些不在主线中。
已经有一些工作为创建用户命名空间添加了一个安全模块钩子，这将为 SELinux 和其他模块提供一种对操作进行判断的方法。这种方法对 Linux 安全模块 (LSM) 社区和其他人来说是有意义的，但作为命名空间维护者的 Biederman 不同意。Graber 说，他不希望看到为用户命名空间添加更多限制，但也许他可以被说服，或者更通用的机制可以通过。他希望看到发行版和其他发行版对用户命名空间的使用有更细粒度的控制，因此他希望问题能尽快得到解决。
他花了一些时间回顾了他和 Brauner 在 LSS NA 上展示的系统调用拦截工作。一般的想法是，他们有一个特权进程，通过seccomp()调解对容器的特权系统调用。他们希望以这种方式启用的一些操作听起来“可怕”，例如内核模块和 BPF 程序加载，或挂载文件系统，但其目的是仅在受信任的资源上执行这些操作。
受信任的资源是主机系统信任的资源，因为它知道内容没有被不受信任的用户修改。例如，容器可能会请求特定的 netfilter 内核模块，因此容器管理器将检查该模块以查看它是否是受信任的模块之一。容器传递的模块“绝对不会被加载”，但如果容器在受信任模块列表中，管理器可以加载容器请求的模块的主机副本。
最后，Graber 说引入 ID 映射挂载是采用用户名空间和容器的“游戏规则改变者”。多年来，缺乏该功能意味着 Docker 和 Kubernetes 容器通常必须是特权容器；由于这些构成了绝大多数容器，因此非特权容器的使用很少。但是随着 ID 映射挂载功能的推出，Docker 风格的分层文件系统上的 ID 问题将会消失，因此未来会有更多非特权容器使用的希望。“也许再过十年，没有人会再使用特权容器了……也许”。
他还认为，作为用户命名空间一部分的命名空间的新模型很有意义。它有助于减轻审查负担，并应允许添加更多有趣的命名空间。seccomp ()系统调用拦截也令人兴奋，因为它允许解决非特权容器存在的一些限制。未来似乎是光明的。
[我要感谢 LWN 订阅者支持我前往都柏林参加欧洲 Linux 安全峰会。]