daisy Asked: 2023-12-17 08:12:19 +0800 CST2023-12-17 08:12:19 +0800 CST 2023-12-17 08:12:19 +0800 CST 为什么 Ubuntu 默认启用 user.max_user_namespaces ？ 772 我正在研究近年来的内核漏洞，其中大约 80% 需要 user.max_user_namespaces 具有正值。 自 6.X 系列以来，此设置在 CentOS 中被禁用，但在所有最新的 Ubuntu LTS 版本中启用。 结论似乎是“Ubuntu 更容易被利用”，因为默认情况下启用了“user.max_user_namespaces”。 我想知道为什么 Ubuntu 不禁用它呢？在默认设置中启用它有什么好处吗？ kernel 1 个回答 Voted Best Answer muru 2023-12-17T09:24:09+08:002023-12-17T09:24:09+08:00 Ubuntu 启用它的时间比 Debian 长得多，但看看Debian 在 Bullseye 中启用它的原因，我认为这可能与 Ubuntu 的相同： 从Linux 5.10开始，默认允许所有用户创建用户命名空间。这将允许 Web 浏览器和容器管理器等程序为不受信任或不太受信任的代码创建更受限制的沙箱，而无需以 root 身份运行或使用 setuid-root 帮助程序。 以前的 Debian 默认设置将此功能限制为以 root 身份运行的进程，因为它暴露了内核中更多的安全问题。然而，随着此功能的实现已经成熟，我们现在确信它提供的安全优势超过了启用它的风险。 因此，他们认为由此提供的安全优势已经足够好，无需考虑扔掉整个东西。 Ubuntu 意识到了安全问题，并正在努力使用 AppArmor 来缓解： 禁用非特权用户命名空间可能会阻止漏洞利用，但也可能会破坏合法使用和依赖访问它们的应用程序。 通过引入受限制的非特权用户命名空间，AppArmor 可用于有选择地允许和禁止单个应用程序的非特权用户命名空间。AppArmor 策略用于根据每个应用程序有选择地控制对非特权用户命名空间的访问，然后拒绝对所有其他应用程序的访问。 （这篇文章还在其他地方提到了用户命名空间如何减少对 setuid 的需求。） 根据宣布这一点的博客文章，它在 23.10 的初始版本中默认被禁用，并计划在稍后获得更多数据时通过包更新来启用。较旧的版本不会受到影响。
Ubuntu 启用它的时间比 Debian 长得多，但看看Debian 在 Bullseye 中启用它的原因，我认为这可能与 Ubuntu 的相同：
因此，他们认为由此提供的安全优势已经足够好，无需考虑扔掉整个东西。
Ubuntu 意识到了安全问题，并正在努力使用 AppArmor 来缓解：
（这篇文章还在其他地方提到了用户命名空间如何减少对 setuid 的需求。）
根据宣布这一点的博客文章，它在 23.10 的初始版本中默认被禁用，并计划在稍后获得更多数据时通过包更新来启用。较旧的版本不会受到影响。