A (Sand)Box Of Go

Hi ,

I know, this newsletter is in summer break right now, but I thought I'd send you a small "mid-break" issue.

I've been experimenting with Microsandbox, a microVM that's dead simple to use, for a few months now. I prepared a Spotlight article about it back then, but the tool wasn't super stable at that time. So I continued using Microsandbox VMs and watched the project maturing and the tool becoming really stable over time. No more excuses for keeping the article in the drawers! See the spotlight section below or read it on appliedgo.net.

Now, what's new around Go? Some news I picked up recently:

• Anton Zhyanov goes backward but otherwise makes good progress with his language Solod, a subset of Go that compiles to C.
• JetBrains will be hosting a Go 1.27 release party at August 25th (reservation required). Show hosts are Jesús Espino and Ainsley Clark, and a few members of the Go team will talk about the changes in Go 1.27: Robert Grisemer, Alan Donovan, Mark Dougherty, and Cameron Balahan, plus regular Go contributor Joe Tsai.
• Redowan Delowar [advises to (and how to) supervise goroutines with a three-function API (New(), Submit(), Stop()).
• Chris Siebenmann slices and dices the memory of a (simple) Go 1.27 program.
• And while you are reading this, the security releases Go 1.26.6 and Go 1.25.13 are probably already out.

Until the next issue!

–Christoph

Spotlight: Secure code execution with Microsandbox

If you have some untrusted code you must (or want) run, including but not limited to AI agents, the usual answer is: use a VM. Now, the answer is valid but hides a few uncomfortable details.

To start with, virtual machines (VMs) are quite bulky. They boot a whole OS inside a hardware emulation box, and every instance of a VM claims significant amounts of resources from the host. Containers (OCI containers, that is) are much more lightweight but haven't the same level of isolation. Secure execution isn't among their core strengths.

MicroVMs

Not too long ago, microVMs entered the stage. A microVM attempts to marry the lightness of containers with the strict isolation of VMs. The best of both worlds! Since then, I've been looking for an easy-to-use microVM system, but the ones I came across were complicated to install and use, or Linux-only, or nothing but a proof of concept. Oh, and there are lightweight security-elevating approaches like bubblewrap or Docker Sandboxes, but they don't reach the levels of isolation of a VM. They simply can't—it's a conceptual limit.[^1]

Microsandbox is so easy to use that there are no more excuses for running an LLM in yolo mode outside a VM.

Then I found microsandbox.dev, and I was immediately hooked by the straightforward way it works. It's so easy to use that there are no more excuses for running an LLM in yolo mode outside a VM, or any other code you don't fully trust.

Microsandbox's security measures

A microsandbox restricts access to the filesystem, the network, and other resources in a configurable manner. For example, I can give an AI agent access to only one or a few select folders on my laptop and allow access to particular web pages only.

My favorite security feature is how Microsandbox handles secrets. The problem with secrets is that you basically cannot store them anywhere safely. Whether they're in a file, in the process environment, or even only in the process' main memory, secrets aren't safe from extraction.

Try this on Linux to get a taste of the ease of reading data of a running process:

1. Get the PID of a process
2. Run

   cat /proc/<PID>/environ | tr '\0' '\n'
   

Now you see all the process' environment variables, including any GITHUB_TOKEN or OPENAI_TOKEN or other secrets stored there.

Even process memory isn't safe. An attacker can trigger a core dump, which dumps the process' current state to disk. Now anything that was in the process memory at the time of the core dump is but a file read away.

Also, privileged processes can attach to other processes via ptrace and read memory content live.

This is where Microsandbox gets interesting: If you pass a secret to a sandbox, Microsandbox replaces that secret with a dummy value. So a GitHub token looks like this inside the VM:

GITHUB_TOKEN=$MSB_GITHUB_TOKEN

Whenever a process sends a network request that contains this dummy value, Microsandbox replaces it on the fly with the acutal value that it holds safely outside the VM. No attacker inside the VM can ever grab that secret.

Smart!

Up within (milli-)seconds

Microsandbox lets you create ephemeral sandboxes on the fly, like so:

msb run ubuntu

This command downloads an ubuntu image, starts the VM, and opens a shell in your terminal. The active user is root, so you can start installing apps right away (try apt update && apt install golang but be aware that apt usually provides a sligthly outdated version of Go).

Parameters let you add bind mounts, set the user, run a command, and more.

You can, for example, open a shell as user ubuntu as easy as typing

msb run ubuntu -u ubuntu

When the image is already downloaded from a previous run, startup time goes down into the subsecond range.

Sandboxes become persistent by simply assigning them a name when creating them. They can be started, stopped, and they keep their state until they're removed.

Try this to create a persistent microVM named "goinabox":

msb run ubuntu -n goinabox

My current build script

Enough of theory; I bet you want to try out microsandboxes now. I have been experimenting a bit with microsandboxes, and I created a script to build a standard Ubuntu VM and install Go, some Go tools, and Claude. Later, I turned the script into a Dockerfile to create an image with all the goodies pre-installed.

But first the script; it's best for experimenting before

Here are the main parts:

First, the script creates a sandbox for user ubuntu with an Ubuntu image, 4GB maximum RAM usage, a maximum of 6 CPUs to use, and a bind mount that maps the current directory to the directory $HOME/workspace inside the VM.

(Note how the script injects the GITHUB_TOKEN value: It grabs the secret from my gopass vault and hands it over to msb's secret management.)

export home=/home/ubuntu
export user=ubuntu

msb create --name "$1" \
    --secret GITHUB_TOKEN="$(gopass app/ag/github-token)@api.github.com" \
  -u $user \
  -w $home \
  -v "$(pwd)":$home/workspace \
  -c 6 \
  -m 4G \
  --trust-host-cas \
  ubuntu

Then, the script installs curl, Go, and NeoVim as user root (as apt needs root rights).

Installing Go poses a small challenge: I want to install the latest Go version (which rules out apt install), yet there is no permanent link to the latest Go on go.dev/dl. So the script fetches the latest Go version from go.dev/VERSION and uses this to construct the name of the tar file to download.

I also had to set the target architecture dynamically, as I use Microsandbox.dev on Intel Linux machines and on macOS with an ARM architecture.

This is the resulting software installation part of the script:

msb exec "$1" -u root -- bash -c "set -eo pipefail
export DEBIAN_FRONTEND=noninteractive
export TZ=Europe/Berlin
apt update 
apt install -y curl 
echo 
echo Install Go
GO_VERSION=\$(curl -Ls https://go.dev/VERSION?m=text | head -n 1)
export arch=\"\$(uname -m)\"
case \$arch in
  arm64|aarch64)
    arch=arm64
    ;;
esac
curl -so /tmp/go.tar.gz -L# https://go.dev/dl/\${GO_VERSION}.linux-\$arch.tar.gz 
tar -C /usr/local -xzf /tmp/go.tar.gz
echo 'export PATH=\$PATH:/usr/local/go/bin:$home/go/bin' >> $home/.bashrc
echo
echo Install NeoVim
apt install neovim -y --no-install-recommends
"

For installing stuff in user space, I run another script inside the VM; this time, under the default user ubuntu:

msb exec "$1" -- bash -c "set -eo pipefail
echo Install user space stuff

"

As of this writing, I am running into an issue with repeated go install calls in the above script (which I removed because of this). After a few successful go install calls, the script errors out with a "server misbehaving" error while resolving proxy.golang.org.

Control a Microsandbox VM fom Go

While the CLI is super convenient to use, Microsandbox doesn't seem to be primarily designed for CLI use: The larger part of the documentation is about SDK use. SDKs exist for Rust, Python, TypeScript, ... and Go.

Imagine the possibilities when the best language for infrastructure teams up with a fast, secure micro-VM. Run isolated tests, create a replicable Go development environment, or call LLM agents that can't wreck havoc outside the VM[^2]: Go-orchestrated micro-VMs are a superb recipe against security breaches, especially in times of increasing numbers of supply chain attacks.

Conclusion

Microsandbox is so easy to use, you just can't not use it. Microsandbox's secrets management is a definite selling point, and so are the intuitive CLI and the Go SDK.

A word of caution, though: Microsandbox is pre-1.0 and under active development, so expect things to break. I had two such cases back in May or June, but they were quickly fixed by removing VMs and re-creating them with the new msb version. As of this writing, msb runs stable On My Machine™.

I definitely have plans with Microsandbox: I want to try the SDK, and I plan to switch from the standard ubuntu image to a Go image and turn my startup script into a Dockerfile, to have an instant, secured Go lab at my fingertips. So stay tuned.

[^1]: Em-dash proudly hand-crafted. [^2]: But remember there's always some risk remaining: Bugs in the VM code, misconfiguration that lets the LLM access things it shouldn't access (think interent connections), etc.