[kbenson]

I was enamored with this feature too, but a comment here on HN[1] made me reconsider its use. Apparently rootless requires unprivileged user namespaces, which provides a different security context than most apps are expected to run in, and might be less thoroughly tested than you would think.

I still like the systemd integration and that it doesn't require a daemon too, and I still favor it over Docker.

1: https://news.ycombinator.com/item?id=28393949

Edit: Clarified that it's the unprivileged user namespaces feature specifically, not namespaces in general. Thanks for the feedback solarkraft.

[vngzs]

I am generally conservative about these things, but recently the consensus appears to be that unprivileged user namespaces are stable enough for GA. If you work in a targeted environment (e.g., you are a reporter covering civil liberties), maybe you should wait a bit longer, but for average people the advantages of rootless containers probably exceed the advantages of keeping the unprivileged_userns_clone code out of your attack surface.

I would encourage most security-conscious users to enable it and migrate to recent podman over using Docker, assuming a sufficiently recent kernel. The latest batch of major Linux OS releases have all enabled kernel.unprivileged_userns_clone, so Red Hat, Canonical et al seem to agree.

For those interested, though, you can read the anatomy of a userns clone() vulnerability here:

https://lwn.net/Articles/543273/

[solarkraft]

Thanks for linking the original comment. Every container uses namespaces, this is (TL;DR attempt) about user namespaces, which is a not particularly well audited kernel feature, meaning you may open up potentially insecure kernel code to unprivileged users.

The way I understand it, with containers running under a root user, is that to break out of a container you‘d have to find a vulnerability in standard (rootful) namespaces, which is much less likely (since it’s the same thing everything including Docker uses).

[CameronNemo]

But the vulnerability without usernamespaces is much more severe, because the process then has UID 0 on the host.

Frankly if you are that concerned about security (e.g. you have multitenant workloads or are dealing with sensitive data), you should be using KVM or gvisor.

[kbenson]

If you're using user namespaces and allowing a previous root only API to be used by a user, it's possible that some escape in that which provides root access (which wouldn't be as huge a deal if it was only ever able to be run as root) allows root level escalation outside the container.

That intermixes with security concerns about what's possible if running as root directly in different ways, and be more or less problematic than a root container depending on the use case, and also more or less likely based on how well those APIs are exercised for the specific use case.

It's not that these should be avoided, it's just that people should be aware that it's not necessarily a pure security increase at the expense of a bit of extra CPU due to kernel checks. There's a bit to consider. Maybe later everyone will consider this tested enough that's it's mostly a pure win. Maybe it's already at that point but people haven't internalized it. I don't know enough to know what stage we're at, but I thought it was worth mentioning, as it took me by surprise when I learned of it.

[modshatereality]

"the vulnerability" means one specific vulnerability in docker or somesuch "privileged container" i presume. there are also some sleeping in the kernel code that userns opens up, and even outright intentionally allow, that were previously not on the radar.

ultimately we must consider userns vs privileged-ns a fork in the road. one direction sweeps privilege concerns under the rug, and opens up new attack surface today leaving the door open for more non-obvious problems tomorrow. the other relies on highly competent engineers that know the nuances of the system they are working with, and have strong will to stomp out needless complexity from design to implementation.