I hope, if you have upgraded to Mojave, that all went well and you’re now happy that you made the right decision. Looking around, there seem to be remarkably few problems or regrets. That’s not to say that Mojave has been an instant success, but it doesn’t seem to be the lemon that some had feared.

Apart from a few model-specific problems, such as the strange dislike for the iMac 27-inch Late 2012, 3 TB hard disk with a Boot Camp partition, and ongoing issues with some MacBook Pro 2018s, most who have upgraded seem not to have hit problems, and the support forums are quite quiet.

The biggest issues are centred on Mojave’s new privacy management, TCC, which most of us expected. TCC has actually been around in the background of macOS for quite a few years now, but has been keeping a low profile.

The last time that it was in the news was when DropBox abused Accessibility features two years ago. Since then, it has largely been the concern of those distributing their apps through the App Store. That should have kept TCC away from the limelight, until early September when Trend Micro was caught exfiltrating private data from its App Store apps.

Glance at the headlines, and you’d think that the three vulnerabilities reported so far in TCC rendered it pretty well dead on arrival, and a serious blow to Mojave as a whole. However, at this stage of the cycle, I’m not sure that this is a particularly serious problem, at least not for users.

One of the ‘vulnerabilities’, in which someone can ssh in and then has free access to private data, is surely not accidental. There are several issues involved here, but fundamentally the problem is one of the virtues of ssh: its power. If your Mac has Remote Login enabled and is thereby vulnerable to attack, the privacy of your data is a secondary concern, as it’s a disaster waiting to happen.

On the other hand, trying to impose privacy restrictions on remote connections via ssh is neither a particularly tractable problem, nor one in which any apparent solution would be acceptable. For command tools, TCC uses an Attribution Chain, which tracks privacy permissions upwards in the hope of reaching a caller which can interact with the user. For local commands executed in Terminal, it is Terminal’s ability to fire off a consent dialog which you will notice.

When a system administrator tries to connect to an unresponsive Mac using ssh over a local network, that Attribution Chain lacks a head. The sysadmin might be connecting over VPN from a Linux laptop on a beach in the Bahamas, and for TCC to start asking them for consent would be a real nightmare.

The biggest problem with ssh is not its ability to bypass privacy protection, but the fact that no Mac which has Remote Login enabled has given any warning during Mojave’s configuration that that allows a remote user to bypass TCC’s privacy protection. It is surely enabling Remote Login which needs one of TCC’s dialogs, with a very explicit warning as to what this can do. In response to comment, I discuss these issues further in the Appendix below.

The other two vulnerabilities, announced by Patrick Wardle and Jeff Johnson, shouldn’t be too surprising. Both are real macOS wizards, and I’d be a little disappointed if neither could find a way around TCC at this stage. Given that TCC didn’t reach any sort of maturity until quite late during beta-testing, in August when many developers were on holiday, means that Apple’s ferocious product development cycle hasn’t really allowed much testing by third parties as yet.

What is much more important at this stage is how well Apple responds, and whether these prove to be mere bugs, or more deeply embedded in TCC’s architecture. We should find that out over the coming weeks.

Even then, more persistent issues in TCC’s robustness may not be as important as they might seem now. This is because Mojave’s privacy protection is only a small part of a much bigger change which is happening in macOS. Another important component is ‘Notarization’, which in Mojave is voluntary, but intended at some time in the future to become a requirement of third-party apps which are not delivered by the App Store.

Imagine for a moment if, in macOS 10.15 next autumn/fall, there were four classes of apps and executable code:

1. Apple’s apps, signed by an Apple certificate and using Apple’s private entitlements and privacy rules;
2. App Store apps, sandboxed and only able to step outside when they have appropriate ‘entitlements’;
3. Notarized apps, ‘hardened’ with their own entitlements which are more liberal than those of the App Store, but well-enforced;
4. Other apps, deemed high risk and only able to be run when the user accepts full responsibility.

Default settings would limit the great majority of users to classes 1-3, and only the most adventurous would elect to enable class 4.

We have seen that it is possible to sneak deceptive apps, perhaps even the occasional item of malware, through class 2, and I’m sure that someone will try with class 3. But, as should have been the case of Trend Micro, deliberately circumventing the rules and protections would prove instantly fatal once detected. If Apple’s screening of class 2 and 3 apps is thorough enough, it could make it practically impossible to get a deceptive app approved either for the Store or for notarization.

This would also reduce any reliance on the detection or removal of conventional malware, making XProtect and MRT almost vestigial.

Apple needs to get TCC and its protection right. Given its relative immaturity, it has actually got off to a good start, as has Mojave. As others have pointed out, even if the new privacy protection is quite limited, it can only be an improvement on High Sierra, and at least APFS is finally of release quality.

Appendix: Remote Login and TCC

Currently, almost all Macs which are running Mojave have been upgraded from an earlier version of macOS which doesn’t enjoy the same privacy protection as that in Mojave. Some/many of those who have upgraded are probably unaware that they have Remote Login enabled, and that that in turn allows someone who connects to that Mac using ssh to access data which they would reasonably presume should now be protected.

It would not be difficult for Apple to incorporate a valuable step in the initial configuration of the upgraded system in which Remote Login status is assessed. If it is enabled, then the user should be advised of the fact that this would enable a remote user to bypass their privacy protection, and to offer as a default to disable Remote Login. I believe that many of those who currently have Remote Login enabled would choose then to follow that default and to disable it.

I do not know whether Apple’s default setup for new Mojave installations is to enable or disable Remote Login. Experience tells me that this isn’t always consistent: it is only a couple of years ago that batches of new MacBook Pros were delivered with SIP disabled by default! However, I believe that all new Macs should by default be configured with Remote Login disabled.

Regardless of whether Mojave was installed as an upgrade or as the initial version of macOS on a Mac, enabling Remote Login necessarily changes privacy protection on that Mac. Therefore, whenever a user enables Remote Login, they should be alerted by a dialog informing them that this will enable a remote user to bypass all the privacy protection on that Mac.

I should have guessed that trying to wrap these issues up in just two sentences was probably a bit optimistic, and my original statement misleading.

I accept that the original claim that I made in this article that “The biggest problem with ssh is not its ability to bypass privacy protection, but the fact that by default Remote Login is enabled in most, if not all, macOS installations” is not accurate, for which I apologise. Remote Login is though enabled on a great many Macs, but no user has been alerted during the Mojave setup or upgrade process that that allows a remote user to bypass their privacy protection by connecting using ssh. That needs to change.