Landrun: Sandbox any Linux process using Landlock, no root or containers

Original Article ↗ Hacker News Discussion ↗

A new Go-based tool called Landrun aims to make Linux’s Landlock security module practical for everyday use, letting unprivileged users sandbox individual processes with fine‑grained filesystem and TCP access controls—without containers, root, or SELinux/AppArmor configuration. Commenters compare it to existing sandboxing approaches like bubblewrap, firejail, namespaces, and OpenBSD’s pledge/unveil, highlighting trade‑offs in usability, flexibility, and security guarantees. While many welcome Landrun’s lightweight, auditable model and see potential for integration with systemd and OCI runtimes, they also note current limitations such as lack of resource control, partial network filtering, configuration ergonomics, and concerns over “best effort” defaults.

Comparison to existing sandbox tools (bubblewrap, firejail, nsjail, containers)

  • Landrun wraps Linux Landlock LSM, not namespaces; works unprivileged and doesn’t require containers, cgroups, or SELinux/AppArmor.
  • Several commenters say many Landrun use cases can be done with bubblewrap or firejail (mount/network namespaces), but note:
    • Namespaces may be disabled or require root on some systems, whereas Landlock is explicitly designed for unprivileged use.
    • Namespaces can expose a larger kernel attack surface; LSM-based controls are seen as safer for untrusted apps.
  • Firejail already integrates Landlock; nsjail relies on namespaces for FS isolation.
  • Landrun is viewed as closer in spirit to OpenBSD’s pledge/unveil than to full containers.

Landrun behavior, flags, and UX questions

  • Early confusion over --exec: users discovered many simple invocations failed without it; the author quickly refactored toward more granular --exec-path semantics.
  • Example from README initially failed (touch denied on /tmp), then was shown to need --exec and specific directory permissions.
  • Some argue “no rules” should mean “deny everything”; Landrun was updated to tighten this.
  • The default --best-effort mode (fall back to weaker sandbox) is widely criticized as unsafe; several suggest this should be opt‑in.
  • Option naming (--ro, --rw, --rox) is seen as confusing; some want clearer long/short flags.

Features, gaps, and kernel-level aspects

  • Today: fine-grained filesystem plus TCP port restrictions; UDP and more protocol controls are planned.
  • Landlock supports scoped abstract Unix sockets, but Go bindings currently struggle with them due to multithreading/signal issues; works from single‑threaded C.
  • Landlock is positioned as complementary to seccomp (attack surface reduction) and to namespaces (isolation); only LSMs can reliably block privileged child namespaces.

Configuration formats and ecosystem integration

  • Strong interest in declarative configs (JSON/TOML/YAML or reuse of existing policy formats). A separate landlockconfig project and OCI integration are in progress.
  • People want systemd integration akin to SystemCallFilter=, plus usage inside OCI containers as an extra layer.
  • Underlying Go/Rust/C libraries are MIT-licensed; Landrun’s GPLv2 CLI is acceptable to some, problematic to others.

Broader sandboxing / permissions discussion

  • Multiple commenters want macOS/Android‑style per‑app permissions and interactive prompts; Landlock could be a backend, but Landrun doesn’t provide that UX layer.
  • Alternatives mentioned for per‑app/network control: firejail, network namespaces + nftables, cgroups + firewall marks, Flatpak + xdg‑portals, and tools like OpenSnitch.