Linux: the engine behind Landlock

Landlock: deny-by-default in the kernel

On Linux the cage is Landlock, a kernel security module (LSM), again deny-by-default. It's not a wrapper in our code but a rule the kernel enforces. The engine may do exactly three things:

• read only the model file - nothing else on disk;
• execute only its own binary - it cannot launch other programs;
• bind to the one local port it answers on - and nothing more.

Outbound connections are refused by the kernel with 'permission denied' - before a single byte leaves the system. This isn't a promise in our code; the guarantee sits in the kernel, below anything the engine does. No writing to disk, no spawning of foreign processes, no network egress.

Static against musl, so 'only the model' holds

'Read only the model file' is only true if the engine genuinely needs nothing else from disk. That's why the Linux engine is built fully statically against musl, with no dynamic loader and no shared libc, on both architectures (amd64 and arm64). A normally linked binary would have to read and execute /lib64/ld-linux and the system libc at startup, forcing those paths into the allowlist; the static engine reads exactly one file and executes exactly one binary, itself.

What Landlock asks of your kernel

You need a kernel ≥ 5.13 with Landlock active. That covers Ubuntu ≥ 22.04, Debian ≥ 12 and RHEL ≥ 9.6 out of the box; on other distributions you enable it with the boot parameter lsm=landlock,…. Inside containers the default Docker seccomp profile blocks the Landlock syscalls - so you need an adjusted profile there.

Without Landlock: no on-device analysis

Where Landlock can't be enabled, there is no on-device analysis on that host. The engine simply doesn't start (fail-closed): a suspicious change is kept in place and surfaced rather than waved through unsandboxed.

How the same cage looks on macOS and Windows is in the engine sandbox overview.