Some of the most intractable problems in Mojave are those arising from its new privacy protection. The Privacy pane in Security & Privacy and the command tool tccutil intentionally give users, sysadmins and developers almost no help. Most of the lists in the Privacy pane aren’t directly controlled by the user, and all tccutil seems able to do is wipe the contents of those lists. When you have a problem, you’re stuffed.

Until now, the only steps you can take beyond those involve reading the entitlements and other settings for the app, and wading through the log. Because of the way that the protection works, you can’t tell how it has handled an app or command tool’s request to access protected data or services unless you browse through thousands of entries in the log. Even using Consolation, that is far from easy.

I have now extended my free app Taccy, which already helps you examine entitlements and settings in an app, to provide customised access to the unified log which should make troubleshooting privacy control a great deal easier. If you’re familiar with Cirrus, which does the same for iCloud, then you’ll already be familiar with this new feature.

Taccy’s new log browser window gives instant access to selected log entries from the main subsystems involved in privacy protection: TCC, LaunchServices, securityd, and selected entries from tccd (the service at the heart of privacy protection) and sandboxd. The best way to explain this is to demonstrate its use.

I opened my app xattred when the system clock reached 17:04:00, then about 16 seconds later, had navigated it to open a file in my protected Calendars folder. This all worked fine, as xattred has the correct settings and info strings to ensure that TCC should let it do that.

I then opened the new version of Taccy, opened a log window, ensured the time period set went from 17:03:57 to 17:04:30, and clicked on its Get log button.

I show you here just a short excerpt from the log extract in Taccy, which shows what happened when I tried to access the Calendars folder. Although I have abbreviated some of the entries (marked with square brackets []), these are consecutive entries and haven’t been edited to remove intervening ‘noise’.

Accessing the Calendars folder is, for a hardened app, considered to be a request to the sandbox which it runs in, so the first entries show that being passed to TCC:
16.287 sandbox request approval
16.287 sandbox TCCAccessRequest() IPC
16.287 TCC Sending 0/7 synchronous to com.apple.tccd: request[] contents = "service" [] "kTCCServiceCalendar" [] "function" [] "TCCAccessRequest" []

The TCC service daemon asks for a SecTrust evaluation, and handles the request:
16.287 tccd SecTrustEvaluateIfNecessary
16.287 TCC tccd[369](501): handling request [] {service="kTCCServiceCalendar" function="TCCAccessRequest" []
16.287 TCC handle_TCCAccessRequest: []
16.287 TCC PID[119] is checking access for target PID[28287]
16.288 TCC Created SecCodeRef 0x7fae04a4edc0 for PID[28287].
16.288 tccd SecTrustEvaluateIfNecessary
16.288 tccd SecTrustEvaluateIfNecessary

securityd checks the certificate:
16.289 securityd asynchronously fetching CRL (http://crl.apple.com/root.crl) for client (tccd[369]/0#-1 LF=0)
16.289 securityd cert[2]: AnchorTrusted =(leaf)[force]> 0
16.290 tccd SecTrustEvaluateIfNecessary

TCC confirms that this is valid static code, then handles the request to access the Calendars folder:
16.291 TCC matchesCodeRequirementData: SecStaticCodeCheckValidity() [] from co.eclecticlight.xattred []; result: 0
16.291 TCC Handling access request to kTCCServiceCalendar, from co.eclecticlight.xattred []
16.291 securityd asynchronously fetching CRL (http://crl.apple.com/root.crl) for client (tccd[369]/0#-1 LF=0)
16.291 securityd cert[2]: AnchorTrusted =(leaf)[force]> 0

Finally, TCC grants the request, and tells the sandbox it can go ahead:
16.291 TCC Received synchronous reply [] "result" []: true
16.292 sandbox kTCCServiceCalendar granted by TCC for xattred

Note that in Taccy’s log window, each source of entries appears in a contrasting colour, for example with TCC shown in red. With the click of a checkbox, you can select which sources will be shown. If you’ve got lots of entries from other processes accessing TCC at the same time, you can use the standard Find feature to locate those entries which refer to the app that you’re assessing.

Among the crucially important log entries you’ll see when you use this are those which reveal TCC’s Attribution Chain, for example
16.273 TCC AttributionChain: ACC:{ID: co.eclecticlight.xattred, PID[28287], auid: 501, euid: 501, binary path: '/Applications/xattred.app/Contents/MacOS/xattred'}, REQ:{ID: com.apple.sandboxd, PID[119], auid: 0, euid: 0, binary path: '/usr/libexec/sandboxd'}
which shows that a request from sandboxd is being attributed by TCC to xattred, whose entitlements will determine the outcome. Attribution Chains are vital information when trying to discover why a command tool isn’t being given access to protected data, as it is normally the head of that chain, such as Terminal.app, whose privacy settings determine access for commands being run from that.

This new feature should make Taccy a much more versatile tool for anyone wanting to investigate problems with privacy protection in Mojave, and for those wanting to investigate TCC further. It is now available from here: taccy10b7
and from Downloads above.