Drop Lets You Run Code in a Sandbox Without Asking for Root

Drop is a sandbox for Linux that lets you run code without giving it full access to your machine. It is a new project on Hacker News, and it has people talking because it does something simple: it keeps your home directory safe no matter what the code running inside it tries to do.

The Problem Drop Solves

The usual trick for running code in a box is to build a whole new virtual machine, complete with its own kernel and its own copy of everything you have running already. That works, but it is slow and it wastes space. Drop takes a different path. It uses your existing distribution, so every program you have already installed is available inside the sandbox without any extra setup.

That matters for anyone who manages code agents. Those agents often need to run commands with elevated permissions, and that permission can be broken. Drop keeps a copy of your home directory in the background while the sandboxed code runs in its own space. A command that would normally erase your files gets stopped at the boundary.

How It Works

Drop runs inside a Linux user namespace. That is a way of running a process in its own separate box, with its own processes, mount points, network connections and IPC space. Drop drops all of those capabilities before the sandboxed program starts. The program inside the sandbox cannot do anything that needs elevated privilege, like binding a mount point.

The setup language is TOML, a high-level way of describing which files, directories and network services should be shown to the sandbox. By default, all Drop sandboxes share a base configuration, so you can set Drop up once and then create new environments without repeating the work.

Why Rootless Matters

The big selling point is that Drop does not need root to run. That is a real difference from Docker and Podman, which require elevated permissions to work. Drop runs on its own, and it never needs the full power of the host machine.

That means you can run Drop on a shared server without asking for a special account. It also means the sandboxed program cannot break out of its box, because it cannot bind mounts or open ports the way a container can.

The Dangerously-Skip-Permissions Flag

One of the flags in the Drop command line is called --dangerously-skip-permissions. It is exactly what it sounds like: a way to run a program without any permission checking. That is a terrible idea outside a sandbox, but inside Drop it just means the sandbox itself enforces the rules.

A prompt injection that would normally read your SSH keys finds nothing.

The example the project gives is rm -rf ~. That command is the classic way to destroy a home directory. Inside Drop, it fails. The sandboxed code cannot touch the real files. A prompt injection that would normally read your SSH keys finds nothing. A connection to services running on localhost is rejected.

Isolation for Coding Agents

The project is pitched at people who manage coding agents, and the examples it gives are specific to that use case. You can install a coding agent inside a Drop environment and give it full permissions inside the box, then let Drop enforce the rules at the operating system level.

That is the kind of setup that gets complicated fast. If the agent is malicious or compromised, the damage is contained within the sandbox. The home directory is hidden, the network services are exposed only as the TOML config allows, and the program cannot bind mounts to escape.

Third-Party Programs

The same logic applies to any program you want to keep separate from your regular user account. You can install something from PyPI or npm without giving it full access to your machine. The sandbox keeps the damage contained, so a supply chain attack on one of those packages does not spread.

gVisor Support

The optional layer is gVisor. It is a user-space kernel that sits between the program and the host kernel. That means the program never touches the host kernel directly, and the chance of exploiting a kernel vulnerability drops.

That is a second layer of isolation, and it is the kind of thing that only matters for the most hostile code. For most users, the base Drop sandbox is enough. For the paranoid, gVisor is the extra pad.

How It Compares

What This Means for You

The project is a simple idea, but it solves a real problem. Running code with elevated permissions is dangerous. Containers are slow and wasteful. Drop offers a middle path that does not require root and does not waste your distribution.

The rm -rf example is a joke, but it is also the point. The code inside the sandbox can do anything it wants, and the joke is that it cannot do anything to you. That is the value of the sandbox.

The Verdict

Drop is a small tool with a big payoff. It gives you a way to run code in isolation without the overhead of a full container, and it does it without asking for elevated permissions. The gVisor support is a bonus, and the TOML config makes it easy to set up once and forget.

The project is worth a look if you manage code agents or just want to run third-party software without trusting it fully. It is a tool that lives in the background, and it lets you run code without the fear that usually comes with it. That is a rare thing in software, and it is the reason this project is making its way around Hacker News today.

The rm -rf joke is the headline, but the real story is the isolation itself. Drop keeps your home directory safe, and that is a promise most tools cannot make.

Source material: “Show HN: Drop – A rootless Linux sandbox with gVisor support,” droprun.sh.

containers · gVisor · Linux · open source · root access · sandbox