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/

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.

Have you ever tried to use proot?

It does not use process namespaces, and can run on Android (on Termux with proot-distro).

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.

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.

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.

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.

Why they instead of a microVM?

Does it work within containers?

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.

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.

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.

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

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.