User namespace useful especially when running containers about kernel-hardening-checker

[a13xp0p0v]

Hello everyone,

I'm a bit late for the discussion.

@jcberthon, thanks for your message.
Yes, the CONFIG_USER_NS option provides some isolation between the userspace programs, but the script recommends disabling it to cut the attack surface of the kernel.
Let me give the links describing the rationale:

1. A nice LWN article about the corresponding LKML discussion: https://lwn.net/Articles/673597/
2. A twitter thread about USER_NS and security: https://twitter.com/robertswiecki/status/1095447678949953541

@jcberthon, you are right, USER_NS can be disabled using the sysctl - it is even mentioned in the script source code:

checklist.append(OptCheck('USER_NS', 'is not set', 'my', 'cut_attack_surface')) # user.max_user_namespaces=0

(by the way, adding the ability to check kernel boot parameters and sysctl would be really nice)

Thanks for your discussion, I think I should add some clarification of cut_attack_surface to the README.

[Bernhard40]

Maybe I'm wrong, but at least with Kernel 5.0 USER_NS is activated by default, so "is not set" or "y" should be equivalent. At the moment, it fails because it is "y" on my configuration.

"is not set" (disabled) is the opposite of "y" (enabled). The fail for "y" is desired outcome.

I know that activating USER_NS can cut the attack surface if it is not needed on a system. But on my system which are running containers, I want to have USER_NS activated. True this is not pure hardening of the Kernel, but if we take into account the whole kernel including the possibilities to use it to make containers, then USER_NS should be part of the whole hardening.

You have it backwards. Disabling USER_NS cuts the attack surface and is part of kernel hardening. USER_NS (unprivileged) are considered inherently insecure and unfixable.

[jcberthon]

Thanks for clarifying the first point.

Concerning the second point, I know that username space could increase the attack surface (heck I recall there was like 1,5-2 years ago a privilege escalation flaw with user ns - albeit mitigated when using SELinux), that's especially true if the functionality is not used.

Anyway as the site you mention implicitly state, you can still compile it in and use the sysctl knob to disable it depending on your threat model and your usage of the kernel. So your application could test the sysctl knob rather than the kernel config. e.g. for people using Ubuntu but following the guideline (and because they do not need it), they can disable it in sysctl. When running your script, they should see that it is correctly disabled. What do you think?

Note that when someone requires to run containers, user ns can be a good evil. It increases some risk but diminished others. It is a trade off which depends on one's threat model. I mean that I clearly prefer to run my containers as non-root user with as little capabilities as possible, so I would not need user namespaces. But I'm also maintaining a CI/CD environment based on Docker, and there it is pretty hard to deny users the use of root inside spawned containers. I can control capabilities, seccomp and SELinux, but not the root user. There I really need user namespace, I have no other choice.

Do you have a source for user ns being considered unfixable?

Anyway, I understand your reasoning for marking user ns as insecure, so I would not be offended if you would decide to close this issue. Of course I would appreciate you take my suggestion into account :-)

[anthraxx]

its not just one like 2 years ago, userns is an endless stream of privilege escalation flaws exposed by root designed functionality accessible to any unprivileged user inside a user namespace over and over again.

In my personal opinion this should remain as is, being an error, and if your personal threat model doesn't care about user_ns you can just ignore the result of kconfig-hardened-check 🐱

[jcberthon]

Alright, and thanks for the feedback.

[Bernhard40]

(by the way, adding the ability to check kernel boot parameters and sysctl would be really nice)

I'm not sure if it's good idea for this project to start scanning the running system for security features. I would vote for keeping it simple and just check chosen config file.

[a13xp0p0v]

(by the way, adding the ability to check kernel boot parameters and sysctl would be really nice)

I'm not sure if it's good idea for this project to start scanning the running system for security features. I would vote for keeping it simple and just check chosen config file.

I agree, I don't like the privileged scanning of a system from the script too.
I mean the script could analyze additional files with the needed information together with the kernel config.
For example, right now we can say nothing about side-channel attack mitigations.

[jcberthon]

Thank you for the interesting read and for the updated README.