Comment by zbentley

Comment by zbentley 4 days ago

3 replies

The opposite is true. Containwrization systems were built into operating systems as security features. The whole “Linux packaging is a hellscape of self-induced problems, so let’s duct tape a squashfs onto the side of this new security isolation system and call it a deployment primitive” use case we now call “containers” came later and is a fairly inelegant and wasteful way to avoid needing to solve the packaging hellscape problem. It’s valuable to many! But definitely is the square peg to the round hole (security isolation layer) of setns and chroot and friends.

zie 3 days ago

You can make containers mostly as hardened security wise as a VM (but generally none of that comes by default), the big thing you can't get that a VM gives you is a new kernel instance. In a VM you have to break 2 kernels to totally own a machine.

In a container, provided the container software doesn't do it for you(which is likely true), you just have to break 1 kernel.

ryandrake 3 days ago

I always thought containers were how lazy developers solved the "I dunno, it works on my machine" problem: By shipping their entire machine.

  • zbentley 3 days ago

    Not the case; there's a fascinating history here.

    The technologies that enabled containerization (namespaces, chroot, and cgroups, and their predecessors on BSD/Solaris) were created specifically for security and resource isolation.

    The people who came up with "containers" as we know them today found a clever hack: combining those security-oriented tools with a filesystem-in-a-box and packaging system allowed people to package entire OS userlands and run them pretty deterministically in multiple places. The security isolation properties of namespaces/cgroups/chroot also happened to provide increased determinism.

    And I'm not criticizing that; containers are a very clever hack that solved a problem a lot of people have. I use them every day.

    That said, the fact that containers became so ubiquitous in the first place speaks a completely self-induced problem that we didn't need to have in the software engineering community. That problem is, unfortunately, human/incentive-related in nature, so containers are probably the best we're going to get--problem is, they're not that good.

    I complained about the root problems here awhile ago, easier to link than rehash that here: https://news.ycombinator.com/item?id=44069483

    Drew deVault also explained it much more thoroughly and better than I could: https://drewdevault.com/2021/09/27/Let-distros-do-their-job....