Subscribe to updates

Get notified of new posts… via your podcast player!

Open your podcast player's subscriptions section, and add a podcast via its address – paste it from your clipboard, after copying the address there using the button below.

(You could use a feedreader instead, but most people don't have one of those other than their podcast player. So here we are: Podcast feed!)

llmao-af_moshpit – A TCP/unix/vsock proxy for (but not exclusively for) sandboxes

It’s done (medium rare), and here’s the readme.

Compile and install with: 

go install -v "nontrivialpursuit.org/llmao-af_moshpit@latest"
(After scrutinizing the source code, of course).

The run-up to building this

Part of this originally came out of a need to communicate with short-lived ephemeral network-isolated virtual machine instances, through vsock host-guest communication channels. Another use case was to allow untrusted code in such a throwaway VM (eg, npm install) to access only specifically allowlisted Internet hosts, specified by domain (ie, npmjs.org), without having to configure and painstakingly restrict the VM’s networking. Turns out this is very feasible, and the VM doesn’t even need DNS resolving capabilities (we wouldn’t want that, because that’d be a data exfiltration avenue).

Another part of this comes out of a quest to perfect my “run this code, but in a sandbox” oneliners. I’ve been using bubblewrap (and systemd’s isolation features) for years now to isolate processes, for instance to perform operations on user-supplied images; image processing with user-supplied data is infamously (but not inherently) risky (at some point you could root your iphone just by visiting a site serving a particular .tiff) as so much of our image processing libraries have been written in unsafe languages, though that is changing.

And then a few years back I found myself working on a NodeJS codebase with the typical (for that ecosystem) hundreds-of-megabytes dependency tree (and that’s just the backend), and after some months of feeling queasy, set out to make wrappers to make running that code more safe. Just shell scripts at first, that would invoke bubblewrap’s bwrap just right for that project, but gradually growing more generalized. I had started doing this just before the Axios supply chain attack hit, and when that news broke I was very happy to have spent some time erecting such safety barriers.

And now, it’s agents building software. I’m using the Zed editor’s agent (Zed 1.18), but I’m not quite happy with its sandbox configuration. It uses bubblewrap under the hood, but it bind-mounts (read-only) the whole of / (thus, including my homedir, thus including my ~/.ssh, and my email client’s message cache, etc etc) into the sandbox. Not a good thing. Thus I’m currently working on making that more safe, for which this software may come to play a role in exposing choice network services to the agent.