Make value of kernel.unprivileged_userns_clone depending on kernel version

[deimi]

Description

Currently you set the sysctl config kernel.unprivileged_userns_clone to 0, for mitigating CVE-2021-33909.
Unfortunately this config prevents running podman containers as non root, which would actually be a good thing from security perspective. I searched quite some time until I found that this role was the reason why I was not able to start containers.

Solution

Only set kernel.unprivileged_userns_clone to 0 when the kernel version is below 5.14.4 or if it is explicitly set by the user. Newer kernel versions are not effected anymore by CVE-2021-33909

Alternatives

No response

Additional information

...

[schurzi]

This is a hard one. I totally understand where you come from. The curlpit ist, not all systems run Podman and in all these cases it is very much preferable to keep it as is. From what I am reading it is still considered a security risk to have this option enabled.

What I am very much in favour for is to add some documentation to tell our users how to handle this problem. I know it's hard to find, but we already have something similar for other problems: https://github.com/dev-sec/ansible-collection-hardening/tree/master/roles/os_hardening#known-limitations

@rndmh3ro while thinking about this I had the idea to include some extra tasks to notify our users of these known limitations. In this case something like an assert, where we discover that podman is installed and the kernel option is still set to our default and in this case we will emit a warning with a link to the documentation. Currently this would be like 4-5 warnings for the whole collection and could considerably improve the usability. Do you have an opinion on this?

[rndmh3ro]

We discussed this some more:

What we don't want:

• Failing a playbook to get the user to acknowledge some warning or hint about what could possibly break when they (don't) set a specific setting

What we think:

• Nobody will read the warnings the role will emit on the command line

Therefore it is probably enough to properly document these kinds of issues. We already have a "known limitations" part in the docs: https://github.com/dev-sec/ansible-collection-hardening/tree/master/roles/os_hardening#known-limitations

I propose to move this part on top of the variables-section and add this topic.

@deimi what do you think?

[deimi]

That is fine for me, because I understand that it is probably only relevant for podman/container use cases. I totally agree, usually no one reads warnings.
Thx for the quick responses.

Additionally I would welcome to have sysctl_unsupported_entries documented as role variable, because the solution here is to add kernel.unprivileged_userns_clone to this variable. But sysctl_unsupported_entries isn't documented anywhere. I just found it due to a hint in another issue and by reading the actual source code.

[rndmh3ro]

Additionally I would welcome to have sysctl_unsupported_entries documented as role variable, because the solution here is to add kernel.unprivileged_userns_clone to this variable. But sysctl_unsupported_entries isn't documented anywhere. I just found it due to a hint in another issue and by reading the actual source code.

That is because sysctl_unsupported_entries is a vars-variable and not really supposed to be overwritten. You should be able to use sysctl_unsupported_entries to change the value of kernel.unprivileged_userns_clone.