Wouldn't it need a super critical exploit, I mean zero-day vulnerability, to esc...

weinzierl · 2026-08-10T09:18:08

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/resourc...

LeBit · 2026-08-10T10:01:58

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 · 2026-08-10T12:21:45

bubble wrap is just doing the same cgroups work

LeBit · 2026-08-10T12:46:48

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.