firma-run: add macOS VZ guest launch contract#151
Draft
falcucci wants to merge 1 commit into
Draft
Conversation
cherry-picking the VZ guest work from #141 the split is useful to isolated the guest work development to match Apples Virtualization.framework boundaries https://developer.apple.com/documentation/virtualization here we specifically use FIRMA_RUN_VZ_GUEST to select the macOS vz mode. before launch, the backend validates the configured runner and guest artifacts, rejects missing or relative paths, checks that the runner is executable on Unix and only then emits a macos_vz_guest proof. the contract carries the execution envelope the runner must enforce: - sandbox id - runtime dir - runner path - guest image paths - command - args - cwd - environment - mounts - identity mode - seccomp artifact path - proxy URL - DNS stub address - attribution headers - required invariants: - sidecar-only egress - confined DNS - fail-closed startup/runtime - direct-bypass resistance - stdio/signal/exit preservation **since there is still no Apple Virtualization.framework runner here**, it servers us as a bedside contract for the future runner. routing also learns that macOS structural modes may need a host DNS refusal stub even when they are not using the Linux namespace path. the sandbox-exec uses that stub on loopback. the VZ guest contract exposes the same endpoint so the future runner can make guest DNS deterministic instead of letting the agent fall back to ambient resolution. *Note that the ESF remains out of this change.* Tested with: cargo test -p firma-run macos_vz
falcucci
force-pushed
the
push-rtwwzrzpxtyl
branch
from
5a0d253 to
a610b29
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
cherry-picking the VZ guest work from #141
the split is useful to isolated the guest work development to match Apples Virtualization.framework boundaries
https://developer.apple.com/documentation/virtualization
here we specifically use
FIRMA_RUN_VZ_GUESTto select the macOS vz mode.before launch, the backend validates the configured runner and guest artifacts, rejects missing or relative paths, checks that the runner is executable on Unix and only then emits a macos_vz_guest proof.
the contract carries the execution envelope the runner must enforce:
required invariants:
since there is still no Apple Virtualization.framework runner here, it serves us as a bedside contract for the future runner.
routing also learns that macOS structural modes may need a host DNS refusal stub even when they are not using the Linux namespace path. the sandbox-exec uses that stub on loopback. the VZ guest contract exposes the same endpoint so the future runner can make guest DNS deterministic instead of letting the agent fall back to ambient resolution.
Note that the ESF remains out of this patch.
Tested with: