bug(landlock): hard_requirement permits sandbox startup when Landlock ABI is unavailable

[makkavelle2015-bit]

Summary

A policy declaring:

landlock:
  compatibility: hard_requirement

starts a workload successfully on a host reporting Landlock ABI 0, and emits no Landlock log event at any point — no ruleset-built message, no skipped-path report, no warning, no abort.

Per the policy schema documentation, hard_requirement should abort startup when Landlock is unavailable or the filesystem policy cannot be enforced. best_effort is the mode documented as continuing without Landlock.

Observed behavior is consistent with any of:

1. hard_requirement is not enforced for this driver/backend;
2. the setting reaches the driver but is silently downgraded or ignored;
3. the schema documentation does not describe container-driver behavior accurately.

Environment

• OpenShell: v0.1.2 (published 2026-09-28)
• Driver/backend: docker compute driver, container backend with companion supervisor
• Host kernel: 6.18.33.1-microsoft-standard-WSL2
• Reported Landlock ABI: 0
• Policy mode: landlock.compatibility: hard_requirement

Filesystem policy as configured

version: 1
filesystem_policy:
  include_workdir: false
  read_only:
  - /etc/ssl
  - /lib
  - /lib64
  - /usr
  - /workspace
  read_write: []
landlock:
  compatibility: hard_requirement

Expected behavior

Sandbox startup fails before workload execution, with an actionable error indicating Landlock is unavailable or the configured paths could not be applied.

Actual behavior

The workload starts and runs. Two facts make this a contract question rather than a tuning question:

1. The policy block reaches the driver unmodified. The resolved spec fetched from the running sandbox shows:

"landlock": {
  "compatibility": "hard_requirement"
}

2. Landlock initialization is never logged. Searching the gateway log and the companion supervisor's container logs for landlock, ruleset, filesystem, isolat, and seccomp returns no Landlock entry. The supervisor log shows only policy fetch, isolation-boundary attachment, DNS confirmation, and policy-change acknowledgement. If the documented Landlock ruleset built event reporting applied and skipped paths is expected, it is absent — and its absence is silent, with no high-severity warning.

Isolation that was observed

These probes ran inside a live sandbox. They demonstrate real confinement, but they do not establish Landlock enforcement — the effective controls appear to be the container runtime and supervisor mediation:

Probe	Result
cat /etc/passwd	Permission denied
cat /etc/shadow	Permission denied
ls /	Permission denied
write under /tmp	Permission denied
TCP 1.1.1.1:443 (bash /dev/tcp)	refused, exit 1
TCP 8.8.8.8:53	refused, exit 1
TCP to gateway host	refused, exit 1
TCP to loopback	refused, exit 1
id	uid=1000 gid=1000

To be explicit: these are not evidence about Landlock. Landlock network-rule support arrived at ABI 4, and this host is ABI 0, so the network results belong entirely to the Docker/supervisor layer.

Test-validity disclosure

Two earlier probe sets were discarded and are not offered as evidence:

1. Assertions redirected to >/dev/null, but /dev/null could not be created in the workload. The redirect failed before each probe command ran, so the apparent denials came from the redirect, not from policy.
2. Network probes used nc, which is absent from the image. Exit code 127 meant command-not-found, not a blocked connection.

The /dev/tcp results above are the only valid network evidence.

Separate observation: declared paths do not exist

/etc/ssl and /workspace are declared read-only but are absent from the ubuntu:24.04 image (exit 2). This fails closed, so it is not a containment hole, but it raises a related question: under hard_requirement, are inaccessible declared paths supposed to be fatal? The documentation reference suggests individual inaccessible paths should abort startup, which would make this part of the same fail-closed issue rather than a separate one.

Request

1. Is hard_requirement intended to be enforced for the Docker/container driver?
2. Should ABI 0 cause startup failure, or a loud warning at minimum?
3. Which log event definitively reports Landlock ruleset creation, and should its absence be surfaced? Silent success here is the worst outcome — it removes the signal a user would rely on to know confinement is not active.
4. Under hard_requirement, are declared-but-inaccessible paths fatal?
5. Should the driver reject a policy that lands in a non-enforcing backend, rather than accepting it and reporting success?