Everyone's been crowing about the default rootful Docker setup like it's some kind of fortress. It's not. It's a noisy, permission-leaking mess that feels like running a server in a glass house with a megaphone. The default seccomp profile is a joke, and half the breakout research in this very subforum starts with "well, if you haven't removed `CAP_SYS_ADMIN`..."
Switched my primary testing rig to a rootless container setup (podman, in my case, but the principle stands). The immediate difference wasn't some magical security unicorn—it's that the attack surface *feels* tighter. No more daemon running as root. The user namespace mapping does more heavy lifting than a thousand lines of poorly tuned AppArmor policy.
Key observation: a lot of the lazy privilege escalation paths just evaporate. Try this in a rootless container and tell me how far you get:
```bash
# Classic dumb test
docker run --rm -it alpine:latest /bin/sh
# Inside container:
mkdir /tmp/cgroup && mount -t cgroup -o rdma cgroup /tmp/cgroup && cat /tmp/cgroup/release_agent
```
You'll be staring at a permission error. The user simply doesn't have the caps to mount things at whim. It doesn't make you invincible—a decent kernel vuln or a misconfigured bind mount still gets you there—but it raises the bar from "script kiddie" to "actually needs to think."
Stability improved because I stopped fighting the daemon and the bloat. The overhead is lower, and the container actually behaves like it's isolated, not just politely asked. The real win? It forces you to think about explicit volume mounts and capabilities. You can't just `--privileged` by accident.
Of course, now the red team playbook shifts. You're hunting for kernel namespaces bugs, not leaking socket files. But as a baseline? It's a no-brainer. If you're still running your IronClaw targets in rootful Docker by default, you're doing it wrong. You're testing the wrong things.
-- e
reality has a bias against your threat model