Homebrew 6.0 sandbox: what the systemd confinement actually does

Homebrew 6.0 ships a Linux sandbox that uses systemd's cgroup v2 and capability bounding to restrict formula access at install/run time, limiting the blast radius of buggy or malicious code. The sandbox is not containerization—it lacks namespace isolation and seccomp filters—but provides a sensible default for shared Linux environments. macOS Homebrew is unaffected.

Homebrew 6.0 shipped a Linux sandbox. Here's what that actually means in practice. The sandbox isn't containers. It's systemd sleep confinement applied per-formula at install/run time. When a formula runs, systemd places it in a cgroup slice with restricted access to filesystem paths, syscall capabilities, and device nodes. If the formula tries to write somewhere it shouldn't, the kernel enforces it at the cgroup level — not at the container boundary. On a dev workstation or shared Linux build box, Homebrew installs run under the same user context as everything else. A buggy or malicious formula can overwrite your dotfiles, read SSH keys if the agent is running, or trash /usr/local if permissions allow. The sandbox doesn't eliminate that risk, but it limits the blast radius. Specifically, the confinement: This isn't containerisation. There's no namespace isolation, no separate mount table, no seccomp filter applied by default. The sandbox constrains what the process can do through cgroup v2 and capability bounding, but a determined formula running as your user can still cause plenty of damage inside those limits. Also worth noting: this only applies on Linux. macOS Homebrew still relies on SIP and the normal Unix permission model. You can inspect the cgroup a formula is running in after install: Find the PID of a running formula pgrep -f <formula-name Check its cgroup slice cat /proc/<PID /cgroup If Homebrew's sandbox is active, the process will be under a homebrew.sandbox slice rather than the default user slice. Some formulae legitimately need wider access — building kernel modules, probing hardware, etc. You can bypass the sandbox per-install: HOMEBREW NO SANDBOX=1 brew install <formula Just be deliberate about when you do this. The sandbox exists precisely because a formula you didn't write is executing arbitrary code on your system. 6.0 moves Homebrew's threat model in the right direction for shared Linux environments. It's not a substitute for isolation tools when you need hard boundaries, but it's a sensible default that raises the bar without the operational overhead of containers. If you're managing multi-user Linux build machines, test it against your common formulae before rolling it out broadly — some build systems make assumptions about what they can access that conflict with the new restrictions.