Validating the trust boundary of the self-hosted macOS CI runner

[sunxiaoguang]

Issue description

I would like to discuss whether the current CI configuration creates a real security risk. I may be missing repository-specific assumptions, so the goal is to validate the threat model before drawing firm conclusions.

In .github/workflows/main.yml, the runtime-macos job is currently eligible for pull_request events and runs on a persistent self-hosted macOS runner. It checks out the PR revision and executes:

• make
• make check
• bash tests/test-matrix.sh all
• fixture download and preparation scripts

These commands are partly defined by files from the PR itself, including the Makefile and test scripts. If a PR is allowed to run, this appears to give PR-controlled code shell execution with the permissions of the self-
hosted runner.

The GitHub token may be read-only, and fork PRs may not receive repository secrets, but those restrictions do not sandbox the runner’s filesystem, environment, installed tools, network access, or persistent home
directory.

There is also a fixture persistence concern. The runtime job saves externals/test-fixtures under:

$HOME/.cache/elfuse-ci/test-fixtures

The same directory is restored by later runs without being keyed by the PR, commit, or branch, and without validating the fixture contents. Since the fixture tree includes executable binaries, rootfs data, an initramfs,
and an SSH key, a PR may potentially influence what a later run executes.

The main questions I would like to clarify are:

1. Is the self-hosted macOS runner persistent and shared between PR and trusted branch runs?
2. Are PRs intentionally allowed to execute arbitrary repository-controlled shell commands on this runner?
3. Is the fixture cache intended to be trusted across PR and main runs?
4. Are the fixture binaries and initramfs considered trusted inputs, or are they treated as untrusted guest code?
5. Are there existing operational controls that make this threat model acceptable?

I have prepared a PR focused specifically on the CI trust boundary:

- restrict runtime-macos to pushes on main and explicitly dispatched workflows targeting main;
- prevent pull-request runs from restoring or saving the persistent fixture cache;
- keep fixture cache access limited to trusted main-branch events.

This PR does not change fixture validation, lockfile-based cache keying, or SSH-key persistence. Those are separate hardening concerns and are intentionally out of scope here.

I would appreciate feedback on whether the risk is accurately characterized, whether the proposed CI restrictions fit the project’s intended workflow, and whether there are any assumptions or trade-offs I have
overlooked.

[jserv]

I have prepared a PR focused specifically on the CI trust boundary:

• restrict runtime-macos to pushes on main and explicitly dispatched workflows targeting main;
• prevent pull-request runs from restoring or saving the persistent fixture cache;
• keep fixture cache access limited to trusted main-branch events.

This PR does not change fixture validation, lockfile-based cache keying, or SSH-key persistence. Those are separate hardening concerns and are intentionally out of scope here.

I would appreciate feedback on whether the risk is accurately characterized, whether the proposed CI restrictions fit the project’s intended workflow, and whether there are any assumptions or trade-offs I have
overlooked.

The self-hosted macOS CI runner is necessary because GitHub Actions' default macOS runners do not provide access to Apple's Hypervisor.framework. Since elfuse is an academic prototype exploring kernel-less Linux system call emulation, @Max042004 deployed an Apple M4-based machine as a self-hosted macOS CI runner at National Cheng Kung University (Taiwan).

At this stage, the security model has not yet been fully designed or hardened. I would greatly appreciate your feedback on validating the trust boundary of the self-hosted macOS CI runner, as well as any suggestions or proposed changes to improve its security.

I defer to @Max042004 for follow-ups.