A security-module hook for user-namespace creation [LWN.net]

By Jonathan Corbet
August 4, 2022

The Linux Security Module (LSM) subsystem works by way of an extensive set of hooks placed strategically throughout the kernel. Any specific security module can attach to the hooks for the behavior it intends to govern and be consulted whenever a decision needs to be made. The placement of LSM hooks often comes with a bit of controversy; developers have been known to object to the performance cost of hooks in hot code paths, and sometimes there are misunderstandings over how integration with LSMs should be handled. The disagreement over a security hook for the creation of user namespaces, though, is based on a different sort of concern.

User namespaces, which can be created by unprivileged processes, give the creator complete control over user and group IDs. Within the namespace, the creator can run as root, but all interactions with the system are mapped back to the creator's user and group ID. They are a fundamental building block for unprivileged containers. In theory, user namespaces are entirely safe; in practice, they have long been accompanied by worries about the increased attack surface that comes from making formerly root-only actions available within the namespace. There have indeed been vulnerabilities resulting from interactions with user namespaces; see this report for a recent example. Whether user namespaces are truly more prone to vulnerabilities than the rest of the kernel is not clear, though.

See this article for more information on user namespaces.

As Frederick Lawler notes in this patch set, security modules currently have a degree of control over user-namespace creation, but that control relies on a hook that was not actually intended for access-control decisions. Among other things, that prevents any error code from being propagated back to the (presumably frustrated) user. The solution is to create a new hook (security_create_user_ns()) that is called prior to the creation of a new namespace, and which can cause the action to fail if it is not consistent with the current security policies.

It is a relatively straightforward patch set, even after adding a self-test and a hook implementation for SELinux. Over four revisions, it has seen a number of tweaks and appears to be at a point where developers in the security community are happy with it. There is, of course, an exception; Eric Biederman raised some objections in response to the posting of the third revision in late July. One was that blocking access to user namespaces as a way of reducing attack surface would only be effective if the bulk of the exploitable bugs in the kernel would be blocked; otherwise, he said, attackers would simply find a different bug to exploit.

His larger complaint, though, was essentially an objection to applying any sort of access control to user namespaces at all. Over time, he said, numerous new kernel features have been restricted to the root account mostly because otherwise they could be used to confuse setuid programs. That has resulted in more code running as root, which is not good for security overall. User namespaces were meant to bring an end to that trend:

One of the goals of the user namespace is to avoid more and more code migrating to running as root. To achieve that goal ordinary application developers need to be able to assume that typically user namespaces will be available on linux.
An assumption that ordinary applications like chromium make today.
Your intentions seem to be to place a capability check so that only root can use user namespaces or something of the sort. Thus breaking the general availability of user namespaces for ordinary applications on your systems.

Biederman concluded with a "Nacked-by" tag indicating rejection of the patch.

He was alone in that view, though. SELinux maintainer Paul Moore answered that LSM hooks provide for more than just access control; auditing and observability are also important use cases for them. He asserted that "integrating the LSM into the kernel's namespaces is a natural fit, and one that is long overdue", and asked Biederman to suggest alternatives if the proposed hook is truly not acceptable. Ignat Korchagin (who, like Lawler, posted from a Cloudflare email address) said that the real goal was to increase the use of user namespaces by providing more control over them:

So in a way, I think this hook allows better adoption of user namespaces in the first place and gives distros and other system maintainers a reasonable alternative than just providing a global "kill" sysctl (which is de-facto is used by many, thus actually limiting userspace applications accessing the user namespace functionality).

Biederman did not respond further, and the conversation wound down. Moore suggested that it was time to get the work merged:

There is the issue of Eric's NACK, but I believe the responses that followed his comment sufficiently addressed those concerns and it has now been a week with no further comment from Eric; we should continue to move forward with this.

After the posting of version 4 on August 1, though, Biederman made it clear that he did not believe his concerns had been dealt with. "Nack Nack Nack".

What will come next is not entirely clear. Biederman still has not offered any sort of alternative approach to the problem, so developers are left with a somewhat unpleasant choice: either restart from the beginning in the hopes of finding a solution that Biederman will not try to block, or simply ignore Biederman and merge the hook anyway. Since Biederman is evidently opposed to any sort of access control for user-namespace creation, the space of mutually acceptable solutions may be small. Pushing code over a maintainer's objections is not done lightly in the kernel community, but it does occasionally happen. Moore has already indicated that this case may play out that way.

Index entries for this article
Kernel	Namespaces/User namespaces
Kernel	Releases/6.1
Kernel	Security/Security modules

to post comments

A security-module hook for user-namespace creation

Posted Aug 4, 2022 17:23 UTC (Thu) by developer122 (guest, #152928) [Link] (23 responses)

I think it's very true that user namespaces, as a generic way of isolating security concerns, are only useful if they are reliably and easily available. I apologize for the crude metaphor, but teens will only use condoms (to prevent a range of undesirable consequences) if they are cheap and easy to obtain.

To make user namespaces unreliable would *also* fundamentally break the security model and assumptions (of available mitigation) of an enormous number of existing userspace applications.

This whole exercise is born out of a fear that *some unspecified exploitable code* might still be reachable from inside a namespace, thus we should ban namespaces. That might not be the immediate intent, but that will be the result as some LSMs will ban them outright and many will interfere with their use under various circumstances. No application will be able to count on their availability.

Userspace applications will instead implement fallback mechanisms to work-around LSMs, many of which will probably involve the system's *actual* root.

If people are concerned about user namespaces being proous, they should be working to improve them directly. Make available new classes of more restricted/isolated user namespace. Implement a tagging system so that objects from a namespace can be marked persona-non-grata, configured by the creating application. Etc. Etc. Address the actual concerns.

A security-module hook for user-namespace creation

Posted Aug 4, 2022 17:24 UTC (Thu) by developer122 (guest, #152928) [Link]

fix: porous*

A security-module hook for user-namespace creation

Posted Aug 4, 2022 17:27 UTC (Thu) by developer122 (guest, #152928) [Link] (1 responses)

If we left it purely up to sysadmins, the open() system call would be privileged.

open()

Posted Aug 4, 2022 18:47 UTC (Thu) by corbet (editor, #1) [Link]

Somebody will surely point out that there is an LSM hook for open() and has been since LSM was created, so it might as well be me.

A security-module hook for user-namespace creation

Posted Aug 4, 2022 18:40 UTC (Thu) by iabervon (subscriber, #722) [Link] (17 responses)

Doesn't this argue for eliminating all LSM hooks? Any of them would allow an LSM to prohibit some operation that should not be prohibited. Realistically, LSMs don't prohibit things that are needed by userspace applications, or they also prohibit any workarounds those applications would use, and people use LSMs that permit the operations that are used by the applications they want to use.

A security-module hook for user-namespace creation

Posted Aug 4, 2022 20:52 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (13 responses)

> Doesn't this argue for eliminating all LSM hooks?

LSM has basically failed to be useful, so yeah. It works only in very specific environments like Android.

A security-module hook for user-namespace creation

Posted Aug 4, 2022 22:13 UTC (Thu) by Paf (subscriber, #91811) [Link] (12 responses)

“Useful only in restricted environments” isn’t “failed to be useful”, is it?

A security-module hook for user-namespace creation

Posted Aug 5, 2022 1:36 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (11 responses)

> “Useful only in restricted environments” isn’t “failed to be useful”, is it?

Ok. "Failed to be widely useful".

A security-module hook for user-namespace creation

Posted Aug 5, 2022 6:40 UTC (Fri) by jrjohansen (subscriber, #75010) [Link] (10 responses)

It is enabled and used by default on Debian, SuSE, Ubuntu, Android and several other distros. There are several CVEs that have been blocked by its use on these distros.. Could it be better used, sure but I would not call that "failed to be widely useful".

A security-module hook for user-namespace creation

Posted Aug 5, 2022 12:24 UTC (Fri) by ballombe (subscriber, #9523) [Link] (9 responses)

> There are several CVEs that have been blocked by its use on these distros.

Could you provide one that is convincing ?

A security-module hook for user-namespace creation

Posted Aug 5, 2022 17:24 UTC (Fri) by jrjohansen (subscriber, #75010) [Link] (8 responses)

Convincing to who? But just a few examples CVE-2014-7169, CVE-2016-9962, CVE-2017-6074, CVE-2017-7494, CVE-2019-5736. Just how effective the LSM is depends on which LSMs are deployed, and what policies. The LSM is more than just SELinux, smack, etc. There are other modules that can be stacked on top: Yama, safesetid, lockdown, loadpin, landlock, etc.

A security-module hook for user-namespace creation

Posted Aug 5, 2022 20:01 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (3 responses)

> CVE-2014-7169

This doesn't prevent the exploit that allows the attacker to run arbirtrary code, but it prevents this arbitrary code from gaining root right away. Assuming no other exploits.

> CVE-2017-6074

This is BS. Basically, "you can use SELinux to prohibit loading of modules". You can also just delete them, it's not a mitigation.

> CVE-2019-5736

This was the only real non-trivial one from your list, and in this case the proper fix is to use user namespaces.

All in all, very few exploits are truly prevented by SELinux. It sometimes makes it harder for attacker to gain wider access.

A security-module hook for user-namespace creation

Posted Aug 5, 2022 23:50 UTC (Fri) by Wol (subscriber, #4433) [Link] (1 responses)

> > CVE-2017-6074

> This is BS. Basically, "you can use SELinux to prohibit loading of modules". You can also just delete them, it's not a mitigation.

Not having read any of the background stuff but ... how does deleting modules protect against an attacker dropping a module onto your system?

Mind you, I believe you can also build your kernel with the "load module" code missing, no? Perfect for gentoo users like me :-)

Cheers,
Wol

A security-module hook for user-namespace creation

Posted Aug 9, 2022 3:13 UTC (Tue) by jrjohansen (subscriber, #75010) [Link]

>> > CVE-2017-6074
>
>> This is BS. Basically, "you can use SELinux to prohibit loading of modules". You can also just delete them, it's not a mitigation.
>
> Not having read any of the background stuff but ... how does deleting modules protect against an attacker dropping a module onto your system?
>

If the attacker can load or get modules to load, the attacker may be able to exploit a flaw in a module to gain root or even just full kernel privileges. Now you might think if the attack can load a module or get a module to load they are already root, but that isn't always the case. They could be a regular user who can get a module to autoload via some action or they could have restricted root privileges (basically sandboxed in some way).

If the attacker can build and load their built module they can easily gain full kernel privileges, but on systems where they can only trigger module auto-load of existing modules or if the system require signed modules, the attacker will have to resort to exploiting flaws in existing modules.

> Mind you, I believe you can also build your kernel with the "load module" code missing, no? Perfect for gentoo users like me :-)

that is an option that does work for those who can use it.

A security-module hook for user-namespace creation

Posted Aug 8, 2022 20:03 UTC (Mon) by jrjohansen (subscriber, #75010) [Link]

>> CVE-2014-7169
>
> This doesn't prevent the exploit that allows the attacker to run arbirtrary code, but it prevents this arbitrary code from gaining root right away. Assuming no other exploits.

of course it can't stop or fix every flaw/CVE in an application, but it did do its job of containing said flaw and prevented it from becoming a root exploit. Yes there could be another way to elevate to root that is always a possibility unless you can mathematically prove otherwise, but it did stop this one.

> > CVE-2017-6074
>
> This is BS. Basically, "you can use SELinux to prohibit loading of modules". You can also just delete them, it's not a mitigation.

Yes it is. Sure there are other ways to block modules from loading: building the kernel without module support, lockdown (also an LSM), loadpin (also an LSM). What SELinux brings is context, where some services are still allowed to load modules, because the broader solutions don't work for some environments.

> > CVE-2019-5736
>
> This was the only real non-trivial one from your list, and in this case the proper fix is to use user namespaces.

The proper fix is always to patch/rewrite the software to remove the vulnerability, that doesn't take away from SELinux doing its job here.

> All in all, very few exploits are truly prevented by SELinux. It sometimes makes it harder for attacker to gain wider access.

Security is about layers and making it harder for an attacker is a win. No SELinux won't fix programs that have exploits in them, but neither do user namespaces.

A security-module hook for user-namespace creation

Posted Aug 6, 2022 12:15 UTC (Sat) by ballombe (subscriber, #9523) [Link] (3 responses)

Debian conveniently provides links between CVE and packages update, see

https://security-tracker.debian.org/tracker/CVE-2014-7169
https://security-tracker.debian.org/tracker/CVE-2016-9962
https://security-tracker.debian.org/tracker/CVE-2017-6074
https://security-tracker.debian.org/tracker/CVE-2017-7494
https://security-tracker.debian.org/tracker/CVE-2019-5736

So all those CVE lead to packages update and all but one lead to a DSA to be issued,
the exception being a CVE that only affected unstable.

So as far as Debian is concerned, LSM do not seems to reduce the number of security updates.

A security-module hook for user-namespace creation

Posted Aug 6, 2022 13:11 UTC (Sat) by mathstuf (subscriber, #69389) [Link]

It would seem odd to not issue a fix just because Debian has a default LSM-using setup since it supports not using an LSM. I don't think that is evidence that LSMs don't serve a purpose myself. I say that as someone that uses SELinux on Fedora normally, but it broke logging in on one machine recently…so is in Permissive mode until I track down the problem.

A security-module hook for user-namespace creation

Posted Aug 6, 2022 14:28 UTC (Sat) by rahulsundaram (subscriber, #21946) [Link]

> So as far as Debian is concerned, LSM do not seems to reduce the number of security updates.

This isn't the purpose of LSM. It is to mitigate or reduce the severity of vulnerability for end users. Distributions may choose to downgrade the severity of the issue based on the mitigations available by default however they won't be able to negate their responsibility to issue updates regardless. This isn't specific to LSM, if say, Firefox sandboxing stops a vulnerability from being exploited currently, Mozilla isn't going to just ignore the vulnerability, they will still patch it anyway.

A security-module hook for user-namespace creation

Posted Aug 8, 2022 19:43 UTC (Mon) by jrjohansen (subscriber, #75010) [Link]

As @rahulsundaram mentions below that isn't what the LSM is supposed to do. When vulnerabilities are found you still want to fix them regardless if they are stopped or mitigated by an LSM or any other hardening or security techniques.

LSMs can however stop, mitigate or contain an exploit reducing severity of a vulnerability, and hence reducing the priority of fixing a given CVE.

A security-module hook for user-namespace creation

Posted Aug 5, 2022 2:49 UTC (Fri) by developer122 (guest, #152928) [Link]

You don't make unreliable a mechanism you want to encourage users to use. User namespaces are an important security mechanism that right now has universal support. If you make their availability unreliable then people won't use them. They'll implement workarounds that involve handing out actual root permissions.

A security-module hook for user-namespace creation

Posted Aug 5, 2022 20:39 UTC (Fri) by amarao (guest, #87073) [Link] (1 responses)

I'm totally fine with audit hooks, if they do not slow down things. I think that arbitrary fails for things which are expected to work is bad. Let's say I wrote a code to use with namespaces. I ask kernel to create one. It returned me '402 payment required'. What should I do? Exit with code 1? Show 'error: denied' dialog box and exit after 'OK'?

I have a better idea. How about restricting with LSM ability for processes to exit? There is a syscall for that, and by EPERM it, we can forbid crashing software! It's going to work no matter what!

A security-module hook for user-namespace creation

Posted Aug 9, 2022 17:32 UTC (Tue) by cschaufler (subscriber, #126555) [Link]

Hee Hee. There is a legitimate use case for an LSM hook that would prevent a process from successfully terminating. Forensic analysis of a process that did Bad Things and got caught.

In the early days of X11 clients no one checked error codes because there wasn't any notion of what to do if your color map wasn't properly loaded or the like. They figured out how to handle errors reasonably. Many early Unix utilities ignored the return from the write() system call. We don't much tolerate that any more. Assuming a syscall is never going to fail in an unexpected way isn't good programming practice, and never has been. Sure, you can argue that adding an errno to the list a call can return is an API change, but that's a stretch.

A security-module hook for user-namespace creation

Posted Aug 5, 2022 10:14 UTC (Fri) by jkbs (subscriber, #107081) [Link] (1 responses)

You can already block user-namespace creation today with an existing LSM hook (cred_prepare) as demonstrated in this blog post:

https://blog.cloudflare.com/live-patch-security-vulnerabi...

The initial intention behind the patch set was to improve the error reporting, so that it is not confusing to the users, as the article here point out.

A security-module hook for user-namespace creation

Posted Aug 5, 2022 11:39 UTC (Fri) by mokki (subscriber, #33200) [Link]

That is how I read it too. I fail to see any valid reason why better error reporting should be nacked.

And there are likely network visible software (such as sshd/https) that do not currently use namespaces and where pre-emptively blocking them improves security by adding an extra layer.

A security-module hook for user-namespace creation

Posted Aug 4, 2022 19:34 UTC (Thu) by bartoc (guest, #124262) [Link]

It seems more interesting to me to have LSMs enforce that programs _must_ use namespaces rather than restricting them, but I don't generally see the problem with having policy that restricts usage for software that isn't expecting to use them either.

A security-module hook for user-namespace creation

Posted Aug 11, 2022 17:53 UTC (Thu) by flussence (guest, #85566) [Link] (1 responses)

It's a bit ridiculous that they're seriously proposing forcing everyone back to relying on setuid binaries to set up sandboxes instead of accepting the reality that this is, quite frankly, insane.

Security through insecurity! It's like grsec never ragequit.

A security-module hook for user-namespace creation

Posted Aug 19, 2022 2:06 UTC (Fri) by cypherpunks2 (guest, #152408) [Link]

They went private, but they're still actively developing their patches. They're just no longer free.

The fact is, (unprivileged) user namespaces DO open up an extremely large attack surface area. I manage hundreds of computers in a high-security environment and unprivileged userns is the first thing we shut down. The same is true for many other organizations that operate in an adversarial environment and require higher security than your average Joe.

Every time there's a new CVE (and even more often when a CVE isn't obtained), a significant fraction of them are only exploitable if CAP_SYS_ADMIN is available through an unprivileged user namespace. When security is about hard numbers and not a warm fuzzy feeling, limiting access to this unpolished feature drastically reduces the number of successful exploits encountered in the wild.