Show HN: Drop – A rootless Linux sandbox with gVisor support

Thanks! My initial approach and the first prototype was for Drop to be a Python script that generates config.json file for runc Docker runtime (I also tried crun). I ran into issues that prevented the sandbox from being set up with all the Drop-required properties. These issues were certainly technically fixable, but it could be difficult for a new project with no usage to advocate for features in mature and widely adopted tools. Especially that runc and crun are OCI-compatible Container Runtimes, and Drop is not an OCI-compatible container, so it could be justifiably out of scope for these projects not to support Drop usage.

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.

This table shows which dirs are exposed from your system: https://droprun.sh/docs/sandbox-overview/#filesystem-layout

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.

This section of the docs might be helpful for you https://droprun.sh/docs/sandbox-overview/#filesystem-layout

> 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"

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.

Small world, we’re all working on the same thing!

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.

Couldn't you use fine grained github tokens for some of what you're accomplishing with the github/network filtering?

gVisor virtualizes all syscalls which pass through a host userspace golang process that then maps onto the host's syscalls.

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.

I've been able to use cgroups and net namespaces for years.

It's isn't obvious to me what Docker does that we haven't been able to do for some time now.

read-only everywhere and write only to the current directory is good if you want to prevent accidental damage, such as a coding agent could make if it hallucinated an invalid command, like `rm -rf ~`.

If you want to prevent a damage from a malicious dependency or a prompt injection, you need more robust protection (for example read-only everywhere exposes your ssh keys). You can build this on top of bwrap, but because it is a low level sandbox building block, you would likely end up creating some higher level abstraction on top of bwrap (for example srt and Flatpak are build on top of bwrap).

Drop is an attempt to create such a generic, high level sandboxing tool. I personally prefer to run agents already within a sandbox than to rely on a coding agent runtime to sandbox itself. Especially that by doing so, I can use the same sandboxing tool and config for installing other programs that need isolation, not just for running agents.

Bubblewrap is a low level tool, it describes itself as a sandbox building block, rather than a high-level sandbox intended to be used directly (for example, Flatpak uses bubblewrap as its building block). Drop in contrast is high-level, designed to be used directly in day-to-day work without the need to assemble the low-level details of the sandbox.