The signed system volume under macOS Big Sur

The last two major macOS versions have brought about a rapid development in the protection of system files. I would like to briefly discuss this development in this blog:

• In macOS Mojave 10.14, macOS boots from a single APFS volume where sensitive system folders and files are intermingled with those that users can write to. The main protection mechanisms provided to the system come from classic Unix permissions and additionally the macOS mechanism System Integrity Protection (SIP), a software within macOS. In macOS Mojave, malware therefore only needs to exploit a vulnerability in SIP, gain elevated privileges and can then (maliciously) modify system files.
• macOS Catalina 10.15 changes this by splitting the boot volume into two: the system volume and the data volume, which together form an APFS volume group. Immutable system files are now located on the system volume, which is not only fully protected by SIP, but is also normally mounted read-only. This makes it far more difficult for malware, as it must not only overcome SIP, but also mount the system volume as writable before it can manipulate system files.

How Big Sur protects system files

Although Big Sur uses the same protected system volume and APFS volume group as Catalina, it changes the way the system volume is protected to make it an even bigger challenge for those developing malicious software: The Signed System Volume (SSV).

Every file on Big Sur’s signed system volume now has a cryptographic SHA-256 hash stored in the file system metadata. When a file is read from the SSV, its current hash is compared to the stored hash to ensure that the file has not been tampered with or corrupted.

In addition, each node of the tree recursively verifies the integrity of the hashes of its children, similar to a Merkle tree. The hash value of the root node - called the seal - therefore includes every byte of data in the SSV.

This ensures that these hashes cover the entire disk, its data and the directory structure. The seal is verified every time the Mac is started by the bootloader, as well as before loading the kernel and during the installation and update of macOS system files. If the verification fails, the startup is halted and the user is prompted to reinstall the operating system before continuing.

Hands-On: How to protect your system files with Big Sur

The command diskutil apfs list can be used to display the status of the APFS volumes in the terminal. This is what it looks like for the system volume:

In order to understand why the seal is broken here, it is necessary to understand how Big Sur creates the sealed system volume in the first place.

During the system installation, the entire system is created on the system volume. As soon as the installation is complete and protected by SIP, the installation program then creates the Merkle Tree up to the seal and takes a snapshot.

It is therefore not the system volume that is now sealed, but this snapshot. The system volume itself is “not mounted” and therefore no sealing is necessary here. The sealed snapshot is mounted, sealed and cannot be modified.