启用非特权用户命名空间可以使 Linux 内核中的严重漏洞更容易被利用。如果您不打算启用它，则应确保将其禁用。如果内核支持和启用非特权用户命名空间，则定期发现的许多漏洞通常只能由非特权用户利用。除非你真的需要它，否则禁用它。

这样做的原因是，考虑到代码通常被认为是受信任的，许多只打算通过 UID 0 访问的内核没有经过特别好的审计。也就是说，需要 UID 为 0 的错误很少被视为严重错误。不幸的是，非特权用户命名空间使非特权用户可以访问相同的代码并利用安全漏洞。

来自 Brad Spengler 在10 Years of Linux Security中，描述了利用趋势：

非特权用户命名空间暴露的攻击面不会很快减少

• 更多功能被公开：
  • 2abe05234f2e l2tp：允许在用户命名空间中管理隧道和会话
  • 4a92602aa1cd openvswitch：允许从用户命名空间内部进行管理
  • 5617c6cd6f844 nl80211：允许来自用户命名空间的特权操作
• “这个新允许的代码是否通过了现有的模糊测试？” 似乎不是启用此类功能的考虑因素

一些仅可在具有非特权用户命名空间的系统上利用的漏洞示例：

• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-16120

• https://brauner.github.io/2019/02/12/privileged-containers.html

• https://www.halfdog.net/Security/2016/UserNamespaceOverlayfsXattrSetgidPrivilegeEscalation/

• https://www.halfdog.net/Security/2015/UserNamespaceOverlayfsSetuidWriteExec/

• https://googleprojectzero.blogspot.com/2017/05/exploiting-linux-kernel-via-packet.html

• https://seclists.org/fulldisclosure/2016/Feb/123

• https://seclists.org/oss-sec/2016/q4/607

• https://www.openwall.com/lists/oss-security/2015/12/31/5

• https://www.rapid7.com/db/modules/exploit/linux/local/nested_namespace_idmap_limit_priv_esc/

• https://lwn.net/Articles/543539/

• https://lwn.net/Articles/543442/

请注意，这个特定的 sysctl 可能会被弃用并可能很快被删除。这是因为更多的注意力都花在了寻找非特权用户命名空间的错误上，并且该功能并不像以前那样非常不安全。不幸的是，它仍然很不安全（部分原因是缺乏 CVE 报告 Linux 内核中的安全漏洞）。如果您的特定发行版是这种情况，您可以通过设置直接禁用用户命名空间user.max_user_namespaces = 0。

它禁用了 Debian 修补到其分发内核中的一些“强化”。如果您没有运行这样的内核，它将失败并且不执行任何操作，因为这样的设置甚至不存在于主线 Linux 内核中。如果您正在运行这样一个补丁内核，它所要做的就是禁用该补丁的功能，让您的内核像其他所有内核一样工作，允许非特权用户使用unshare -U. 与森林的回答相反，我认为这并不危险。特别是，如果用户可以sudoroot （因为需要关闭它），他们已经可以做这会让他们做的所有事情。