undefined

points

[-]

It’s the same approach as gVisor. Fairly decent isolation if your application can work on it, but your SOL if a scenario comes up that doesn’t work. VMs give you pretty much 100% Linux compatibility at the expense of density, optimal resource allocation and startup time. gVisor gives you excellent startup time, resource allocation and density at the expense of some app compat and performance at the extremes

Edit: at least with gvisor you get close to a decade of work on compat. gVisor can support some rootless containers scenarios and systemd these days.

by mbreese5 hours ago|

prev|

[-]

I’d be very interested in it if it started to approach VM style isolation without needing KVM access (or qemu).

But I’m not sure if that is really possible.

The use case I’m thinking about is a sandbox exec isolation on an HPC cluster without Docker. I know singularity/apptainer exist, but I’m always looking for something that could make that environment more flexible. It is a tight security environment, so we are always limited in what we can do.

by eddythompson805 hours ago|

parent|

[-]

It all becomes a religion to some people. hypervisor escapes are a thing. People always point to Vt-x or AMD-V as having stood the test of time, and that might be true, but the software layer on top certainly hasn’t. Yet you will have “security professionals” tell you that you can’t trust anything beyond a hypervisor. Or they might tell you that a user space kernel is just as secure. They might tell you KVM is a no-go because of bad Type1/Type2 hybrid architecture compared to Xen or HyperV Type1. All have had their fair share of vulnerabilities over the years. All less than Linux process isolation, but still.

by bayindirh4 hours ago|

parent|

[-]

I really like Virtualization to keep things separate, but I never thought of it as an impenetrable wall. For example, I'd not trust an AI agent even inside a VM in my own system.

OTOH, running a messy environment with rollback support is much easier with a VM than a container.

Containers are fun for packing messy executables into their own environment and run them now and then, though.

by eddythompson803 hours ago|

parent|

[-]

I don’t find VMs to be that much easier to manage (in terms of rollback) than containers. The opposite in fact. VMs are these giant blobs that can be stateful or stateless or a mix of both. While containers have clear separation between the state (stored on volumes or in an external store like a db) and the “application” stored in immutable tags or digests.

Rolling back is easy as long as you understand where the state, if any, is which is actually the hard part of any application. At least with containers you have all of them stored in a well defined registry, while with VMs you would be rolling your own VM snapshot storage system. Not super complicated to do in the grand scheme of things, but it’s another thing you need to get right. But VMs/applications that can rollback would be just as easy (if not easier) to rollback with containers.

by imtringued1 hours ago|

parent|

prev|

[-]

>I really like Virtualization to keep things separate, but I never thought of it as an impenetrable wall. For example, I'd not trust an AI agent even inside a VM in my own system.

Remember the submission about how Auto Review is safe? Their standard of safe is that it will take a playwright dependency of another project in your home directory and add playwright based tests to your current project that hasn't declared playwright as a dependency. Amazing.

The issue literally isn't even about a hypothetical security argument anymore. Your sandbox is now a policy that tells the agent what it is allowed to do or not.

by photios6 hours ago|

prev|

[-]

I wonder if this can grow into a capability-based security tool.

by Pawenniag2 hours ago|

prev|

[-]

[flagged]