Is the Landlock ABI v3 floor deliberate, or the first complete read-only guarantee? (ABI v2 + seccomp truncate denial)

[scttfrdmn]

Question

Is the Landlock ABI v3 floor (REQUIRED_ABI = 3, Linux 6.2+, crates/openshell-sandbox/src/sandbox/linux/landlock.rs:72 at 3a5dfcd) a deliberate minimum, or is it the first ABI that gives a complete read-only guarantee?

Why I ask

The source comments say the floor exists for pathname truncation: "self-protection must cover pathname truncation as well as opens. Never silently downgrade this ABI requirement" (:143), and the read-only policy "must also deny pathname truncation" (:300). ABI v3 adds LANDLOCK_ACCESS_FS_TRUNCATE. Nothing else in the sandbox appears to depend on v3 or later: no network rules (v4), no ioctl rights (v5), no scopes (v6).

On ABI v2, the read-only gap is specifically truncate(2) by path:

• open(…, O_TRUNC) for writing already needs LANDLOCK_ACCESS_FS_WRITE_FILE, which a read-only rule withholds.
• ftruncate(2) needs a writable fd, which can only come from an open that WRITE_FILE governs.

The sandbox already installs seccomp filters for the workload. Denying truncate (path-based) there would close that gap on v2.

Who this affects

Hosts running Linux 6.1 LTS with Landlock enabled at ABI v2, which is long-supported and common. For example, Debian 12 (bookworm) kernels ship with landlock first in CONFIG_LSM. Today the Docker and Podman drivers can't run sandboxes on those hosts.

Sketch, if the floor isn't deliberate

An explicit, operator-opted mode, never automatic, preserving "never silently downgrade":

openshell-sandbox … --landlock-abi-floor 2     # or a gateway/driver setting

In that mode:

• the baseline and read-only rulesets are built with ABI::V2 and CompatLevel::HardRequirement;
• the workload's seccomp filter returns EACCES for truncate (and truncate64 where it exists), applied to the whole workload. Path-based truncation of read-write paths is lost too, a documented functional cost. ftruncate on writable fds is unaffected;
• an OCSF config event records "Landlock ABI v2 with seccomp truncate denial" so the weaker mechanism is visible in audit.

If the floor is deliberate (for example, to keep one enforcement mechanism per guarantee rather than splitting it across Landlock and seccomp), that's a fine answer. It would be useful to have it stated in the docs, so hosts on 6.1 know the requirement is principled and not incidental.