Last Week on My Mac: Where privacy protection fails

What I miss most in more recent versions of macOS are consistency and clarity. Clear concepts like permissions have become so heavily embroidered and encumbered that they’re barely recognisable. Although macOS by and large managed to avoid the intricacies of Access Control Lists (ACLs), it has more than made up for that with additional layers such as SIP and its Data Vaults, and most recently the privacy protection afforded by TCC.

If you write conventional GUI apps, you’ll undoubtedly be well aware of the strict constraints that TCC imposes. There are times when the most ordinary of actions, like saving a file to an extension of your Home folder on an external disk, seems to stir up a hornets’ nest of interventions, and in some cases the everyday and reasonable has become forbidden. My most bizarre example is writing a logarchive to an external disk, which TCC takes to be a heinous crime. But write that logarchive to the user’s Documents folder, and it can simply be dragged across to the external disk without any further interference.

We’re now unable to estimate the amount of disk space used by macOS versions, a feature I’ve had to remove from Revisionist, as they’re kept in a Data Vault at the root of each volume. Apps can discover how much space is taken by previous versions of any individual document, but if you want instead to know the total size of the database, you’re now out of luck.

Yet open Terminal and the command line seems cast in a different world. Provided that you’ve enabled Remote Login in the Sharing pane, you can use ssh to go places that the shell can’t, unless you’ve added Terminal to the Full Disk Access list in the Privacy tab of the Security & Privacy pane.

GUI apps aren’t allowed to quietly add themselves to any of the exception lists in the Privacy tab, yet when I use ssh it automatically adds two items, sshd and sshd-keygen-wrapper, to the Full Disk Access list, whether I want ssh to have that level of access or not. If I switch back to the GUI and disable sshd-keygen-wrapper in the Full Disk Access list, ssh loses its access to protected items, but if I exit the ssh connection and remove the sshd-keygen-wrapper item, I can ssh again and sshd-keygen-wrapper will be added back and enabled without any further user interaction.

If an unwanted app has been added to the lists in the Privacy pane, removing that app is likely to see it removed from those lists. If you install the app again, it will normally be awarded the same levels of access as it had before removal, without any involvement of the user.

The latest anomaly which I have run into is the mismatch between controls over ssh access. There are two ways of enabling Remote Login (ssh) services. In the Sharing pane, you can enable and disable it without so much as authenticating to the pane; when the service is active, a clear tick appears against that item which leaves you in no doubt that sshd is active.

You can instead use
sudo systemsetup -setremotelogin on
in Terminal, but as that requires elevated privileges you must authenticate for that to be granted. And if you haven’t added the Terminal app to the Full Disk Access list even that will fail. That is a ‘fix’ which Apple introduced to try (unsuccessfully) to address a vulnerability in which ssh can be used to mount an APFS snapshot and gain read-only access to any file therein, first reported by Csaba Fitzl.

In case you thought those two methods gave identical results, let me confuse you further. If you turn Remote Login on in Terminal, then the Sharing pane doesn’t tick its box, although selecting that item in its list does report on the right that the service is active.


None of this has been helped by the fact that the closest that we’ve got to documentation of TCC and its tools are mentions in a couple of man pages, for the essentially impotent tccutil and systemsetup, and the transcripts of a few presentations at WWDC. Concepts explained there, such as inferring user intent, don’t appear to fit well with commands, which could just as well be executed by an app, from a script, or typed in live in Terminal. For much of this, documentation isn’t a luxury afforded the user or developer, but a valuable tool for Apple’s engineers to see the shortcomings and anomalies which they have cast into code. Nothing gives better insight into your flaws than having to explain them fully to others.

Anomalies like these are rich pickings for malware, which laughs at the tight rules imposed in the GUI as it carves its way through restrictions using AppleScript and command tools. The contradictions and cracks between GUI and command tools have become fertile territory for those wanting to steal private data, which is surely exactly the opposite of what Apple intended.