> runC creates Linux containers. Containers and VMs are not security solutions, rather system administration and provisioning solutions.
As someone who maintains runC, I disagree with you quite vehemently. Containers are a security system. Yes, they've had their fair share of problems but that doesn't mean that
> chroot() was originally implemented as a type of container. It allowed you to run programs (especially before the adoption of dynamic linking) from a private directory tree when building, installing, and testing software, without risking overwriting the real system. Basically, it's purpose was just like Docker.
That is a very narrow view of what the purpose of containers is.
> But the use of chroot() as a security solution is different. You don't usually mount /dev or /proc in a chroot jail as that would defeat the purpose.
That's not correct. Many programs require /proc, /dev or /sys to function. Most of the uses I've seen of chroot do mount stuff like that in the rootfs. If you're an unprivileged user you haven't really increased the attack surface.
And even if you don't mount those filesystems, chroot doesn't namespace networking or process trees -- so those avenues of attack still exist. That _alone_ makes containers more secure than chroot.
> Containers don't reduce code surface area at all, not to the kernel, nor usually to stock SUID and SGID binaries. All the same devices files _and_ system calls are still available, as well as typical SUID account and system management binaries.
This is not necessarily true, given the existence of no_new_privs, seccomp and user namespaces in Linux. Not to mention that all of the runtimes I know of do not just mount /dev (instead it's a tmpfs with bindmounts for the devices needed by containers).
And not to mention that chroot is just a weaker version of mount namespaces (which is a far more powerful primitive for isolating processes).
> But that's no different than chroot, and so it's not really an improvement over chroot in that sense. More importantly, the code implementing Linux containers is complex and has opened up far more kernel bugs than it's closed.
That's just FUD. Yes, the way Linux went about creating namespaces wasn't the best way, but modern Linux containers are more secure than chroot. Chroot doesn't even protect against messing around with other processes on your host system! It doesn't protect against accessing things outside of your current root (pivot_root actually fixes that problem -- but you can't use it without using mount namespaces).