My approach with Drop was to start from designing a sandbox user experience. The key idea was to preserve as many aspects of the user's work environment as possible while isolating things that need to be isolated. So keeping the user's distro with all the currently installed packages is the key thing for Drop.

The first Drop version (and the current default runtime) uses Linux namespaces alone to achieve this.

Then, gVisor was added as the second runtime, because it could be done in a way which is completely seamless from the user perspective, both runtimes produce identically looking sandboxes.

A lightweight VM could potentially be a third runtime, but I'm not yet sure it is possible to use a VM in such a way, that the sandbox is configured identically to the first two runtimes. Basically, quickly boot a kernel using the distro already in / and mount the same dirs Drop mounts with two other runtimes. An obvious problem I can already see is that /etc is not fully readable to the user running Drop, so using it to boot a VM will require working around lack of config file access.

Anyway, if VM support was possible, it would obviously have advantage of being fully compatible standard Linux kernel while providing very good isolation of the host kernel. gVisor does have some compatibility issue, as it is re-implementation of the kernel in Go.

Another advantage would be that with VM runtime it would be possible to start containers from Drop, which currently, due to issues related to nested namespaces, is not supported.

> As the container escapes with K8s shows, it is super tricky to get isolation right. E.g. what happens if a file you think is safe to write to is suddenly is replaced by one that isn’t.

I agree. One thing I'm doing is to review past security problems in popular sandbox and container related projects and check if they apply to Drop. Drop is also rootless only (it won't even start as root), which helps to cut some classes of problems.