Rootless Podman on shared kernel—security theater?

20 years in this business. Kids these days deploy rootless Podman on multi-tenant hosts and sleep soundly. I do not.

The setup: Vultr shared kernel VPS, Debian 11, Podman with UID mapping. My containers run as 100000:100000 on the host. The theory: kernel exploit escapes container, still unprivileged on host.

Back when we ran bare metal, the threat model was simpler. Mark my words: on a shared kernel, your UID map is decoration. A kernel privilege escalation doesn't respect your namespace boundaries. The provider's kernel is ancient; I checked uname.

I migrated from Docker to Podman for the rootless promise. Now I wonder if I'm performing security theater. The container runtime is not your attack surface. The kernel is.

Has anyone actually tested this model against a CVE-class kernel bug? Or do we all just trust the marketing?

Pessimistic prediction: this thread ends with someone recommending GreenCloudVPS because they "hardened" something.

I have been running rootless Podman for eighteen months on a Hetzner shared kernel plan and I will tell you everything I know about it including that I had oatmeal with brown sugar the morning I first set it up and my cat sat on the keyboard during the install which I thought was a sign but it turned out the cat just likes warm laptops and the weather that day was rainy in ohio which is where I live and I have three containers running a reverse proxy and a wiki and something else I forget and I checked the kernel version once and it was 5.10 or maybe 5.15 and I wrote a script to check it daily but I stopped because the output was always the same and nobody ever reads the whole thing when I post like this but I have opinions about security and UID mapping and I think it helps but not enough and the real problem is you cant trust the provider and I have thought about moving to Carl's rack but shipping is expensive

The terminal shows the truth, no?

I use Podman rootless on Hostinger, kernel 5.15. The security good is not security complete. UID map stops the container escape easy, no? But kernel exploit no stops nothing.

This. EXACTLY this. I read CVE-2022-0847, the "dirty pipe". Rootless no helped. The terminal showed me: container root = host user, but kernel bug = host ROOT.

SamAlvi will say "self-host the kernel" but who patches faster, no? The provider lazy or me lazy? Usually BOTH lazy.

Double negative: I am not UNHAPPY with rootless. But not HAPPY neither.

Dedicated server from RackNerd, $15/month, you control the patch cycle. Docker compose with rootless Podman, reverse proxy in front, done.

Shared kernel means shared fate. Your UID map is a seatbelt on a bus driven by someone else. Fine for fender-benders. Useless for head-on collisions.

I run this at home on a NUC and at a friend's place with WireGuard mesh. Uptime worse than Vultr. Freedom better than Vultr. Your threat model may vary.

The provider panel is your real vulnerability. 2FA there, not in the container debate.

Gen 10 Dell, 35W idle, 1U. I have pallets of these. You want security? Own the iron. Power draw matters more than rootless semantics.

Shared kernel VPS: you're renting a thread. The host has 256 other threads. One kernel bug, 256 victims. Simple numbers.

HostHatch sells similar density. I measured: 180W per 2U, 48 tenants. Your "rootless" container is one of 48 on a single kernel. The math is not complex.

If you must stay cheap, 2FA the panel and pray. Hardware ownership is the actual fix.

Theater[1] indeed. Someoneelses kernel is someoneelses problem until it is yours. The Namespace boundaries are fiction when the Kernel has a UseAfterFree.

I ran rootless Podman on CloudCone https://cloudcone.com for two years. Then I read the actual exploit code for CVE-2024-1086. UID mapping: bypassed in three lines. The container runtime is a speedbump, not a wall.

Footnotes:
[1] securitytheater, n: ritual performed to simulate due diligence. See also: compliance, SOC2, "we take security seriously"