Are user namespaces good for your health?

At last, I ran into a take on user namespaces that resonates with my own view of the problem: Kubernetes Finally Has User Namespace Support. The Shared Kernel Problem Remains (and its spinoff on The New Stack) by Kaylin Trychon of Edera.

The article focuses on Kubernetes, but the pitfalls of user namespaces it reveals are relevant to other runtimes, too. Kubernetes, rootless Podman (and Docker), Bubblewrap, and other runtimes and sandboxes that claim improved security through using user namespaces may actually be opening an even bigger attack surface.

There are 3 main vectors for a container breakout:

• an operator error (a misconfigured runtime or overly privileged container);
• a vulnerability in the container runtime;
• a vulnerability in the Linux kernel itself.

User namespaces help to mitigate the first two - if a breakout happens, the escaped process will more likely end up with some high, unprivileged UID/GID on the host. However, holes in the kernel itself that can lead to a container breakout aren't rare these days: GhostLock, Copy Fail, Dirty Frag, Fragnesia, IPv6 Frag Escape, to name a few found in the past 6-12 months.

The more of the kernel surface you expose to your containers, the greater the chance that such a hole can be exploited by the containerized app (especially if it's an autonomous agent smart enough to chain several vulnerabilities together). And, according to Edera (and common sense), user namespaces increase the kernel surface exposed to the container by over 200%. Worse, exploiting kernel vulnerabilities usually leaves the attacker with root on the host, no matter how unprivileged the containerized process was.

Edera's recommendation (and solution) is to use a hypervisor if strong isolation of workloads is required. With a hypervisor, each workload will reside in its own VM and get a dedicated kernel. But some hypervisors are more bulletproof than others, so you need to choose wisely!

For instance, iximiuz Labs uses Type-2 Firecracker and Cloud Hypervisor, and both were recently affected by guest-to-host breakout vulnerabilities (see the KVM-wide Januscape and Zapscape vulnerabilities and the Cloud Hypervisor-specific CVE-2026-45782). And Type-1 hypervisors are penetrable, too! The enterprise-grade VMware ESX and Xen have had an unusually high number of reported CVEs in the past 6 months (see CVE-2026-47876, CVE-2026-62428, or CVE-2026-62435).

Given iximiuz Labs' focus on edu scenarios and explicit discouragement of processing any sensitive data in the playgrounds, Firecracker and Cloud Hypervisor still remain optimal choices for the platform. However, for more sensitive workloads, Edera's approach of using its own Tier-1 hypervisor will likely be a much better choice.

P.S. I have no association with Edera.