LWN：针对用户命名空间的安全模块hook！

关注了就能看到更多这么棒的文章哦～

A security-module hook for user-namespace creation

By Jonathan Corbet
August 4, 2022
DeepL assisted translation
https://lwn.net/Articles/903580/

Linux 安全模块（LSM）子系统的基本工作机制就是在内核中各个地方战略性地选择放置许多 hook。任何一个安全模块都可以 attach 到它要管理的行为的相应 hook 上，并在需要做出决定时提供意见。LSM hook 的放置，经常伴随着一些争议.开发人员经常会反对在 hot code path （非常频繁调用到的代码路径）上增加 hook 带来的额外性能损耗，并且有时开发人员会对如何整合 LSM 存在误解。不过，人们在讨论创建用户命名空间（user namesapce）的 security hook 的时候，基于另一种担忧而产生了争议。

用户命名空间，也就是可以由无特权的进程创建，从而让创建者能完全控制 user ID 和 group ID。在命名空间内，创建者可以以 root 身份运行，但与系统的所有互动都会被映射到创建者的 UID 和 GID 上。它们是无特权容器所需的基本功能。在理论上来说，用户命名空间是完全安全的；在实践中，人们长期以来一直担忧它们会带来更多的攻击面，这种担忧来自于在命名空间内提供了以前只有 root 才能进行的操作。确实有一些漏洞与用户名字空间有关联；最近的一个例子见本报告(https://lwn.net/ml/oss-security/nZdp4o4iHdicJfJwEJ-dtJrhs5aDa-cbvA3psbItS3dkwOwxmzwXanoaslI0T5nXjCNz0Cm5csVgCJxDWPWIaKDbF6mxaYch5xJo3QT-8_0%3D%40protonmail.com/)。不过，用户命名空间是否真的比内核的其他部分更容易出现漏洞，目前尚还不清楚。

关于用户名字空间的更多信息，请看这篇文章(https://lwn.net/Articles/532593/)。

正如 Frederick Lawler 在这个 patch set 中所指出的，安全模块目前对用户名字空间的创建有一定程度的控制，但这种控制依赖于一个 hook，而这个 hook 实际上并不是为访问控制决策而准备的。因此，这就使得错误码无法传播给（可能是正在摸不着头脑的）用户。解决方案是创建一个新的 hook（security_create_user_ns()），在创建每一个新的命名空间之前都会被调用，如果它不符合当前的安全策略，就会导致创建失败。

这是一个相对简单的 patch set，甚至包括了为 SELinux 添加了一个 self-test 以及相关 hook 的实现的代码。在四次修订中经历了一些调整，似乎已经达到了安全社区的开发者都满意的程度。当然，有一个例外；Eric Biederman 在 7 月下旬发布第三个修订版时提出了一些反对意见。其中之一是，只有当内核中大部分可利用的 bug 都被阻止之后，这种阻止对用户名字空间的访问来作为减少攻击面的方式才会有效；否则的话，他说，攻击者只会去寻找各种 bug 来利用。

不过，他更主要的抱怨基本上是在反对对用户名字空间进行任何形式的访问控制。他说，随着时间的推移，许多新的内核功能被限制在仅有 root 用户可用，主要是因为它们可能被用来欺骗 setuid 程序。这导致了更多的代码会以 root 身份运行，这对整体的安全是不利的。用户命名空间是为了结束这种趋势：

用户命名空间的目标之一是避免越来越多的代码迁移到以 root 身份运行。为了实现这个目标，普通的应用程序开发人员需要能够基本确认这一点：典型的用户命名空间都是在 Linux 上正常可用的。

今天，像 chromium 这样的常见应用程序已经假设这样的前提条件是具备的。

你的意图似乎是要放置一个 capability 检查，以便只有 root 才能使用用户名字空间或类似的功能。这样就打破了用户名字空间在你们系统上对普通应用程序的普遍可用性。

Biederman 最后用 "Nacked-by" tag 表示拒绝该 patch。

不过，只有他一个人持这种观点。SELinux 维护者 Paul Moore 回答说，LSM hook 提供的不仅仅是访问控制；审计和可观察性也是它们的重要用例。他断言，"将 LSM 整合到内核的命名空间中是一种自然的契合，而且早就应该这样做了"，并要求 Biederman 提出替代方案，如果他真的无法接受这里提出的 hook 的话。Ignat Korchagin（和 Lawler 一样，他是通过 Cloudflare 的电子邮件地址发布的）说，真正的目标是通过提供对用户名字空间的更多控制来增加对它们的使用：

所以在某种程度上，我认为这个 hook 首先是允许更好地采用用户命名空间了，并为发行版提供商和其他系统维护者提供了一个合理的选择，而不是仅仅提供一个全局的 "kill" sysctl 而已（这是事实上被许多人使用的方式，从而实际上限制了用户空间应用程序访问用户命名空间）。

Biederman 没有进一步回应，谈话结束了。Moore 建议现在是时候把这个改动合并了。

之前有 Eric 的 NACK，但我相信在他的评论之后的回应已经充分解决了这些问题，而且现在已经过了一个星期，Eric 没有进一步的评论；那么我们应该继续推进这件事。

不过，在 8 月 1 日发布第四版后，Biederman 明确表示，他不认为他的担忧已经得到了处理。"Nack Nack Nack"。

接下来会发生什么，目前尚不完全清楚。Biederman 仍然没有为这个问题提供什么替代方案，所以开发者们只能做出一个有点不愉快的选择：要么从头开始，希望找到一个 Biederman 不会阻止的解决方案，要么干脆不理会 Biederman，直接合入这个 hook。由于 Biederman 显然反对对用户命名空间的创建进行任何形式的访问控制，因此很难有双方都能接受的解决方案。在内核社区中，不顾维护者的反对而合入代码是很不容易的，但这种情况偶尔也会发生。Moore 已经表示，这次这个案例可能会出现这样的过程。

全文完
LWN 文章遵循 CC BY-SA 4.0 许可协议。

长按下面二维码关注，关注 LWN 深度文章以及开源社区的各种新近言论～