magus v0.3.0 is out. See what's new
¶ View markdown source · ✎ Suggest an edit
1 min read

MGS2005: kernel landlock unavailable; interpreter-level only

The sandbox is enabled but the host kernel does not support landlock LSM. Magus continues with interpreter-level enforcement only.

[MGS2005] kernel landlock unavailable; sandbox running with interpreter-level checks only
  reason=sandbox: kernel sandbox unsupported on this host: ...

Why

The sandbox normally enforces filesystem confinement through two layers:

  1. Kernel layer: Linux landlock LSM applies the policy via landlock_restrict_self, after which every child process inherits the restriction across fork+exec.
  2. Interpreter layer: the Buzz fs.*, sh.*, env.* bindings consult the policy in user space before performing any operation.

When the kernel does not have landlock (macOS, Windows, or Linux older than 5.13 without the LSM compiled in), only layer 2 runs. The warning is emitted once per process so operators know that kernel-level enforcement is absent.

What still works

  • Buzz spells calling fs.*, sh.*, env.* bindings are still blocked when they target out-of-workspace paths or secret env vars. This covers every spell magus ships and every magusfile written against the documented API.
  • Env scrubbing still applies (it runs in pure Go).

What does not work

  • A spell that bypasses the binding layer cannot be confined by user-space checks alone. No such spells exist today; the spell API routes everything through the bindings. If a future spell type embeds native code (Go plugins, WASM with wasi-fs, embedded C via cgo) it must require landlock or be rejected up front.

Resolution

  • Upgrade to Linux 5.13 or newer and ensure landlock is compiled in (check /sys/kernel/security/landlock).
  • On macOS or Windows, accept the warning. Filesystem-only attacks through documented bindings are still blocked; native-code attacks are not possible today.
  • Set MAGUS_SANDBOX_ENABLED=0 if you do not want the warning on platforms where you accept the reduced enforcement.
sandbox diagnosticsLanding page for the sandbox that confines magus spells to the workspace, plus its MGS2xxx diagnostics for denied reads, writes, execs, and env leaks. magus stdlibReference for every magus stdlib module - fs, os, http, json, yaml, crypto, and the rest of the magusfile API surface. Sandbox modelThe threat model and allowlist semantics that magus enforces around spell execution, and how the MGS2xxx diagnostics map onto that model. magus DocumentationThe magus documentation hub covering install, targets, spells, charms, operations, engines, remote caching, MCP, telemetry, and the interactive playground.
MGS2005sandboxlandlockkernelmacOSLinuxinterpreterenforcement
Last updated (b022d75e)
Glossary

Workspace

The magus root directory that owns a set of projects and shared config; the unit magus operates over. See workspace.

Magusfile

The magusfile.buzz that declares a project's targets (as export funs) and binds its spells. See targets.

Target

A named operation (build, test, ...) you invoke with magus run <target>; it may compose a spell's tool-native operations and depend on other targets. See targets.

Operation

A single tool-native command a target composes; the middle of the work hierarchy (Spell to Operation to Target). See operations.

Spell

A language/runtime adapter (e.g. go, md) that maps generic targets onto a toolchain's real commands. See spells.

Buzz

The language magusfiles are written in (the .buzz engine). See engines.

Sandbox

The restricted filesystem and environment a target runs in, so builds stay reproducible and side-effect-free. See sandbox.

Conventions

This page uses none of the site's convention markers. The full set is on the conventions page.