Scope vsock exec channel to AI Sandbox VMs only#21
Merged
Conversation
Two changes in createVirtualMachine() (the generic non-AI-sandbox VM startup path): 1. Stop attaching a VZVirtioSocketDeviceConfiguration for every macOS guest. The original 'if isMacOS' attach predates the AI sandbox getting its own dedicated config path (AISandboxMacVMConfiguration), which already attaches its own vsock device. Leaving the generic attach in place exposed a host-guest exec channel on every regular macOS VM — fine for AI sandbox VMs (they go through the dedicated path), but a latent control-channel surface on any non-AI-sandbox macOS VM, including a hypothetical macOS malware-analysis VM. The vsock port (2222) is documented in the open-source code, so an adversary inside such a VM with a cooperating host-side process could exploit it; remove the device so there is no port to bind. 2. Stop calling VsockExecBridgeManager.startBridge() from the generic path. The bridge has its own no-op guard for VMs without a vsock device, so this was already inert after change 1, but the explicit call kept the wiring 'one config change away' from re-exposing the channel. AI Sandbox VMs already call startBridge from their own session-boot site (the bootAISandboxSession() path), so nothing legitimate loses access. VirtioFS shares were already AI-sandbox-only (only AISandboxMacVMConfiguration adds directorySharingDevices), so this change closes the remaining cross-boundary surface on non-AI-sandbox VMs. Context: purple team proposal in anthropic-detections-platform/proposals/purple-team-agent-sandbox.md.
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
2 participants
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.
Summary
Scopes the host-guest vsock exec channel to AI Sandbox VMs only, by removing two unconditional attachments from
createVirtualMachine()(the generic non-AI-sandbox VM startup path) inAppDelegate.swift:VZVirtioSocketDeviceConfigurationattach. Theif isMacOS { socketDevices = [...] }block predated the AI Sandbox getting its own dedicated config path (AISandboxMacVMConfiguration, which already attaches its own vsock device). Without this change, every regular macOS guest carried a vsock device on port 2222 — fine for an AI Sandbox VM, but a latent control-channel surface on any non-AI-sandbox macOS VM, including hypothetical macOS malware-analysis VMs. The port number is documented in open-source code, so the surface is reachable by an adversary inside such a VM cooperating with a host-side process. With no device, there is no port to bind.VsockExecBridgeManager.startBridge()call. Already inert after change (1) because the bridge guards onvm.socketDevices.first is VZVirtioSocketDevice, but the explicit call kept the wiring "one config change away" from re-exposing the channel. AI Sandbox VMs still start their bridge from their own session-boot site (bootAISandboxSessionpath, ~AppDelegate.swift:2714), so nothing legitimate loses access.VirtioFS shares were already AI-Sandbox-only (
directorySharingDevicesis set in exactly one place:AISandboxMacVMConfiguration.swift). With this change, the cross-boundary surfaces that the purple-team proposal targets (VirtioFS workspace + vsock exec bridge) are both structurally confined to the AI Sandbox path.Context:
proposals/purple-team-agent-sandbox.mdinanthropic-detections-platform(purple-team writeup; "Adjacent hardening" section flags this fix).Test plan
xcodebuild -scheme SecVF -configuration Debug -destination 'platform=macOS,arch=arm64' build/tmp/secvf-exec-<UUID>.sockstill appears andsecvf-cli vm execstill drives the guest./tmp/secvf-exec-*.sockappears for this VM; confirm VM boots and operates normally.stopBridgecalls are still safe no-ops where no bridge exists.Generated by Claude Code