DEV.co
Open-Source Security · Zouuup

landrun

Landrun is a lightweight Linux sandbox tool that restricts what programs can access on the filesystem and network using kernel-level Landlock security. It requires no root, containers, or complex configuration—just pass flags to specify which paths and ports a command can use.

Source: GitHub — github.com/Zouuup/landrun
2.2k
GitHub stars
54
Forks
Go
Primary language
MIT
License (OSI-approved)

Key facts

Objective fields from the source. Values we can't verify are shown as “Unknown” rather than guessed.

FieldValue
RepositoryZouuup/landrun
OwnerZouuup
Primary languageGo
LicenseMIT — OSI-approved
Stars2.2k
Forks54
Open issues22
Latest releasev0.1.14 (2025-04-03)
Last updated2025-10-01
Sourcehttps://github.com/Zouuup/landrun

What landrun is

Go-based CLI wrapper around Linux Landlock (kernel 5.13+, network features require 6.7+) that applies fine-grained access control (read-only, read-write, execute) to filesystem paths and TCP ports. Supports best-effort mode for graceful degradation on older kernels and integrates with systemd.

Quickstart

Get the landrun source

Clone the repository and explore it locally.

terminalbash
git clone https://github.com/Zouuup/landrun.gitcd landrun# follow the project's README for install & configuration

Need it deployed, integrated, or customized instead? DEV.co ships production installs.

Best use cases

Sandboxing untrusted or third-party CLI tools

Run scripts, plugins, or utilities from uncertain sources with explicit allowlists for filesystem and network access. Blocks unexpected file reads, writes, or network activity.

Hardening systemd services and daemons

Deploy web servers, workers, or microservices with minimal required permissions (e.g., nginx bound only to ports 80/443, read-only config access, write-only to log directories).

Development and testing isolation

Quickly test build scripts, package managers, or installers in restricted environments without containers, verifying they don't access unexpected system directories.

Implementation considerations

  • Carefully enumerate required paths (binaries, libraries, config, working directories) per command; overly restrictive rules cause cryptic permission-denied errors—use strace or --log-level debug to diagnose.
  • Environment variables are not passed by default; explicitly pass HOME, PATH, and custom vars via --env flags or the sandboxed process will not inherit them.
  • For dynamically linked executables, include /usr/lib and /lib64 with --rox (execute permission required due to PROT_EXEC on mmap); --ldd flag automates this.
  • Network restrictions (--bind-tcp, --connect-tcp) only work on kernel 6.7+; fallback behavior or errors on older kernels depend on --best-effort flag.
  • Test sandboxing policies thoroughly before production deployment; a restrictive policy may silently fail if a required path or library is missing.

When to avoid it — and what to weigh

  • You need container-grade isolation — Landlock is a single-process sandbox, not process/PID/network namespace isolation. Does not prevent inter-process communication or resource exhaustion. Use containers for stronger isolation.
  • Your kernel is older than 5.13 or missing Landlock support — Landlock requires Linux 5.13+; network restrictions require 6.7+. Best-effort mode can degrade gracefully, but full features are unavailable on older/non-Linux systems.
  • You require SELinux/AppArmor policy integration — Landlock is independent; it does not interoperate with existing mandatory access control (MAC) policies. Coexistence with SELinux or AppArmor is untested.
  • You need enterprise support or SLA guarantees — This is a community-maintained project with no commercial backing, support contracts, or guaranteed response times for security issues.

License & commercial use

MIT License. Permissive OSI-approved license permitting commercial use, modification, and redistribution with minimal restrictions (preservation of license notice required).

MIT is a permissive, commercial-friendly license. However, no commercial support, warranties, or liability limitations are provided by the project. Evaluate your risk tolerance for using an unsupported community tool in production before relying on it commercially.

DEV.co evaluation signals

Editorial assessment — not user reviews. Directional, with an explicit confidence level.

SignalAssessment
MaintenanceActive
DocumentationStrong
License clarityClear
Deployment complexityModerate
DEV.co fitGood
Assessment confidenceHigh
Security considerations

Landlock is a kernel-native LSM providing defense-in-depth as a stackable security module. It enforces file access (read/write/execute) and TCP restrictions at the kernel level, not subject to userspace bypass. Security posture depends on correct policy definition—overly permissive allowlists reduce effectiveness. No public audit or CVE history provided. Gradual kernel rollout (Landlock ABI v5 in 6.7) means policy compatibility must be tested per kernel version. No runtime intrusion detection; monitor filesystem/network activity externally.

Alternatives to consider

Firejail

Older, more mature sandbox with broader isolation (PID/network namespaces, seccomp). Heavier footprint, requires more configuration. Landrun is lighter and kernel-native but less isolation.

systemd sandboxing (PrivateTmp, RestrictFilesystem, etc.)

Native systemd integration, no extra tool needed. Fine-grained control is more limited and fragmented; Landlock offers a unified, explicit policy language.

Docker/container runtimes

Full process, namespace, and resource isolation; production-grade with wide adoption. Overkill for single-process sandboxing; heavier and more complex than Landrun.

Software development agency

Build on landrun with DEV.co software developers

Landrun offers a fast, lightweight path to sandboxing untrusted tools and services. Evaluate it in dev/test, define policies carefully, and validate on your target kernel versions before production.

Talk to DEV.co

Related open-source tools

Surfaced by semantic similarity across the DEV.co open-source index.

Related on DEV.co

Explore the category and the services that help you build with it.

landrun FAQ

Do I need root to run landrun?
No. Landlock allows unprivileged processes to sandbox themselves. You do not need root unless your policy requires accessing privileged directories or binding to ports < 1024.
What if my kernel doesn't support Landlock?
Landlock is available in kernel 5.13+. If absent or older, use --best-effort flag to gracefully degrade (remove unsupported restrictions) or switch to an alternative sandbox. Network restrictions require 6.7+.
How do I debug 'permission denied' errors?
Use --log-level debug to see Landlock denials, or run with strace -f -e trace=all to observe syscalls. Ensure all required libraries and binaries are in --rox paths and config files in --ro paths.
Can I sandbox multiple processes or daemons with Landrun?
Landrun sandboxes a single command invocation. For multiple services, define separate landrun policies in separate systemd service files or wrapper scripts.

Software development & web development with DEV.co

From first prototype to production, DEV.co delivers software development services around tools like landrun. Our software development agency staffs experienced software developers and web developers for custom software development, web development, integrations, and ongoing support across open-source security and beyond.

Ready to harden your processes?

Landrun offers a fast, lightweight path to sandboxing untrusted tools and services. Evaluate it in dev/test, define policies carefully, and validate on your target kernel versions before production.