alt Hacker NewsShow HN: Drop – A rootless Linux sandbox with gVisor support
I created Drop because I always felt uneasy installing and running third-party programs using my main user account. A single compromised dependency means a full compromise of the system. What is even worse, because I ship software from my computer, a single compromised dependency can lead to compromise of all the users of my software.
Containers and VMs are one solution, but for local work, they are often detrimental to productivity. It takes effort to configure a machine with all the tools and configs needed for productive work, but a container or a VM will be stripped of all these tools. This is great for production deployments, where the aim is a reproducible system with minimal dependencies, but can get in the way of productive local work.
Drop is language independent, but the workflow is inspired by Python's virtualenv. With virtualenv the environment isolation is only a convention that relies on installed dependencies being good citizens. With Drop the isolation is enforced.
Each Drop environment gets its own writable and easily disposable home dir, with only selected config files and dirs from the original home mounted, mostly read-only.
Drop uses Linux namespaces for isolation (user, mount, network, PID, IPC, cgroup), doesn't require root and, as an option, uses gVisor user-space kernel, which adds protection against exploiting host kernel vulnerabilities to escape the sandbox.
I don't want to make the introductory post too lengthy, but I'm here to answer any questions and give any additional technical details.
Note: This is my 3rd submission of the project, the first two did not draw attention. Since then I have added support for gVisor and created a project website to better explain the concept and organize documentation.
Comments
So there are a lot of ad-hoc solutions everybody is using for agent isolation and Drop looks well thought out. But the obvious question is what do the pros use? What does Anthropic, OpenAI, SpaceXAI, Google and Amazon do in house to deal with the isolated agent environment problem?
Based on past experience I'm guessing everybody is using Kubernetes, but what are the details? Stripped down VMs on Kubernetes? Hardened containers on Kubernetes? Can the rest of us spin up something comparable on K3s?
Anybody knows the answers and can share?
This is super interesting to me. I've slowly been working on something similar (https://gitlab.com/saghm/tartarus) because my ideal sandboxing is "prevent writing to anything outside this dir but still allow reading to most things so that I don't have to manually copy things into a container/VM". I approached it by trying to figure out how to build up a bubblewrap based on a config that gave the properties I wanted, with the hope that I could eventually expand it to support other platforms via stuff like `sandbox-exec` on MacOS, but I haven't had time to work on it more for a while.
At a glance, this seems to be providing most of what I was originally looking for when I ended up deciding I'd have to write it myself, but focusing specifically on Linux and providing a more full-fledged sandbox rather than only caring about a small set of permissions that I personally had a need for. Probably the biggest (and least hardened) feature that I spent time on in mine was trying to figure out how to allow arbitrary GUI apps so that I could run agents in it via Zed.
I'm definitely going to try this out and see how well it works for me. It's insane to me that this is something none of the big AI companies have bothered solving this yet other than via opaque rules built into their harnesses or absolutely awful manual rules that expect me to hard-code shapes of shell commands that I want to allow or not allow.
Thank you for building it! I started using Drop a few weeks ago, and I've been very happy with it so far (thanks again for quickly fixing a few issues I've reported :)!).
For me, it nails the convenience vs isolation aspect quite well, and I would like to get to a point where I can use it for all my development by default.
The main challenges that I still have, which none of the solutions I've found so far resolve, are:
- development of containerized applications, where e.g., docker/podman compose is used to bring up services
- development of GUI applications with hardware acceleration, like games (maybe security contexts for pipewire and wayland, like what's done in flatpak would be a good path?)
When I did my research in this space last time, https://litterbox.work/ was another option I've considered, and it is very nice too, but the friction is a bit higher than drop: it's slower to rebuild envs, lacks a "base" config, etc. Drop was much easier to adopt for me so far.
Every comment is talking about their own sandbox implementation.
Gratulacje Jan! Looks like something critical to gain adoption these days, security-wise. For others who also wonder how it works, I find this docs page a bit more informative than the landing page https://droprun.sh/docs/sandbox-overview/
As everyone mention, there are a lot of implementations of this idea, and not only for agent workflows.
My own approach has the following features, hopefully that gets stolen into an actual softawre package at some point:
- Generate bwrap options (for use in bwrap or gVisor) rather than build the sandbox itself. I wont't trust a random sandbox.
- UDS based automatic HTTP proxy with popup or allowlist and reverse proxy to serve apps. (I won't trust any more net access).
- File based configuration (executable with shebang).
- Composable profiles and command line options for ad-hoc sandboxes.
- Manage system directories (use host's, use another distro's, use an OCI image, etc.) as well as home directory for the sandbox and how the "work" directory is shared.
Drop appears to do a few similar things, and it seems to fit well with how I use such systems. I would like to see more details about how the sandboxes are executed and about the security model.
Can you explain a bit more about the boundary between the environment and my system? Is it just giving read-only access to /usr/lib?
I use an alias to launch a Podman container with opencode in $PWD. It is fully ephemeral aside from the directories I map to it (usually a couple configs). XDG_HOME is local to that working dir. My only frustration is that my image is too minimal but that can be resolved.
I guess people are slowly realizing that giving LLMs r/w access to your entire machine is an utterly insane idea.
I did a quick look-around last month and decided to start using bwrap. But manually configuring it on a per-project basis is irritating. So I rolled out something for my own use (+ a couple of friends) based on bwrap.
What I do:
- start with `bwrap --clearenv --unshare-all --die-with-parent --tmpfs / ...`
- every single file and folder and envar I need has to be mapped in. I have profiles in TOML, and `prepare/probe` commands to make this task simpler
- `--tmpfs /` means sandbox inits as `/home/user` on tmpfs unless you specify your own `home` and `user` keys.
- `--unshare-all` means there is no network inside the sandbox. So I used `socat` to run a HTTP/S proxy inside. Lets me control exactly which host+port combinations can be accessed. But this means nothing except HTTP(S) works. So no ICMP/UDP/TCP.
- profiles can be extended via extend syntax (otherwise you have to prepare/probe/manually specify everything per profile which is a nightmare). Which lets me do a base -> net -> coding chain.
Glad to see this coming with gVisor support to help secure the Kernel- IMHO we should expect frontier models to find Kernel exploits.
I am working on a project similar in spirit that uses microsandbox (libkrun) to run inside a tiny and fast VM. It includes other security properties that are needed for some workloads.
* network allow lists
* credential masking
* github allow list
So this seems to be useful to me, when you run drop run it starts a child process and places it into a Linux namespace...it gives the process a separate identity and limited privileges so itt can appear to be root inside the sandbox without being root on the host. It also gives it a separate view of the filesystem and all processes inside see their own process tree rather than all host processes. same for network connections.
BUT IT DOESNT WORK ON MAC OS :( bummer (it's Linux-specific)
Guess i'll test it on a VPS
This is exactly what I was looking for - the website and docs are easy on the brain. I have some apps hosted on distrobox containers that I'd rather not have write access to my home dir.
Hello, cool project!
Can you explain to me what the benefit of using this is versus something like an LXC container? It is currently my preferred "temp dev env" that behaves like a full system. It can also be customized with cloud-init to load up my preferred settings.
What do you see as the main advantages of gvisor instead of working within a lightweight VM with full native performance?
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.
Have you ever tried to use proot?
It does not use process namespaces, and can run on Android (on Termux with proot-distro).
I've built something similar, but used landlock instead: https://github.com/denysvitali/boxy
How is this different than bwrap or srt and others? Im using bwrap to achieve read only everywhere and and write on pwd. Also pi and other coding agents all have sandboxing that work in similar way
I've been using gVisor with Docker (or Docker-compatible runtimes) via runsc for years.
It isn't obvious to me what this does that we haven't been able to do for some time now.
I like to use firecracmer, since it has no support for many things, eg host filesystem mounting in the guest.
Can you make any similar guarantees about Drop?
There are a lot of options in this space, but I feel utterly helpless. Which of these are really secure such that I could intentionally run malware without fear of my ssh keys being stolen?
All of the options I find seem to say something along the lines of, “We’re totally secure so long as you don’t Fizz the Bar or Twiddle the Quanzipulator”.
What is the most bullet proof, idiot proof option I should use?
So, the primary advantage of this over bubblewrap is the insulation layer between the program and kernel syscalls?
[dead]
Hi OP, funny enough I’m working on something very similar. Lots of us are I guess! Take that as validation of your thinking.
I like that your readme has a couple paragraphs comparing to popular tools in this space. Personally I feel it is a bit light on the security differentiators (if any). For example you are using the same fundamental primitives that are used in nsjail, runc, etc. Thus it seems you have recreated those libraries in some aspects, so would be curious to hear your rationale for approaching this way vs building explicitly on those primitives.