Changes in macOS security since Mojave have been deep and extensive, but their impact on troubleshooting isn’t often appreciated. Most of us continue to use techniques and solutions that ignore those profound changes, only to become frustrated that they no longer work as they used to. This article briefly reviews the consequences of Secure Boot, the Sealed System Volume (SSV), code signing requirements on Apple silicon, and Gatekeeper checks in Ventura on how we tackle problems.

This also depends greatly on which type of Mac we are dealing with: plain Intel Macs (which I’ll refer to as Intel), Intel Macs with T2 chips (IT2), and Apple silicon Macs (AS) differ in their security features, which in turn determine how we should tackle their problems.

Secure Boot and the SSV

Since Big Sur, the great majority of macOS has effectively been locked away as if in ROM, and can’t be changed even by accident, except on Intel.

During Secure Boot on IT2 and AS, each stage of the boot process now verifies the integrity of the code for the next stage. The fact that a Mac can boot normally therefore guarantees that the kernel, firmware and software are exactly as intended. This is extended to the entire contents of the System volume by the SSV, using a tree of cryptographic hashes to verify them down to the last bit. Apple details this here for IT2, here for AS, and here for the SSV on both. There is no such thing as Secure Boot on Intel (without T2), though, and Apple doesn’t explain whether or how those older Macs verify the SSV.

Some of macOS is still stored outside the SSV, on the Data volume of all Macs running Big Sur and later, including most notably Safari and its supporting components. These are now protected within cryptexes, and as immutable as the contents of the SSV.

With the guaranteed integrity of the SSV and cryptexes on IT2 and AS models, reinstalling the same version of macOS has no effect on the great majority of macOS. Similarly, installing an older version and updating it to the current one can only produce exactly the same result as installing the current version directly.

Two procedures might be worth considering, though: replacing the latest version of macOS with an older one, in an attempt to clear new problems, and installing macOS and migrating to it from backups. Both of these can also make problems worse as they rely on migration, which could restore other components responsible for a problem, or those incompatible with the version of macOS being installed. Unless you have identified which items in the backup shouldn’t be installed in the new macOS, and exclude them from migration, neither procedure has much chance of solving a problem.

Intel Macs (without a T2) could be different, but there’s insufficient knowledge about how thoroughly they verify the integrity of the SSV to assess whether reinstalling macOS could be any more purposeful.

Code signing and Gatekeeper

All third-party software is installed on the Data volume, making it susceptible to accidental or deliberate change, just as it has been in the past. What has changed is that all Universal executable code is required to be signed, and signing and integrity are now checked whenever an app is opened, rather just when it’s first run. As a result of this change, I am removing the signature-checking code from all my apps, as that’s now superfluous.

Just as successfully booting macOS is verification of its integrity, so launching an app without a code signature error verifies the code within that app. That applies to all Macs running Ventura, where replacing a misbehaving app with a fresh copy is likely to be pointless. The most important exception to this is when the app crashes when it’s launched. Two significant causes for that are:

• The app is being run in translocation, because it hasn’t been moved from within the folder it was originally located in. The solution is then to move the app without its enclosing folder to a standard location such as the main Applications folder, and run it from there.
• The app has been updated or otherwise modified without it being signed correctly again. Downloading and installing a complete updated version of the app should solve that.

Login and Background Items

Many apps now rely on Login and Background Items to perform privileged tasks or provide services. Previously no accessible control has been provided over these, and third-party utilities have been required. Ventura’s new Login Items settings are an important improvement here, in listing LaunchAgents and LaunchDaemons previously only accessible through their installed property lists.

Apps developed for Ventura may opt to use its new architecture, in which those property lists remain inside the app’s bundle. Although this can make them harder to track down, because they’re protected by the app’s code signature, in the long run this should simplify troubleshooting: any change to those property lists will break the app’s signature, and prevent it from being opened.

Examining Login and Background Items settings are now an important step in diagnosing many otherwise elusive problems. This is explained in this article, which recommends obtaining a BTM dump using the command
sudo sfltool dumpbtm > ~/Documents/btmdump.text
to write it to the text file btmdump.text in your Documents folder.

Example: File sharing in Ventura

Many users have reported problems in recent versions of Ventura with network shares failing to mount. The most common attempted solution seems to be re-installing that version of macOS, typically 13.2 or 13.2.1. Some have even gone to the lengths of reformatting their Mac’s internal SSD, installing a fresh copy of macOS, and migrating from backups. So far, I haven’t heard of a single success using those approaches.

All evidence points to this problem being a bug or new feature in macOS. Currently the most likely reason for this occurring is that Ventura has become incompatible with custom icons for such shares, and those who have removed all custom icons are most likely to report success. If this does turn out to be the cause, it demonstrates how the traditional panacea of re-installing macOS is now so often ineffective.

Summary

• For Intel Macs with T2 chips and Apple silicon Macs, reinstalling macOS seldom solves problems. Intel Macs without T2 chips might still be amenable, though, because they don’t have Secure Boot and may perform more limited checks on the SSV.
• Anyone advocating reinstalling macOS as a solution should explain how that might solve the problem.
• Macs running Ventura now perform code signature checks whenever an app is launched. Successful launch thus confirms the integrity of that app.
• Login and Background Items settings in Ventura are an important tool in troubleshooting, and a BTM dump can be invaluable.
• Careful observation, panic or crash logs, Unified log extracts and analysis are more important than ever.
• Remove and re-install usually isn’t a successful strategy.