bug(vm-driver): packaged macOS ARM64 runtime lacks usable Landlock ABI

User Story

As an operator using the OpenShell VM driver on Apple Silicon,
I need landlock.compatibility: hard_requirement to be enforceable in the packaged guest,
so that VM-backed sandboxes can fail closed with mandatory filesystem isolation.

Problem Statement

OpenShell v0.0.116 successfully boots VM sandboxes on Apple Silicon, but the packaged guest kernel does not expose a usable Landlock ABI. A direct landlock_create_ruleset(..., LANDLOCK_CREATE_RULESET_VERSION) query returns ENOSYS. Sandbox creation with landlock.compatibility: hard_requirement fails with Landlock Filesystem Sandbox Unavailable, including when every listed filesystem-policy path is verified to exist.

The current rolling vm-runtime-darwin-aarch64.tar.zst is byte-for-byte identical to the artifact embedded in v0.0.116, so the rolling runtime reproduces the same behavior.

Impact / Why This Matters

Operators who require fail-closed filesystem containment cannot qualify or use the VM backend on Apple Silicon. The only OpenShell compatibility alternative is best_effort, which may continue without Landlock when the ABI is unavailable. Security-sensitive workloads must therefore remain on another backend or maintain a custom VM runtime. This blocks adoption of the stronger VM boundary for workloads that require mandatory filesystem enforcement.

Acceptance Criteria

• The packaged macOS ARM64 VM guest returns Landlock ABI version 1 or higher from the version query.
• A sandbox using landlock.compatibility: hard_requirement and known-existing paths reaches Ready.
• A runtime smoke test demonstrates that a declared path is accessible and an undeclared path is denied.
• The VM-runtime build fails unless the final kernel config has CONFIG_SECURITY=y, CONFIG_SECURITY_LANDLOCK=y, and CONFIG_LSM contains landlock.
• Runtime provenance records the effective kernel version, libkrunfw commit, and final kernel-config hash.

Reproduction Steps

1. Install OpenShell v0.0.116 on Apple Silicon and start a VM-driver gateway.

2. Create a diagnostic sandbox and confirm the guest reports Linux 6.12.76 aarch64.

3. Query the Landlock ABI in the guest:

   import ctypes, errno
   libc = ctypes.CDLL(None, use_errno=True)
   result = libc.syscall(444, None, 0, 1)
   error = ctypes.get_errno()
   print(result, error, errno.errorcode.get(error))
   

   Observed: -1 38 ENOSYS.

4. Create a sandbox with landlock.compatibility: hard_requirement and only paths confirmed to exist in the guest.

5. Observe provisioning fail with Landlock Filesystem Sandbox Unavailable.

Environment

• OpenShell: 0.0.116
• Host: Apple Silicon, macOS 26.3.1, arm64
• Driver: openshell-driver-vm 0.0.116
• Guest: Linux 6.12.76 aarch64
• VM runtime SHA-256: 04349e6395c60e8cda059cc74e24105fdd23cec49ceac84966ce7377396e757d
• VM runtime build source: 56088d0811f35d01e5af8f975335c9d0e30524be
• VM runtime GitHub run: 33026157021
• Pinned libkrunfw: 463f717bbdd916e1352a025b6fb2456e882b0b39

Logs

OCSF FINDING:CREATE [HIGH] "Landlock Filesystem Sandbox Unavailable" [type:landlock-unavailable confidence:high]
landlock_abi_result=-1 errno=38 errno_name=ENOSYS


Source inspection at the runtime build commit shows the pinned ARM64 libkrunfw base config has `# CONFIG_SECURITY is not set` and a `CONFIG_LSM` value without `landlock`. OpenShell's fragment requests `CONFIG_SECURITY_LANDLOCK=y` but does not enable `CONFIG_SECURITY` or add `landlock` to `CONFIG_LSM`. The build verification loop checks only `CONFIG_BRIDGE`, `CONFIG_NETFILTER`, and `CONFIG_NF_NAT`, so `olddefconfig` can discard the Landlock request without failing the build.

Related issue #2587 contains the same Landlock warning in VM logs but concerns an independent SSH relay disconnect.

Inizia dal commit del codice sorgente di build di VM-runtime 56088d0811f35d01e5af8f975335c9d0e30524be, esaminando la configurazione di base fissata di libkrunfw, il frammento del kernel e il ciclo di verifica della build descritto nel report. Esegui la diagnostica Apple Silicon e gli smoke test di hard_requirement, incluso l’accesso ai percorsi dichiarati e non dichiarati. È completato quando sono presenti una versione ABI pari o superiore a 1, un provisioning Ready riuscito, l’accesso applicato, la validazione della configurazione richiesta e la provenienza per il kernel, il commit di libkrunfw e l’hash della configurazione.