Re:Are we defaulting to VM-level sandboxing before understan...
by samhita-alla on Friday June 12, 2026 @01:15AM
(#48500193)
Supply chain attacks are a reasonable use case. But do they require VM-level isolation?
For example, what about a sandbox that isolates arbitrary user code in its own process using kernel-level primitives like user namespaces, Landlock and seccomp? That's the same class of problem Claude Code and Codex are solving when they execute model-generated commands, and it should also limit filesystem and network access as you mentioned. It's process-level isolation rather than VM-level isolation, but it still provides meaningful containment. What do you think?
My concern is that people often default to VM-level isolation without really thinking through what it's meant to protect against and whether they actually need it. It comes with a fairly heavy infra burden and isn't necessarily the right answer for every use case.
Re:Are we defaulting to VM-level sandboxing before understan...
by cpburns2009 on Friday June 12, 2026 @09:41AM
(#48503956)
I think process namespaces is what both Docker and Podman use along with cgroups for isolation. It should provide meaningful containment, and I was originally pursing using rootless Podman. But after hearing about the Copy Fail and recent container escape vulnerabilities, I'm concerned that is not enough. That's why I've opted for VM-level isolation, but at a more convenient level using KVM than full-fledged VMware VMs. I admit I'm not an expert in this space so maybe I'm overly cautious.
The threat model I'm concerned about is supply chain attacks on third-party package repositories. The primary goal is to keep the convenience of containers, but to limit the blast radius of a compromised package or application, and reduce the risk of container escape. The software stack I'm currently evaluating is:
- Kata Containers: Backend for containerd to run each container in a KVM-backed QEMU microVM (alternative to the standard runc).
- containerd: Container runtime. Docker and Podman are not compatible with Kata 3. Kata 4 is supposed to fix that.
- nerdctl: Docker-compatible front-end to containerd.
- cni-plugins: networking component for containerd. Used to isolate containers networks.
- iron-proxy: MitM, TLS-intercepting egress proxy. This restricts all outbound traffic to whitelisted domains and IPs, and supports secret injection. Squid is a more established alternative.
How is this used in practice? I have a small bash script to launch the sandboxed OpenCode container with the current folder bind-mounted. OpenCode only has file-system access to the context directory, and limited network/internet access.