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.
Securing Services with Rootless Containers
31–40 of 40 posts
Re: Securing Services with Rootless Containers
#32Rootless 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.
Re: Securing Services with Rootless Containers
#33Rootless 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…
Re: Securing Services with Rootless Containers
#34I'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…
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
#35Rootless 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…
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
#36Rootless 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…
Re: Securing Services with Rootless Containers
#37"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
#38Personally 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`?
Re: Securing Services with Rootless Containers
#39Earlier 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.
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
#40Earlier 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. :'(