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.
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)
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.
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.
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.
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.
> 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.
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.
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.
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.
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.
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/
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
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.
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.
gVisor virtualizes all syscalls which pass through a host userspace golang process that then maps onto the host's syscalls.
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
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.
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.
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.
> 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.
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.
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.
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.
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.
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'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.
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/
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
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?
Have you ever tried to use proot?
It does not use process namespaces, and can run on Android (on Termux with proot-distro).
Does it work within containers?
So, the primary advantage of this over bubblewrap is the insulation layer between the program and kernel syscalls?
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.