As AI accelerates kernel vulnerability discovery and exploitation, the barrier to escaping containers by attacking kernel has fallen so significantly that we must assume attackers can do so at will.
You definitely don’t need containers to “run something that needs a different dependency”, it’s a massive waste of time and resources and just not what containers were made for. There are/were a thousand other solutions for this, from Nix to chroot to building from source to LD_LIBRARY_PATH to AppImage.
Containers were initially sold as a “security boundary” of sorts. The ability to run some software with the peace of mind that it won’t ruin your OS or leak all your data if it’s vulnerable. It’s the entire point, but it turns out to be extremely difficult to get right. We managed to make a boundary against accidentally messing something up, not against targeted attacks.
Yeah, but Nix and every other solution you mentioned has their own tradeoff and ease of use friction between developer and devops. Containers have good ergonomics for both that it reduces friction to achieve ci/cd
You’re talking about sandbox type container-based app packaging, like flatpak, appimage, or snaps I think. Containers in the libcontainer/docker sense were always supposed to be “lightweight self-contained runtime environments.” It simplified deployment and operations by decoupling infrastructure from code. If it were made with security applications in mind from the start, rootless would have been supported properly
You definitely don’t need containers to “run something that needs a different dependency”, it’s a massive waste of time and resources and just not what containers were made for. There are/were a thousand other solutions for this, from Nix to
chrootto building from source toLD_LIBRARY_PATHto AppImage.Containers were initially sold as a “security boundary” of sorts. The ability to run some software with the peace of mind that it won’t ruin your OS or leak all your data if it’s vulnerable. It’s the entire point, but it turns out to be extremely difficult to get right. We managed to make a boundary against accidentally messing something up, not against targeted attacks.
Yeah, but Nix and every other solution you mentioned has their own tradeoff and ease of use friction between developer and devops. Containers have good ergonomics for both that it reduces friction to achieve ci/cd
You’re talking about sandbox type container-based app packaging, like flatpak, appimage, or snaps I think. Containers in the libcontainer/docker sense were always supposed to be “lightweight self-contained runtime environments.” It simplified deployment and operations by decoupling infrastructure from code. If it were made with security applications in mind from the start, rootless would have been supported properly