Before macOS Mojave came along, security strategy was layered. At the heart, System Integrity Protection (SIP) ensured that no attacker could nobble system files, and Gatekeeper checked that all downloaded and quarantined software was bona fide. In the event that some malware did slip past, XProtect would detect it, and hopefully MRT would clean things up afterwards.
When everything worked perfectly, that would have been fine, but there were inevitably vulnerabilities, and most important of all, developer signatures were used to give malware false credentials. Not only that, but once malware (or even badly behaved apps from the App Store) got running, it had access to all your most sensitive data, which was after all its purpose.
When signed malware has been detected, Apple has been fairly swift to revoke the developer’s certificate, but that is a blunt tool which could also prevent other perfectly innocent apps from running.
In Mojave, this strategy appears in transition. In the future, Apple intends relying on two methods which go far beyond anything possible with Gatekeeper and simple signatures. Apps will either be delivered through the App Store, following its review process, or they will be notarized. Notarization uses less stringent sandboxing than the App Store, which allows apps to do a great deal more, and Apple has introduced automated checks to determine whether code is possibly malicious.
Apple’s aim is to ensure that users can only install and run software which it has checked, either in the App Store review process, or during notarization.
Neither of those is necessarily perfect, though. In the event that something malicious does slip through, Apple now has finer controls which allow it to block one specific version of a specific app, rather than having to revoke the entire developer certificate.
XProtect and MRT have thus been put out to grass for the time being. XProtect does still perform basic malware checks, for example inspecting JPEG images before they are opened, to ensure that they aren’t malicious. In the event that the threat landscape changes, XProtect and MRT are still available if their defences are necessary. But if Apple’s strategy works, there should be little if any need for them.
We don’t know when Apple will make notarization the only alternative to delivery from the App Store, and to a degree, this depends on how developers respond to Mojave’s voluntary notarization. Although there have been some occasions when the notarization service has been very slow indeed, my experience of it is generally excellent. What’s more, it is completely free, provided that you pay Apple’s very modest annual developer subscription.
I’m making good progress in getting all my apps notarized now, and each time that they’re updated, notarizing those new versions. But only Apple has any idea of how this is going more generally. Given the number of 32-bit apps which were still being sold until quite recently, the bigger picture may not be as good.
Apple also still needs to come up with good solutions for command tools, which usually aren’t even signed, for open source software, and other cases which it might think are more marginal.
But any change in strategy will have greatest impact on those who can’t (or won’t) upgrade to the latest version of macOS. When Apple has introduced new security systems like SIP and Gatekeeper, it has never (as far as I can recall) provided them retrospectively for older versions of macOS for which it still provides security updates.
With Sierra and High Sierra unable to check whether apps have been correctly notarized, or react to revocation of notarization in the event of its abuse by malware, running an older but still supported version of macOS will be an exercise in vulnerability. At least, if Apple does introduce the requirement for notarization in macOS 10.15, those still using Mojave will have partial protection. But if you’re left with High Sierra, as many Macs will be, the prospects look bleak.
I’m hoping that Apple will break its silence, and engage in more open discussion with developers, sysadmins, and the user community as a whole. Apple’s understanding of the problems that we face is often worryingly limited, and its contacts most usually limited to transmission rather than reception and debate.