A security-module hook for user-namespace creation

Posted Aug 4, 2022 22:13 UTC (Thu) by Paf (subscriber, #91811)
In reply to: A security-module hook for user-namespace creation by Cyberax
Parent article: A security-module hook for user-namespace creation

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

(Log in to post comments)

A security-module hook for user-namespace creation

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

> “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]

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]

> 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]

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]

> 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]

> > 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]

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.