From 1ba53fe0bb009a3caae6673766a5f3564b0ad025 Mon Sep 17 00:00:00 2001 From: Claude Date: Thu, 14 May 2026 18:19:02 +0000 Subject: [PATCH] Scope vsock exec channel to AI Sandbox VMs only MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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. --- SecVF/AppDelegate.swift | 32 ++++++++++++++++---------------- 1 file changed, 16 insertions(+), 16 deletions(-) diff --git a/SecVF/AppDelegate.swift b/SecVF/AppDelegate.swift index f75a5b9..d2eda4c 100644 --- a/SecVF/AppDelegate.swift +++ b/SecVF/AppDelegate.swift @@ -1163,15 +1163,14 @@ class AppDelegate: NSObject, NSApplicationDelegate, VZVirtualMachineDelegate, NS virtualMachineConfiguration.consoleDevices = [createSpiceAgentConsoleDeviceConfiguration()] } - // Add a virtio socket device (vsock) only for macOS guests — that's - // where the AI sandbox exec agent listens on port 2222. Linux VMs in - // SecVF (kali router etc.) don't currently use vsock, and adding the - // device unconditionally caused VM-startup hangs in testing. Limit to - // macOS for now; revisit if a Linux-side use case appears. - if isMacOS { - virtualMachineConfiguration.socketDevices = [VZVirtioSocketDeviceConfiguration()] - NSLog("[VM] Added virtio socket device (vsock) for host-guest IPC") - } + // No vsock device on the generic VM startup path. The AI sandbox builds + // its config via AISandboxMacVMConfiguration and attaches its own vsock + // device there; this path only runs for non-AI-sandbox VMs (regular + // macOS guests, Linux samples, Kali router), none of which have a + // legitimate use for the host-guest exec channel. Attaching it here + // unconditionally for any macOS guest opened a latent control-channel + // surface on hypothetical macOS malware-analysis VMs — see the purple + // team proposal in anthropic-detections-platform for context. NSLog("[VM] Validating virtual machine configuration...") do { @@ -1262,13 +1261,14 @@ class AppDelegate: NSObject, NSApplicationDelegate, VZVirtualMachineDelegate, NS // SECURITY: Start security monitoring for this VM VMSecurityMonitor.shared.startMonitoring(vm: vmConfig, virtualMachine: virtualMachine) - // Expose the AI Sandbox vsock exec channel as a UDS at - // /tmp/secvf-exec-.sock so cross-process / cross-user - // clients (e.g. ai-mon's SecVFTracer, secvf-cli vm exec) can - // drive the guest. No-op for VMs without a vsock device. - VsockExecBridgeManager.shared.startBridge( - vmId: vmConfig.id, vmName: vmConfig.name, vm: virtualMachine - ) + // Intentionally no VsockExecBridgeManager.startBridge() here. AI + // Sandbox VMs do not flow through this generic createVirtualMachine + // path — they boot via the AISandboxMacVMConfiguration code path, + // which calls startBridge at its own session-boot site. Starting + // the bridge here would either be a no-op (no vsock device on this + // path, post-hardening) or, if a vsock device ever re-appeared, + // would expose a host-guest control channel on a non-AI-sandbox + // VM. Keep the attach surface confined to the AI Sandbox path. let needsInstall = self.needsInstallFlags[vmId] ?? false