landrun

Overview

landrun is an open-source CLI tool written in Go that sandboxes any Linux process using the kernel's Landlock LSM (Linux Security Module). The pitch: fine-grained filesystem and network access controls without containers, without root, and without touching SELinux or AppArmor.

Where tools like yolobox and shai wrap processes in Docker containers, landrun takes a fundamentally different approach — it asks the kernel to enforce the restrictions directly. No daemon running in the background. No container images to pull. No runtime overhead. Just a small Go binary that sets Landlock rules and then exec's your command.

The project launched on Hacker News in March 2025 and quickly became the most popular Landlock wrapper tool, accumulating 2,156 stars. It also got picked up on Slashdot, which is a rare signal for a security CLI tool.

How It Works

landrun uses a simple CLI interface to define access policies, then enforces them via Landlock before executing the target command:

landrun \
  --allow-read /usr --allow-read /etc \
  --allow-read-write /home/user/project \
  --allow-tcp-connect 443 \
  -- python3 my_script.py

This command lets the Python script read from /usr and /etc, read and write to the project directory, and make outbound HTTPS connections — nothing else. No access to ~/.ssh, ~/.aws, or the rest of the filesystem. No binding to local ports. No reading other users' files.

The enforcement model is:

1. Parse the policy from CLI flags — which paths get read/write/execute access, which TCP ports can be bound or connected to
2. Apply Landlock rules via the kernel's Landlock syscalls — this creates an irreversible security sandbox for the process
3. exec the command — the target process runs with the Landlock rules in place. The process (and all its children) cannot escape the sandbox, even with root privileges inside it

The "irreversible" part is key. Once Landlock rules are applied to a process, they cannot be loosened — only tightened. This is enforced by the kernel, not by landrun. Even if the sandboxed process finds a way to execute arbitrary code, it cannot remove its own restrictions.

Landlock Explained

Landlock is a Linux Security Module that's been in the kernel since version 5.13 (July 2021). Unlike SELinux and AppArmor, which require root to configure and operate at the system level, Landlock is designed for unprivileged, per-process sandboxing.

The key properties:

• Unprivileged — any process can sandbox itself, no root needed
• Stackable — Landlock works alongside SELinux, AppArmor, and other LSMs
• Irreversible — once applied, rules can only be made stricter, never looser
• Inherited — child processes inherit (and cannot escape) parent restrictions
• Kernel-enforced — restrictions are enforced by the kernel, not a userspace daemon

Landlock has evolved through five ABI versions:

Version	Kernel	Added
v1	5.13	Filesystem access control
v2	5.19	File refer (rename/link across dirs)
v3	6.2	File truncation control
v4	6.7	TCP bind and connect restrictions
v5	6.10	IOCTL on device files

landrun detects the available Landlock version at runtime and uses the highest supported ABI. On older kernels, it gracefully degrades — you get filesystem sandboxing on 5.13+ and network sandboxing on 6.7+.

Agent Use Cases

While landrun is a general-purpose sandboxing tool, it's increasingly appearing in discussions about AI coding agent safety. The use case is straightforward: you want an AI agent to edit files in your project directory, but you don't want it reading your SSH keys, AWS credentials, or browser cookies.

A typical agent sandboxing setup:

landrun \
  --allow-read /usr --allow-read /etc --allow-read /lib \
  --allow-read-write /home/user/my-project \
  --allow-tcp-connect 443 \
  -- claude-code --dangerously-skip-permissions

This gives the agent full read-write access to the project, read access to system libraries (so it can run tools), outbound HTTPS (so it can call APIs), and nothing else. No reading ~/.gitconfig for your email. No accessing ~/.config for stored tokens. No binding to local ports to exfiltrate data via a reverse shell.

HN commenters specifically called out landrun as superior to container-based approaches for this use case, because:

• No overhead — no container startup time, no image layers, no daemon
• Kernel enforcement — the sandbox can't be escaped by the sandboxed process, even with privilege escalation
• Composable — can be combined with other security tools (seccomp, namespaces) for defense in depth

The limitation is that landrun provides filesystem and network controls, but not process isolation, memory limits, or PID namespaces. For full isolation, containers still win. For "don't let this process read my secrets," landrun is more precise and lighter.

Strengths

• Zero overhead — no daemon, no runtime, no images. Landlock rules are applied via syscalls and enforced by the kernel with negligible performance impact
• Kernel-level enforcement — restrictions can't be bypassed from userspace, even by root inside the sandbox. This is stronger than any container-based approach
• Dead simple — a single binary with CLI flags. No config files, no YAML, no learning curve beyond "what paths should this process access?"
• Auditable — the entire codebase is a small Go binary. You can read and understand the whole thing in an afternoon
• No root required — unlike SELinux/AppArmor policies or Docker daemon, any user can sandbox their own processes
• Progressive enhancement — works on kernels as old as 5.13, gains features on newer kernels automatically

Weaknesses

• Linux only — Landlock is a Linux kernel feature. No macOS, no Windows, no WSL1. This is the biggest adoption barrier for developer tools
• Not full isolation — landrun controls filesystem and network access, but doesn't provide PID namespaces, memory limits, or CPU caps. A misbehaving process can still fork-bomb or consume all memory
• Kernel version dependency — network restrictions require kernel 6.7+. Many production servers and cloud VMs run older kernels where you only get filesystem sandboxing
• No GPU/device passthrough model — no concept of GPU access controls or device-level permissions beyond basic IOCTL filtering in Landlock v5
• No built-in audit logging — landrun enforces restrictions but doesn't log what was blocked. You need separate tooling (auditd, etc.) to see denied access attempts
• Young project — created March 2025, single primary maintainer (Zouuup). Bus factor of 1

Bottom Line

landrun represents a philosophically different approach to process sandboxing. Instead of wrapping processes in containers (which are complex, heavyweight, and provide isolation-by-abstraction), it uses the kernel's own access control primitives to enforce restrictions directly. The result is simpler, lighter, and arguably more secure — the kernel is the enforcer, not a userspace daemon.

The 2,156 stars and enthusiastic HN reception suggest developers are hungry for this approach. The Linux-only limitation is real, but for the server-side and CI/CD contexts where AI agents increasingly run, Linux is the dominant OS anyway.

The interesting tension is between landrun's surgical precision (control exactly which paths and ports a process can access) and container-based tools' broader isolation (full filesystem, network, and process namespace separation). For AI coding agents specifically, landrun's approach may be the better fit — agents need access to specific project files and specific network endpoints, and landrun lets you express exactly that policy without the overhead of a full container runtime.

If you're running AI agents on Linux and want the lightest-weight, strongest-guarantee sandboxing available, landrun is the tool to watch.