Or perhaps this is a new reality where for each current problem we will see myriad solutions because of how easy it is to put together a prototype with agents. 3 years ago having a sandbox was also an important problem to address, but we didn't see so many attempts.
gVisor has performance benchmarks: https://gvisor.dev/docs/architecture_guide/performance/
Long ago I worked on and benchmarked a Linux user space virtual filesystem that used ptrace to intercept and amend system calls. For surprisingly many workloads, per system call performance overhead is negligible. This is because many programs either wait for IO, in which case the small added overhead of a system call doesn't really matter, or spend time on CPU doing some computation. Only workloads where kernel is hit with long series of syscalls have measurable performance overhead. The difference is visible in benchmarks, but not anything that a user is able to notice in an interactive shell session.
An interesting book "Countdown to Zero Day: Stuxnet and the Launch of the World's First Digital Weapon" describes how the researchers at Symantec who analyzed Stuxnet ran malware:
"They worked in Symantec’s Threat Intelligence Lab in Culver City, the cyber equivalent of a biodefense lab, where researchers could unleash malevolent code on a “red” network—a sandboxed system air-gapped from Symantec’s business network—to observe its hostile behavior in a controlled environment. To reach the ground-floor lab, workers passed through several sets of security doors, each with progressively more restrictive rules. The final gateway kept all but a handful of workers out and physically isolated the red network from computers connected to the outside internet. Portable media were prohibited here—no DVDs, CD-ROMs, or USB flash drives were allowed —to prevent workers from mindlessly slipping one into an infested machine and inadvertently carrying it out of the lab with a malicious specimen stowed away on it."
No, I haven't tried it, thanks for the pointer. It looks like something that could be used by Drop instead of Linux namespaces. I didn't yet encounter any obvious limitation of the namespaces (other that some distros, like Ubuntu, are keeping programs' access to the user namespace creation behind AppArmor allowlist, which makes the Drop installation more involved).
I mean, Drop does mount host filesystem in the guest, the idea is that you keep working within your current distro and have access to some of its files.
Thanks! I have GUI applications sandboxing on the roadmap. I also ponder the idea to add VM as the third runtime option (in addition to currently supported native Linux namespaces and gVisor). I'm not yet sure if this is feasible, but VM could allow to start containerized apps within the sandbox as it dodges the nested namespaces problems with containers.
* /usr is from your host, so you don't need to maintain a separate image to have programs that you already have installed.
* username, hostname, your current directory and home dir paths are preserved in the sandbox (within a Podman container a home dir is /root)
* environment variables are easy to carry into the sandbox.
* environments are explicit (`drop ls` lists them) and can be removed with `drop rm`, so you don't need to track in which dirs you have started Podman if you want to cleanup XDG_HOME files.
It is likely that your Podman wrapper also solves some of these or they are non-issues for your. If your setup works well, I wouldn't switch to something different.
I was unpleasantly surprised that those default mounts weren't just included in the base toml config like the ones from the home dir. What's the purpose of having two different kinds of "defaults"?
> 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.
reply