Note: Every mainstream OS since RHEL8 has defaulted to User Namespace being turned on. Debian, Fedora, Ubuntu, RHEL, Centos ... all have this defaulted on. While overall the statements are true. There has not been many recent vulnerabilities forcing distributions to reconsider this setting. Podman is taking advantage of something that is turned on on most of the Linux systems running in the world. So saying this is not well tested on novel is a big exageration. User Namespaces have been available for almost 10 years and enabled for rootless users for at least 5 years in main line distributions.

Shouldn't the best security come from using Rootless podman, but configuring SE Linux to prevent all other binaries from using unprivileged namespacing?

The concern isn't that podman itself might use that extra attack surface (because, you give podman so much more rights by making it setuid root), but that other untrusted binaries (like a virus) might use unpriviledged namespaces to exploit the kernel.

TBH, by the time you are worrying about privilege escalation from userspace threats on a typical single-user linux machine, you have already lost.

A smart threat will just modify your $PATH or bash aliases to replace su and sudo with wrappers that execute their own commands the next time you use su/sudo to do something legitimate.

I’m not too knowledgeable about SELinux, but Podman itself can create unsafe (privileged, etc.) containers, so I don’t think naively restricting user namespaces to Podman is going to help, exploits could just create the namespaces through Podman instead of doing it themselves.

BTW, if I remember correctly Podman isn’t setuid root except some very small helper binaries, almost all of the process of creating the container can be done without root privileges.

On a workstation, I don't see so much problems. Considering that most people uses an user account that just by typing sudo (or of course spawining a process that invokes sudo) you become root without a password (because we are all annoyed inserting it, but even if we require one, it's trivial to intercept.

If it's a system you use interactively you have other problems. For a server yes, unprivileged containers are a very bad idea, not doubt.

I have found that the processes I put in motion on my workstation tend to creep into production..

I'm not sure what the tradeoff is. You can give a user access to rootless containers or you can give them root access to run containers. User namespaces are at least attempting to improve on the Docker situation where access to the Docker daemon is effectively equivalent to root access, unless that has changed recently.

Does the exposed kernel surface actually extend to the processes running in the contained environment?

You could also give an unprivileged user access to run VMs, that has its own set of security tradeoffs, but VM technology is generally considered more isolated and mature.

Unprivileged user namespaces give an unprivileged user the opportunity to use syscalls like chroot, mount, etc. which they historically couldn't use. Container managers like Docker and Podman drop those "capabilities" after creating the container, so an application running inside a container isn't that unsafe (probably, at least everybody is doing it nowadays for production servers). I think a more problematic scenario is that someone who gets hold of an unprivileged user can then create an user namespace without dropping those capabilities and then use a local root exploit based on those syscalls you normally weren't able to use.

I think the problem might be in the interplay of how many allications/daemons already try to drop privileges by running as a user after doing the few things they need those privileges for (like binding to a low port), and if you don't even need those privileges, you don't even need to start it as root, and your container has well known security properties.

If you're running rootless and using namespaces to allow non-root users access to previously root-only kernel APIs, then a bunch of prior assumptions may no longer hold, and there's a new attack space available to target that has always existed, but was of no use previously to exploit.

This is the concern that kept Debian from enabling user namespace support in their kernels by default, until their recent Bullseye release. It's not Podman-specific; it also affects Docker's rootless mode.

Can't the issue be avoided by simply launching the application as a non-root user within the container namespace?

> Can't the issue be avoided by simply launching the application as a non-root user within the container namespace?

Yes, though the issue currently is that with the likes of (rootfull) docker containers, users end up setting docker to not need to call sudo every time. Meaning, if an attacker accesses your workstation (or a server), they will be able to run docker containers as root. This may as well be giving the attacker access to root as you can really easily give yourself full root access if you can launch rootfull containers. Having (rootfull) docker run access is pretty much the same as having root access.

This sysctl `kernel.unprivileged_userns_clone` doesn't even exist in upstream kernels: the feature can only be disabled at build time.

So then what do you use for container that's better from a security standpoint?

What do you use instead?

I mostly use K8s on VMs[0], and docker the same way. Podman is a just a hobby for me, but I think running Podman in VMs is still the right way to go because it offers you a way of coding distributed systems the same way you can with K8s (with the cool style of systemd and single process containers:))), even if its just your laptop, you could move it to production clusters more easily, because you were forced to think distributed from the start. KinD[1] is also a good option if you can't or don't want to run VMs (but you have to run docker somewhere.. :/). The point is to simulate multiple nodes even when working in development.

[0] https://news.ycombinator.com/item?id=28395329 [1] https://kind.sigs.k8s.io/