I'm confused why VM + systemd-nspawn? From my understaing WSL 2 runs a single VM + something like systemd-nspawn per "linux installation", but it runs a VM because it needs linux kernel. Why not just do systemd-nspawn if you alread on linux?
Way better isolation, is my guess. Plus, you can use a different kernel this way.
I used to poo-poo when people said that containers aren't a _real_ security boundary, at least for personal stuff, and not a multi-tenant server. But I bet even mid-tier LLMs can break out of LXC/Docker/nspawn at this point.
CVEs for runc are much more frequent than CVEs for KVM. The attack surface area is bigger, and containers were never intended as a security boundary, but rather as a resource management tool.
it is quite likely that you can break out even with no linux containers related CVEs. --isolate does seem to fix that somehow but is explicit opt. in and "more painful to use" ... (which creates a UX challenge unlikely to end well from a security POV).
I was just testing this and it's not clear that it works out of the box. `krun` shows a different kernel than with `crun` but it doesn't reflect the dropped capabilities in the same way. I'm probably holding it wrong but I'm not sure what to look for at the moment.
0x457 · · focus · HN ↗
pkulak · · focus · HN ↗
I used to poo-poo when people said that containers aren't a _real_ security boundary, at least for personal stuff, and not a multi-tenant server. But I bet even mid-tier LLMs can break out of LXC/Docker/nspawn at this point.
fhn · · focus · HN ↗
bloppe · · focus · HN ↗
dathinab · · focus · HN ↗
> Your files and your account [..]
> Ports and windows on the host
it is quite likely that you can break out even with no linux containers related CVEs. --isolate does seem to fix that somehow but is explicit opt. in and "more painful to use" ... (which creates a UX challenge unlikely to end well from a security POV).
akdev1l · · focus · HN ↗
zenoprax · · focus · HN ↗