Skip to content

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

Description

@arunbuduri

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.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    state:acceptedA maintainer decided OpenShell should pursue this issue

    Type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions