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.
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.
You definitely want to do that. I have a Github App that I use for my AI agents, and that has its own associated restricted credential.
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.
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.
> 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.
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.
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.
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.
* /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.
I was unpleasantly surprised that those default mounts weren't just included in the base toml config like the ones from the home dir. What's the purpose of having two different kinds of "defaults"?
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.
Thanks! I have GUI applications sandboxing on the roadmap. I also ponder the idea to add VM as the third runtime option (in addition to currently supported native Linux namespaces and gVisor). I'm not yet sure if this is feasible, but VM could allow to start containerized apps within the sandbox as it dodges the nested namespaces problems with containers.
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.
Or perhaps this is a new reality where for each current problem we will see myriad solutions because of how easy it is to put together a prototype with agents. 3 years ago having a sandbox was also an important problem to address, but we didn't see so many attempts.
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?
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.
This is a really interesting middle ground between venvs and containers. How much overhead does gVisor add in practice for typical local development workloads?
gVisor has performance benchmarks: https://gvisor.dev/docs/architecture_guide/performance/
Long ago I worked on and benchmarked a Linux user space virtual filesystem that used ptrace to intercept and amend system calls. For surprisingly many workloads, per system call performance overhead is negligible. This is because many programs either wait for IO, in which case the small added overhead of a system call doesn't really matter, or spend time on CPU doing some computation. Only workloads where kernel is hit with long series of syscalls have measurable performance overhead. The difference is visible in benchmarks, but not anything that a user is able to notice in an interactive shell session.
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.
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.
No, I haven't tried it, thanks for the pointer. It looks like something that could be used by Drop instead of Linux namespaces. I didn't yet encounter any obvious limitation of the namespaces (other that some distros, like Ubuntu, are keeping programs' access to the user namespace creation behind AppArmor allowlist, which makes the Drop installation more involved).
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.
Nice, albeit I am not sure I understand the threat profile. I see something like gvisor making sense in a multi-tenant enviroment, but presumably OP is not pulling in the sketchiest of sketchy dependencies and build artifacts. Further, I cannot see how something like this protects you against something like a typical supplychain attack.
MicroVMs make the most sense to me, as they are the simplest and cleanest abstraction. I personally use VMs with a mounted github repo and found it to be the simplest mental model. I block all network access except for the domains that the agent needs to talk to, and I remove sudo. Since its all scripted, the VM is easy to drop and recreate and I know exactly whats installed on it.
Drop is interesting because it is thinking about the approach differently - basically an extension of the user's existing userspace. This prevents files from being inadvertently deleted by the agent, but it doesn't prevent the agent from uploading files that it shouldn't be.
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.
To be honest, me also. I don't even use Docker either but it helps in conversations to keep it simple.
Since it isn't obvious to your, Docker and friends also have an entire content management system (pulling, pushing, tagging images and layers) as well as a build system.
I mean, Drop does mount host filesystem in the guest, the idea is that you keep working within your current distro and have access to some of its files.
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)
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.
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?
An interesting book "Countdown to Zero Day: Stuxnet and the Launch of the World's First Digital Weapon" describes how the researchers at Symantec who analyzed Stuxnet ran malware:
"They worked in Symantec’s Threat Intelligence Lab in Culver City, the cyber equivalent of a biodefense lab, where researchers could unleash malevolent code on a “red” network—a sandboxed system air-gapped from Symantec’s business network—to observe its hostile behavior in a controlled environment. To reach the ground-floor lab, workers passed through several sets of security doors, each with progressively more restrictive rules. The final gateway kept all but a handful of workers out and physically isolated the red network from computers connected to the outside internet. Portable media were prohibited here—no DVDs, CD-ROMs, or USB flash drives were allowed —to prevent workers from mindlessly slipping one into an infested machine and inadvertently carrying it out of the lab with a malicious specimen stowed away on it."
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.
Worth being explicit about the threat model, because it decides the design. Isolating against a compromised dependency needs filesystem and egress control. Isolating against your own agent getting prompt-injected needs the credentials to never be inside the sandbox at all. Most setups I see do the first and assume it covers the second.
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.
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.
https://github.com/gregwebs/agent-vm/#agent-vmCouldn't you use fine grained github tokens for some of what you're accomplishing with the github/network filtering?
You definitely want to do that. I have a Github App that I use for my AI agents, and that has its own associated restricted credential.
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.
The fine-grained tokens have some surprising permissions for "read only" https://github.com/orgs/community/discussions/180063
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.
> 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.
> That's what Codex does out of the box
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.
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.
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.
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.
I was unpleasantly surprised that those default mounts weren't just included in the base toml config like the ones from the home dir. What's the purpose of having two different kinds of "defaults"?
Thanks. I think it's probably more complicated than I need at the moment but good to know it is an option down the road!
This section of the docs might be helpful for you https://droprun.sh/docs/sandbox-overview/#filesystem-layout
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.
Thanks! I have GUI applications sandboxing on the roadmap. I also ponder the idea to add VM as the third runtime option (in addition to currently supported native Linux namespaces and gVisor). I'm not yet sure if this is feasible, but VM could allow to start containerized apps within the sandbox as it dodges the nested namespaces problems with containers.
hey there, smolvm might be the right tool for your needs of containerization + GUI with gpu acceleration through vulkan.
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.
Every comment is talking about their own sandbox implementation.
That makes me wonder if it is a tarpit idea.
Or perhaps this is a new reality where for each current problem we will see myriad solutions because of how easy it is to put together a prototype with agents. 3 years ago having a sandbox was also an important problem to address, but we didn't see so many attempts.
I think at the surface level it's a wide problem but the solutions so far are shallow attempts
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?
Not sure what the platforms are using, but this was recently released: https://github.com/agent-substrate/substrate
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.
This is a really interesting middle ground between venvs and containers. How much overhead does gVisor add in practice for typical local development workloads?
gVisor has performance benchmarks: https://gvisor.dev/docs/architecture_guide/performance/ Long ago I worked on and benchmarked a Linux user space virtual filesystem that used ptrace to intercept and amend system calls. For surprisingly many workloads, per system call performance overhead is negligible. This is because many programs either wait for IO, in which case the small added overhead of a system call doesn't really matter, or spend time on CPU doing some computation. Only workloads where kernel is hit with long series of syscalls have measurable performance overhead. The difference is visible in benchmarks, but not anything that a user is able to notice in an interactive shell session.
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.
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.
Have you ever tried to use proot?
It does not use process namespaces, and can run on Android (on Termux with proot-distro).
No, I haven't tried it, thanks for the pointer. It looks like something that could be used by Drop instead of Linux namespaces. I didn't yet encounter any obvious limitation of the namespaces (other that some distros, like Ubuntu, are keeping programs' access to the user namespace creation behind AppArmor allowlist, which makes the Drop installation more involved).
I've used proot in the past but it crashed often, I'm interested in finding other rootless chroot-like projects.
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.
Nice, albeit I am not sure I understand the threat profile. I see something like gvisor making sense in a multi-tenant enviroment, but presumably OP is not pulling in the sketchiest of sketchy dependencies and build artifacts. Further, I cannot see how something like this protects you against something like a typical supplychain attack.
That sounds like a huge hit to performance
Per syscall performance overhead has surprisingly low impact on overall performance of programs. gVisor's benchmarks are here: https://gvisor.dev/docs/architecture_guide/performance/
Why they instead of a microVM?
MicroVMs make the most sense to me, as they are the simplest and cleanest abstraction. I personally use VMs with a mounted github repo and found it to be the simplest mental model. I block all network access except for the domains that the agent needs to talk to, and I remove sudo. Since its all scripted, the VM is easy to drop and recreate and I know exactly whats installed on it.
Drop is interesting because it is thinking about the approach differently - basically an extension of the user's existing userspace. This prevents files from being inadvertently deleted by the agent, but it doesn't prevent the agent from uploading files that it shouldn't be.
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.
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.
To be honest, me also. I don't even use Docker either but it helps in conversations to keep it simple.
Since it isn't obvious to your, Docker and friends also have an entire content management system (pulling, pushing, tagging images and layers) as well as a build system.
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?
I mean, Drop does mount host filesystem in the guest, the idea is that you keep working within your current distro and have access to some of its files.
I don't see a difference to containers, which also use namespaces and make it easy to mount home as read only?
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
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.
Check out nono.
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?
An interesting book "Countdown to Zero Day: Stuxnet and the Launch of the World's First Digital Weapon" describes how the researchers at Symantec who analyzed Stuxnet ran malware:
"They worked in Symantec’s Threat Intelligence Lab in Culver City, the cyber equivalent of a biodefense lab, where researchers could unleash malevolent code on a “red” network—a sandboxed system air-gapped from Symantec’s business network—to observe its hostile behavior in a controlled environment. To reach the ground-floor lab, workers passed through several sets of security doors, each with progressively more restrictive rules. The final gateway kept all but a handful of workers out and physically isolated the red network from computers connected to the outside internet. Portable media were prohibited here—no DVDs, CD-ROMs, or USB flash drives were allowed —to prevent workers from mindlessly slipping one into an infested machine and inadvertently carrying it out of the lab with a malicious specimen stowed away on it."
A VM that doesn't contain your keys.
I've built something similar, but used landlock instead: https://github.com/denysvitali/boxy
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.
Does it work within containers?
Unfortunately not, and it also does not support starting containers from the sandbox.
Worth being explicit about the threat model, because it decides the design. Isolating against a compromised dependency needs filesystem and egress control. Isolating against your own agent getting prompt-injected needs the credentials to never be inside the sandbox at all. Most setups I see do the first and assume it covers the second.
For agent workloads, how are you separating "where the code runs" (namespace/gVisor/microVM) from "what credentials and egress ever enter that guest"?