Mojave’s new privacy protection is delivered by the Transparency Consent and Control (TCC) system, which is not new to macOS 10.14 by any means. Look back in Sierra’s logs and you’ll find a few of its messages there, but it has a much more limited role so there is little to see. It started to become more prominent in High Sierra, and is now one of the more chatty subsystems in the log. This article explores some of its basic behaviours in Mojave, illustrated with log extracts.

What’s what

TCC’s background service is tccd, whose only documented control is in tccutil, which merely clears existing settings from lists in the Privacy tab of the Security & Privacy pane. Its front end is that Privacy tab. In the unified log, TCC’s entries come from the subsystem com.apple.TCC.

There are three well-known folders which contain TCC’s data:

• /System/Library/Sandbox contains TCC_Compatibility.bundle, which contains an AllowApplications property list in the overall path /System/Library/Sandbox/TCC_Compatibility.bundle/Contents/Resources/AllowApplications.plist. This is a signed bundle, currently at version 14.0, and doesn’t appear to have been updated since the release of Mojave.
• /Library/Application Support/com.apple.TCC contains the system database TCC.db, and may contain two overrides property lists named MDMOverrides.plist and SiteOverrides.plist. Those property lists appear to be installed only when that Mac is being managed by MDM.
• ~/Library/Application Support/com.apple.TCC contains the user-specific database TCC.db. It doesn’t appear to be capable of containing user-specific overrides, though.

Startup

TCC doesn’t appear to start until over 5.5 seconds after startup in Mojave, and then normally in response to a synchronous request from WindowServer for Installer Progress. Its startup is summarised in the log entries shown below.

The first steps are to load overrides from MDMOverrides.plist and SiteOverrides.plist, if those files exist. On non-managed Macs, they shouldn’t, but AllowApplications.plist should, and will then be loaded. Its contents aren’t apparently added to the database in any persistent way, and this property list is loaded each time that Mac starts up.

AllowApplications.plist currently consists of an array of dictionaries under the key PostEvent, which is under the key Services. These are code requirement specifications for just over 30 apps, including different versions of Adobe Dreamweaver. It is not clear whether this is a whitelist or blacklist, though.

As each of those dictionaries is added, TCC writes an entry in the log as a PostEvent, and gives the code requirement from the property list.

Once all the overrides are loaded, TCC reports that its service is starting as com.apple.tccd.system with the root user ID. It then purges expired access entries from the database, and gets on with processing requests.

Overrides are first loaded around 5.5 seconds after startup, and are loaded again after a total of 17 seconds, about one second after the user has logged in. The first load thus applies to system usage, and the second for the logged-in user.

TCC activity

Many requests then follow to TCC. These show a similar pattern, which I will try to interpret. The example shown above is from the Login Window, and is an access request. The first log entry shows TCC putting a synchronous request to tccd. It is first displayed in its original form as a dictionary with five entries, then tccd repeats the request as received.

TCC converts from actual user IDs as given, to effective user IDs (euid), then builds details of the process making the request, in this case WindowServer. The next entry shows the Attribution Chain which TCC uses: although the request has come from WindowServer, which is given in the REQ field, it is actually loginwindow which is at the head of the chain to accept responsibility, given in the ACC field.

Subsequent entries step through TCC’s internal processes, and culminate in receiving a synchronous reply, which is again a dictionary, and gives authorisation with the boolean value of true.

Follow com.apple.TCC in the log and you will see hundreds, thousands of similar exchanges taking place. Because that was early after startup, it is perhaps less representative of the most common pattern, which is shown in the excerpt above. This contains:

1. The request to tccd in the form of a dictionary;
2. tccd handling that request;
3. Generation of euids;
4. Construction of details of the accessing process;
5. Construction of the Attribution Chain, giving the REQuesting process and in the ACC field the head of the chain;
6. The Entitlement Check for the head of the Attribution Chain;
7. Authorisation by tccd;
8. A synchronous reply, again in a dictionary returning the authorisation result of true.

Where next?

One unanswered question is how TCC data will be updated by Apple. In its Support Note detailing Mojave’s background updates (a valuable resource in itself), Apple includes “TCC Configuration Data” in its list of silent background updates, which “improves compatibility of specified software with macOS security features”.

The only repository of TCC data which appears intended to be updatable at present is /System/Library/Sandbox/TCC_Compatibility.bundle. I am watching this like a hawk, and may need to add it to the bundles covered by LockRattler.

If you’re suffering problems with TCC, in particular when you have an app which should be generating a consent dialog but doesn’t, as well as checking that app’s entitlements and usage strings using Taccy, try inspecting the log with the single predicate 'subsystem == "com.apple.TCC"' and looking for an exchange involving that app’s ID. It is easy to do that in Consolation 3, as you can make the app’s ID a filter, rather than part of the predicate. Once you have located the relevant log entries, remove that filter and browse all the messages from TCC around that time.

If you’re struggling to work out what to add to your Full Disk Access list to get a command to work, then you should be successful when you add the item listed in the ACC field of the Attribution Chain shown by TCC.

Further reading

Carl Ashley’s blog is an excellent resource: his take on log entries is slightly different, and is here. He is particularly focussed on management using MDM configuration profile payloads, and has an excellent summary here.

Rich Trouton’s Der Flounder blog is another valuable source of information, for example this article aimed again mainly at sysadmins using MDM.