3 ms·

Wouldn't it need a super critical exploit, I mean zero-day vulnerability, to escape from that kind of sandbox ? And if you think further, then isn't that risk a

• weinzierl 2mo ago
  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.