Plugin isolation is the feature that turns a risky plugin from an incident into a non-event. deepseek-harness ships the landlock-run native sandbox, which brings Linux Landlock to the dsh runtime. This post explains how Landlock sandboxing works, what the dsh plugin isolation model actually covers, and why it changes the security math for installers.
What Landlock Gives You
Landlock is an unprivileged Linux security module: a process can restrict its own filesystem access with fine-grained rules, no root required. landlock-run wraps the dsh runtime so every plugin runs inside a rule set defined by its bundle manifest — read-only on system paths, write access only to its own data directory, no touching of home or ssh keys.
What the Isolation Model Covers
- Filesystem: scoped read/write, with an explicit allowlist for the plugin data dir.
- Network: landlock-run setups can pair with network namespaces to block or allow outbound traffic.
- Execution: child processes inherit the restricted ruleset instead of escaping it.
What It Does Not Cover
Landlock is filesystem-first. It does not magically contain memory-safety bugs, and it relies on the kernel version supporting the feature (Linux 5.13+). On platforms without Landlock, the runtime degrades to advisory isolation — which is exactly when you should trust the quality score and install-script scan even more.
The New Security Math for Installers
With sandboxing, a dangerous install script becomes containable rather than catastrophic. But containment is a safety net, not a license to install anything. The recommended posture: let the scanner veto obvious risk, let Landlock contain the rest, and still review anything you plan to run with privileges. Sandboxes make mistakes survivable; they do not make them safe.