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.

forest · Accepted Answer · 2022-07-29T00:20:03.947

23

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:

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.

edited Jul 29 '22 at 00:20

answered May 05 '19 at 01:41

forest

64,616
20
206
257

I see, thanks. Is this a common automatic attack or is it more likely to be something specific and manual do you reckon? – Baa May 05 '19 at 01:48
3

I disagree with this answer. In particular, I find it very hard to believe that disabling this "opens up severe vulnerabilities" given that [the mainline Linux kernel doesn't even let you disable this like this](https://lwn.net/Articles/673597/). Are you really saying that every Linux kernel with user namespaces and without Debian's patch is super vulnerable? – Joseph Sible-Reinstate Monica May 05 '19 at 02:04
@JosephSible Any Linux kernel with _unprivileged_ user namespaces is significantly more vulnerable. – forest May 05 '19 at 03:08
5

[citation needed] – WBT Sep 13 '19 at 16:12
4

@WBT Look at LWN writeups, oss-sec reports, security-related kernel commits, or CVEs for userns-based containers. https://lwn.net/Articles/543442/, https://lwn.net/Articles/543539/, https://seclists.org/oss-sec/2016/q4/607, https://www.halfdog.net/Security/2015/UserNamespaceOverlayfsSetuidWriteExec/, https://www.rapid7.com/db/modules/exploit/linux/local/nested_namespace_idmap_limit_priv_esc, https://seclists.org/fulldisclosure/2016/Feb/123, http://www.halfdog.net/Security/2016/UserNamespaceOverlayfsXattrSetgidPrivilegeEscalation/, https://brauner.github.io/2019/02/12/privileged-containers.html – forest Sep 14 '19 at 01:14
2

@WBT And, from https://news.ycombinator.com/item?id=14309755: _Right, but "unprivileged user namespaces" are disabled in many contexts, because they've been a source of many vulnerabilities due to code originally thought to only be reachable by root anyway._ – forest Sep 14 '19 at 01:14
4

Those might be good to edit into the answer. However, it looks like the issues (excluding those citing privileged namespaces/containers) tend to be that "unprivileged" user namespaces were actually privileged *more* than the creating namespace, due to now-fixed (and possibly yet-undiscovered) kernel bugs. Is that an accurate assessment? – WBT Sep 16 '19 at 17:32
4

@WBT It's not so much that they're more privileged so much as the kernel interactions limited to the UID 0 are not audited for security nearly as much as those that are typically unprivileged. Unfortunately, unprivileged user namespaces let just anyone interact with said kernel code, opening it up to countless vulnerabilities that just keep on coming. – forest Sep 17 '19 at 05:32
1

@forest Good points and useful resources, however, I don't see how your link https://brauner.github.io/2019/02/12/privileged-containers.html is relevant here when it's talking about prvileged containers (1:1 root mapping) and advising for unprivileged containers? – DenisM Dec 03 '19 at 04:19
1

@DenisM Unprivileged user namespaces refers to root namespaces that can be created _by_ an unprivileged user. In other words, unprivileged userns gives users more privileges. – forest Dec 04 '19 at 07:21
2

@forest Please extend your answer(s) to such questions by providing sources and your rationales/reasoning (not only in the comments after being asked for them). Edit: I just realized that this very question is hosted on the security sub-stackexchange. Here the reputation should give enough clue to trust the answer (sources/rationale would still be welcome in the answer itself though). – stefanct Apr 25 '20 at 13:59
1

@stefanct Thanks. I've added sources and rationale. – forest Jan 23 '21 at 08:40

score 5 · Answer 2 · answered May 05 '19 at 02:05

5

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.

answered May 05 '19 at 02:05

Joseph Sible-Reinstate Monica

7,110
3
21
35

2

Unprivileged user namespaces are _extremely_ dangerous. Check out oss-sec or look for recent privesc CVEs and see how many of them are either only exploitable with unprivileged user namespaces, or are easier to exploit. – forest May 05 '19 at 03:10
Arch Linux kernels [also provide this knob](https://github.com/archlinux/linux/commit/479ca137ea2b368c8c8e84d5ce7c4084f5653a0d), leaving it enabled by default (matching the default upstream behavior). – Vladimir Panteleev Apr 12 '21 at 11:27

What does enabling kernel.unprivileged_userns_clone do?

2 Answers2

Linked

Related