On Sunday I introduced some of the principles involved in the protection of folders, to preserve your privacy, and provided a small test app, Insent. This article follows on with additional concepts, details, and a new version of Insent that writes diagnostic information to the log. This article refers to privacy protection as implemented in macOS Tahoe 26.4.
The macOS privacy system is more formally known as Transparency, Consent and Control (TCC), and is built around its manager tccd, working alongside the security system and the sandbox service sandboxd. The last might surprise those who thought that sandboxing was only required for apps provided in the App Store, but this sandbox is different.
When an app makes certain types of request of the file system, including those seeking a list of files (e.g. with FileManager’s contentsOfDirectory() method), or opening a file for read access, that request is passed to sandboxd for approval. That in turn queries TCC to discover whether that app should be authorised for that access. Depending on the path to be accessed, TCC checks in its database of policy approvals, runs various safety checks on the app’s signature and other properties, then tells sandboxd whether the request should be approved or denied.
As I revealed in the previous article, TCC’s controls over folders only apply to reading their directory and file contents. If an app wants to write a file to one of those protected locations, privacy restrictions don’t apply, only conventional Posix permissions. This is easily verified using the Save buttons on the left side of Insent’s window, which can write test files wherever you as a user have sufficient privileges. This is an important distinction, and a consequence of TCC’s purposes.
Reading directory listings and file contents is also different when it’s a user intent. This is most characteristically performed using the File Open dialog, where only the user gets to see the lists of files, and has complete control over which file is opened. This is handled by a separate XPC process, the Open and Save Panel Service, which has automatic approval. The same mechanism applies to the Open Recent command, drag-and-drop, double-clicking the document, and using the Finder’s Open command.
The Open and Save Panel Service is also an example of another fundamental concept in macOS privacy protection, that of the attribution chain.
This is often encountered when considering how privacy protection can be applied to command tools that lack a GUI that could support TCC’s dialogs. Ultimately, each process has a GUI app responsible for it, and it’s that app which TCC uses as the front-end. In the case of most command tools that are run from Terminal, the attribution chain ends in Terminal.
If you want your command tools to have Full Disk Access, you thus add the Terminal app to the list in Privacy & Security settings. The disadvantage of this design is that it gives Full Disk Access to all command tools run in Terminal’s shell, and could get you into trouble if one turns out to be flawed or malicious. This can be exploited by ClickFix attackers, which trick you into pasting malicious commands into Terminal, and is a good reason for not leaving Terminal with Full Disk Access any longer than is necessary.
Daemons or services, whose name normally ends in d, are seldom run from Terminal, and when they require Full Disk Access can be added as individual binaries, although they can’t normally be given access to individual Files & Folders.
I’ve been unable to discover a comprehensive and up-to-date official list of protected folders and locations, but the following appear to be those most frequently used:
The first three are by far the most common in most Macs, with Removable Volumes close behind. Others are more dependent on your hardware configuration, for example whether you use network shares or third-party cloud services.
The overriding principle in privacy protection is to minimise access given to potentially sensitive files.
Apps that are intended to access files anywhere or everywhere, such as backup apps and those used to detect duplicate files, should normally be given Full Disk Access, as should be advised in their documentation. That requires you to put trust in them not to abuse their privilege, and in their supplier to ensure they aren’t the victim of a supply-chain attack. If you have any doubts whatsoever, don’t install that app, and certainly don’t give it Full Disk Access.
Other apps should only be given access to Files & Folders when you’re invited to give your consent in one of TCC’s dialogs, and then only if you consider the app has a sufficiently good reason to be given that access, and can be trusted not to abuse it. All this should be explained in the app’s documentation, and better apps cover it in their onboarding sequence.
The Files & Folders list is different from Full Disk Access. You pick and choose which apps to give Full Disk Access to, and can leave an app listed there but with access disabled, to ensure it will remain blocked. TCC decides which apps are offered for inclusion in the Files & Folders list on the strength of their making a request of the file system that triggers sandboxd to ask TCC if it has been approved for such access. You can’t add apps of your choice, but you can disable an access that has already been granted, and remove that app from the list.
In the next article I’ll show what happens in the log when sandboxd and TCC are in action. This has been made much easier in a new version of Insent which writes detailed entries in the log. If you want to study those, Insent 1.1 is now available from here: insent11
For those who don’t want to dive that deep, version 1.0 is the same in all other respects, and is available from here: insent10
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。