Live data from Hacker News

Securing Services with Rootless Containers

blog.coderspirit.xyz

31–40 of 40 posts

Re: Securing Services with Rootless Containers

#31
Rootless helps, but less now that it used to (pre-2026). There have been a lot of local privilege escalation vulnerabilities in the Linux kernel (dirtyfrag, fragnesia, CIFSwitch et al) and several of those can be repurposed as container breakouts.

As a result, if you're looking for good security isolation, I'd say a (Micro)VM is a better option. The other route is hardening down your container runtime with seccomp/AppArmor/SELinux but that can be a tricky game.

Re: Securing Services with Rootless Containers

#32

Rootless containers have privilege escalation risks of their own. The problem is the unprivileged_userns_clone sysctl, which rootless containers rely on, has historically been a big source of local privilege escalations. The most recent attack I'm aware of is CIFSwitch.

Why use Microsoft broken technologies on Linux?

Re: Securing Services with Rootless Containers

#33

Rootless helps, but less now that it used to (pre-2026). There have been a lot of local privilege escalation vulnerabilities in the Linux kernel (dirtyfrag, fragnesia, CIFSwitch et al) and several of those can be repurposed as container breakouts. As a result, if you're looking for good security isolation, I'd say a (Micro)VM is a better option. The other route is hardening down your container runtime with seccomp/Ap…

That is what I have been thinking too about recent linux vulnerabilities in context of container escape, but upon brief research I am not convinced it's all that straightforward. For example here https://github.com/Percivalll/Dirty-Frag-Kubernetes-PoC relies on sharing same container layers with other privileged workloads, which is quite a stretch to find in the wild and moreso it says that having a seccomp enabled breaks the exploit - "The default seccomp policy disables the unshare syscall." Other thing is that temporary remedy to lot of these exploits is to blacklist esp4, esp6, algif_aead modules, but how on earth are they going to be loaded in host kernel, which they are not by default, from unprivileged container in first place?

Re: Securing Services with Rootless Containers

#34
post #4

I'd still rather use docker. I don't mind that the daemon runs as root because there are some things that you need root for anyways! Like binding to privileged ports or setting up networks (use `internal: true` and the daemon will automatically set up iptables rules that limit traffic). I deploy docker compose files with ansible so everything comes with built in security defaults like rootless, dropped caps, no new p…

That privileged port thing is not true anymore for Docker created containers, since it lowers that limit and unprivileged containers can listen on any port.

  docker run -ti --rm --user 1000:1000 --privileged=false alpine:latest
  ~ $ cat /proc/sys/net/ipv4/ip_unprivileged_port_start
  0
  ~ $ id
  uid=1000 gid=1000 groups=1000
  ~ $ nc -lvp 80
  listening on [::]:80 ...
Also the iptable rules Docker creates is for routing traffic to container with destination NAT, to actually limit traffic you have to do it yourself by inserting rules in DOCKER_USER chain.

Re: Securing Services with Rootless Containers

#35
post #33

Rootless helps, but less now that it used to (pre-2026). There have been a lot of local privilege escalation vulnerabilities in the Linux kernel (dirtyfrag, fragnesia, CIFSwitch et al) and several of those can be repurposed as container breakouts. As a result, if you're looking for good security isolation, I'd say a (Micro)VM is a better option. The other route is hardening down your container runtime with seccomp/Ap…

That is what I have been thinking too about recent linux vulnerabilities in context of container escape, but upon brief research I am not convinced it's all that straightforward. For example here https://github.com/Percivalll/Dirty-Frag-Kubernetes-PoC relies on sharing same container layers with other privileged workloads, which is quite a stretch to find in the wild and moreso it says that having a seccomp enabled b…

So one of the factors in this is that Kubernetes disables the default seccomp policy provided by the container runtime, by default (you can re-enable it ofc, but you have to know to do that).

As a result I reckon there's more vulnerable containers that you might expect.

Also depending on the environment there's things like dirtyclone https://github.com/raesene/vuln_pocs/tree/main/CVE-2026-4350... which can be triggered where the attacker can start new containers.

Re: Securing Services with Rootless Containers

#36

Rootless helps, but less now that it used to (pre-2026). There have been a lot of local privilege escalation vulnerabilities in the Linux kernel (dirtyfrag, fragnesia, CIFSwitch et al) and several of those can be repurposed as container breakouts. As a result, if you're looking for good security isolation, I'd say a (Micro)VM is a better option. The other route is hardening down your container runtime with seccomp/Ap…

[deleted]

Re: Securing Services with Rootless Containers

#37
Funny timing! I just finished migrating my NAS containers all to be rootless last weekend.

"Migrating" because secrets management was a bit of a pain. I ended up with pretty close to the same design as this article though. (I put an extra layer of complexity in mine, we'll see if I regret it)

Along with the other folks in this thread, I don't think we can stop at rootless in 2026. But I'm optimistic that dropping in libkrun as the runtime will be an easy next step, given its integration with podman (--runtime=krun).

If the author tackles that next, I'd be interested in reading about it

Re: Securing Services with Rootless Containers

#38
post #30

Personally I still think this is not enough, and we really need full generalized (not AI-only) microvm support built into docker/podman, like yesterday. Currently it's difficult to even get a hold of a properly configured minimal kernel (or time-consuming to try to build one) and all the right command-line incantations to even start a one-off microvm using say, qemu, with all the proper storage/networking/etc. bits o…

Have you tried podman with the crun OCI runtime and `--annotation=run.oci.handler=krun`?

The problem I ran into is that krun does not have a readily available package for ubuntu, and I'm too lazy to build it.

Re: Securing Services with Rootless Containers

#39

Earlier quoted context omitted.

I'm all ears, would love to improve smolvm into the right solution for this.

Well for starters, all the single binaries I made of various distros a month ago, simply don't work anymore for no obvious reason. Trying to execute the process silently exits after about 10 seconds with a 0 exit code and no output, shell or anything at all, and no errors. I have absolutely no idea what to do now.

Apologies for this.

I introduced a breaking change in order to build out the hosted platform & registry of pre-packed machines.

I updated the newest smolvm to have a recommendation to repack to fix it.

Forgive me, hope you can try smolvm again. It's improving. :'(

Re: Securing Services with Rootless Containers

#40

Earlier quoted context omitted.

Well for starters, all the single binaries I made of various distros a month ago, simply don't work anymore for no obvious reason. Trying to execute the process silently exits after about 10 seconds with a 0 exit code and no output, shell or anything at all, and no errors. I have absolutely no idea what to do now.

Apologies for this. I introduced a breaking change in order to build out the hosted platform & registry of pre-packed machines. I updated the newest smolvm to have a recommendation to repack to fix it. Forgive me, hope you can try smolvm again. It's improving. :'(

I thought the point of a single binary was that none of that should matter?
Post reply on HN