>without granting them additional privileges such as CAP_NET_ADMIN and without write-bind-mounting sensitive host directories into the container, offer a reasonable security boundary compared to the counterfactua

There's much more to it than that if you check out the link above. Misconfiguring a container is the 2026 version of misconfiguring FTP and MYSQL in the 90s. I.e. most users don't even know how they are asking to get rooted.

▲

lxgr 5 days ago | parent [-]

If you let your container write setuid binaries to your path, give it admin access to your network, let it access the Docker daemon socket etc., sure, you're going to have a bad time. But how is that different from e.g. giving software running in a VM SSH access to your host or a writable bind mount to the host's root directory?

	▲	fc417fc802 5 days ago \| parent [-]
		Yeah all of that stuff seems reasonably obvious. If you fire up a default unprivileged container with a network adapter but no other affordances it shouldn't have any holes. (If it does those are either runtime or distro bugs.) AFAICT all the security problems are fairly obvious own goals inflicted after that point.