bug(vm-driver): packaged macOS ARM64 runtime lacks usable Landlock ABI
Nobody has claimed this yet.
- Dominant language
- Rust
- Stars
- 8.7k
- Forks
- 1.3k
- Avg merge
- 2d 11h
- Merged PRs (30d)
- 253
Description
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_requirementand 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, andCONFIG_LSMcontainslandlock. - Runtime provenance records the effective kernel version, libkrunfw commit, and final kernel-config hash.
Reproduction Steps
-
Install OpenShell v0.0.116 on Apple Silicon and start a VM-driver gateway.
-
Create a diagnostic sandbox and confirm the guest reports Linux 6.12.76 aarch64.
-
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. -
Create a sandbox with
landlock.compatibility: hard_requirementand only paths confirmed to exist in the guest. -
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.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start at VM-runtime build source commit 56088d0811f35d01e5af8f975335c9d0e30524be, inspecting the pinned libkrunfw base config, kernel fragment, and build verification loop described in the report. Run the Apple Silicon diagnostic and hard_requirement smoke tests, including declared and undeclared path access. Done means ABI version 1 or higher, successful Ready provisioning, enforced access, required config validation, and provenance for the kernel, libkrunfw commit, and config hash.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- linux, macos
- Domain
- build-system, infrastructure, operating-systems, security
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100