Securing virtual machines on Apple silicon

Using a virtual machine (VM) might seem an ideal platform for private computing. With all its data locked away in a VM that can’t otherwise be accessed from your Mac, it’s thoroughly safe from Spotlight indexing, access to old versions of documents, QuickLook previews, and everything else on your Mac’s Data volume that could give unintended access to its contents. But how secure could you make it? Prior to Sequoia, only as secure as the volume it’s stored on, it seems, which doesn’t make it so private after all.

In addition to Sequoia VMs on Apple silicon Macs being able to use services such as iCloud using Apple ID, they now appear able to support full-strength FileVault when Apple ID is activated. This contrasts with FileVault supported by previous macOS guests, which appears comparable to that provided by Intel Macs without T2 chips, or on external disks of any Mac, in that the Secure Enclave isn’t involved in protecting their encryption keys, as explained in Apple’s Platform Security Guide. Thus an attacker who has access to an older VM could copy that and attempt to gain access by brute force.

Apple hasn’t explained what is required for Sequoia VMs to support Apple ID, but it involves configuring “an identity for the VM that it derives from security information in the host’s Secure Enclave”. Support requires changes in macOS, both in the host and the guest, as its use requires the combination of Sequoia developer beta 3 or later running on both. It’s also significant that it can’t be used on VMs that have been upgraded from earlier versions of macOS, although thankfully it doesn’t require that of the host. This appears to be because Apple ID support requires structural change in the VM that can’t be achieved by a macOS updated inside it, and can only be performed when creating a new VM from scratch.

The best that a VM has been able to offer before Sequoia is relative privacy, but little more protection than already available on the host’s internal SSD. That assumes you store your VMs on the internal Data volume, which isn’t good practice in terms of snapshots and backups, as those will be significantly larger as a result. Storing VMs externally benefits from encrypted APFS, but that’s not as robust as full-strength FileVault.

If you want to set up a private VM using lightweight virtualisation on Apple silicon:

Upgrade the host to macOS Sequoia.
Build a new VM using macOS Sequoia.
Create the VM on the host’s Data volume on its internal SSD, with FileVault enabled.
Add that item to Time Machine’s list of exclusions from backups, only backing it up when necessary to an encrypted APFS volume. Bear in mind, though, that the VM will still appear in local snapshots.
During VM configuration, sign in with your Apple ID and enable FileVault for the VM.
For the VM’s primary admin account, use a different name and a different and robust password.
In the VM, disable all unnecessary iCloud and iCloud Drive access, and don’t enable network file sharing.

Remember that access to shared folders is only available from inside the VM. It’s currently not possible for the host or processes running on the host to access the contents of the VM unless enabled by network file sharing or through iCloud.