What does enabling kernel.unprivileged_userns_clone do?

Question

This message was sent to my websocket:

echo kernel.unprivileged_userns_clone = 1 | sudo tee /etc/sysctl.d/00-local-userns.conf

Is it dangerous, and what would it do?

---

Thanks for your feedback everyone, chances are it was someone trying to install the Brave Browser who accidentally pasted into the wrong box and I'm overreacting.

Answer 1

Enabling unprivileged user namespaces can make severe vulnerabilities in the Linux kernel much more easily exploitable. If you did not intend to enable it, you should ensure it is disabled. Numerous vulnerabilities that are found regularly are often only exploitable by unprivileged users if unprivileged user namespaces are supported and enabled by the kernel. Unless you truly need it, just disable it.

The reason for this is that much of the kernel that is only intended to be reachable by UID 0 is not audited particularly well, given that the code is typically considered to be trusted. That is, a bug that requires a UID of 0 is rarely considered a serious bug. Unfortunately, unprivileged user namespaces make it possible for unprivileged users to access this very same code and exploit security bugs.

From Brad Spengler in 10 Years of Linux Security, describing exploitation trends:

Attack surface exposed by unprivileged user namespaces isn’t decreasing anytime soon

• Even more functionality being exposed:
  • 2abe05234f2e l2tp: Allow management of tunnels and session in user namespace
  • 4a92602aa1cd openvswitch: allow management from inside user namespaces
  • 5617c6cd6f844 nl80211: Allow privileged operations from user namespaces
• "Does this newly-allowed code pass existing fuzzing tests?" doesn’t appear to be a consideration for enabling such functionality

A few examples of vulnerabilities only exploitable on systems with unprivileged user namespaces:

• 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://seclists.org/oss-sec/2022/q1/205

• https://seclists.org/oss-sec/2022/q1/54

• 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/

Note that this particular sysctl may get deprecated and possibly removed soon. This is because a little more attention is being spent on finding unprivileged user namespace bugs and the feature is not quite as horribly insecure as it once was. Unfortunately, it is still quite insecure (in part due to the lack of CVE reporting for security bugs in the Linux kernel). If that is the case for your particular distro, you can disable user namespaces directly by setting user.max_user_namespaces = 0.

Answer 2

It disables a bit of "hardening" that Debian patches into their distribution kernel. If you're not running such a kernel, it will fail and not do anything, as such a setting doesn't even exist in the mainline Linux kernel. If you were running such a patched kernel, all it would do is disable the functionality of that patch, and let your kernel work like every other kernel, allowing unprivileged users to use unshare -U. Contrary to forest's answer, I don't believe this to be dangerous. In particular, if a user can sudo to root (as would be required to turn this off), they can already do everything that this would let them do.