2 ms·

Container escapes are more common than you think. Common enough for AWS not to rely on containers for their serverless functions, common enough for Google to sa

Container escapes are more common than you think. Common enough for AWS not to rely on containers for their serverless functions, common enough for Google to say: "Untrusted code shouldn't rely on the container security boundary [..]" [1] The same is not applicable for any kind of sandboxing for two reasons: 1. The boundary is in the kernal’s own code, enforced by the thing you are trying to be protected from. -> Use a VM 2. The kernal is a gigantic attack surface -> Use gVisor [1] https://docs.cloud.google.com/kubernetes-engine/docs/resources/security-patching https://docs.cloud.google.com/kubernetes-engine/docs/resourc...

LeBit 2mo ago
What if you use tools like bubblewrap or nono inside the container? Say I want to use pi inside a container. If I wrap pi within a bubblewrap or within nono, how is that less secure than using a vm? Also, I think most people run containers inside VMs anyway and not directly on their hosts (on Mac and windows you have to use a vm anyway).
- akdev1l 2mo ago
  bubble wrap is just doing the same cgroups work
  - LeBit 2mo ago
    Depending on the configuration, bubblewrap can substantially reduce the attack surface. It doesn’t change the fact a malicious process is still attacking the same kernel , but it can reduce what it can do to that vm.