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…
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.
63 comments
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.
Anyway, my decision, for which I also evaluated the use of bubblewrap as a building block, was to err on the side of flexibility that calling fine-grained Linux APIs directly give. For a project like Drop, runc could be seen as very coarse-grained JSON-based API to Linux sandboxing calls (basically a single call: setup a sandbox, here is a json config that describes it), similarly bubblewrap is a coarse grained command-line API to Linux sandboxing calls. Reusing such tried and proved layers of course also has significant advantages, so as in case of many engineering decision, it wasn't super obvious which path is better.
Drop eventually integrated gVisor's runsc (as an option), which is also OCI-compatible Container Runtime, but this is to add a user-space kernel isolation layer.
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
There are going to be cases where you want to white list an org or a repo for read access that is not under your control and Github filtering will be a simple way to do that.
Github can be a source of hostile code, prompt injections, and exfiltration- you may want to lock down using repos that aren't yours.
The tool inherited this feature from the prior implementation and its something I am still exploring.
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.
That's what Codex does out of the box, and it's not good against malware - i.e. a rogue npm packet (or even just codex after prompt injection) can read your ssh key and send it to the attacker.
As I said, opaque rules built into the harness rub me the the wrong way. They could change in an update without anything making it clear. Plus, I don't use Codex outside of work (I don't have any active paid subscriptions LLM offerings).
> it's not good against malware - i.e. a rogue npm packet (or even just codex after prompt injection) can read your ssh key and send it to the attacker
Ignoring the repeated references to software I don't personally use, I never said I was trying to hedge against malware. The use case for me is when I'm running agents directly based off of prompts that I give them and asking them to modify some files. If I wanted a solution for running code I didn't trust, I wouldn't rely on what I wrote, because that's not the intended use case at all.
I went with Docker because history has taught me that new isolation strategies _will_ have escape bugs at some point, and I’m distrustful that the LLM can’t find one if it wants to.
> 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 actually have code for this if you want to use/fork/borrow it. TLDR, mine pretends to be an ACP agent so you run Zed on the host, but under the hood that binary is just creating a Docker container with your image and agent, copying files, etc, and then proxying ACP messages via web socket back and forth. Except for the built-in ACP read/write file and shell endpoints. Those get executed inside the container by the proxy by default, though there’s a config option to pass either or both through to the host.
Repo is https://github.com/SethCurry/abyss and the code you’d want would be in ‘internal/websockets/wsacp’.
It does wrap them in protobuf and there’s some router-like stuff so you can add your own non-ACP messages between the two ends of the proxy.
main also has experimental wasm plugin support in the proxies so you can block prompts/tool calls/whatever in an agent-independent way, or add RAG that works for every agent in the world, or whatever.
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.
Compared to your setup:
* /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.
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.
Read the full thread on Hacker News →
Related stories
- Hacker News · 3 points · 3 days ago
- Hacker News · 15 points · 13 days ago
- Launch HN: Vespper (YC F24) – SOTA Docx MCPvespper.comHacker News · 31 points · 2 days ago
- Hacker News · 1 points · 3 days ago
- Hacker News · 1 points · 9 days ago
- Hacker News · 1 points · 1 day ago