In my last article, I gave an introduction to Apple's Transparency, Consent, and Control (TCC) framework. The primary goal of TCC is to empower users with transparency regarding how their data is accessed and used by applications. This time around, we're going to dig deeper into the mechanism that runs TCC and what's going on in the background.
The Primary Framework
TCC is managed by a tccd binary in the System directory, at /System/Library/PrivateFrameworks/TCC.framework/Support/tccd. It’s worth noting, that formerly, this binary was located within the /Versions/A/ directory in the .framework bundle but has since moved.
There is one aspect of TCC parlance that I want to cover before we dive too deep. We will be primarily talking about two () when we speak about the TCC framework—we'll often discuss a client and a service. In this case, the client is the application that’s requesting permission, such as Zoom, whereas the service is the permission it is requesting, such as camera or microphone access. The client is requesting access to a service.
If we dump the strings from this binary, we can see the different services that TCC covers, although their names are not necessarily straightforward.
When we look in our TCC databases, one of the columns we'll see is service. Within this service field, we’ll see one of the above values, correlating the requesting application and the requested service.
When a user, let's say, wants to use their microphone in a program that hasn't requested access yet, Apple will display a prompt, asking the user if they want to “Allow” or “Not Allow” access. These prompts can look different depending on the service. We can dump the contents of the binary property list (plist) located at /System/Library/PrivateFrameworks/TCC.framework/Resources/Localizable.loctable, and see some of Apple's prompts in the plist.
<key>en</key>
<dict> <key>NOTIFY_BUTTON_kTCCServiceSystemPolicyAppBundles</key>
<string>Allow…</string>
<key>NOTIFY_SERVICE_kTCCServiceSystemPolicyAppBundles</key>
<string>"%@" was prevented from modifying apps on your Mac.</string> <key>REQUEST_ACCESS_ADD_MODIFY_ADDED</key> <string>Keep Add Only</string> <key>REQUEST_ACCESS_ADD_kTCCServiceCalendar_ADD</key> <string>OK</string> <key>REQUEST_ACCESS_ALLOW</key> <string>Allow</string> <key>REQUEST_ACCESS_ALLOW_kTCCServiceFocusStatus</key> <string>OK</string> <key>REQUEST_ACCESS_ALLOW_kTCCServiceGameCenterFriends</key> <string>Allow</string> <key>REQUEST_ACCESS_ALLOW_kTCCServicePhotos</key> <string>Allow Access to All Photos</string> <key>REQUEST_ACCESS_DENY</key> <string>Don't Allow</string> <key>REQUEST_ACCESS_DENY_kTCCServiceFocusStatus</key> <string>Don't Allow</string>
truncated
In our case, this is the key/value pair that applies to our specific use case where %@ is the client making the request.
<key>REQUEST_ACCESS_SERVICE_kTCCServiceMicrophone</key>
<string>“%@” would like to access the microphone.</string>
Let's examine our root-level TCC database, located at /Library/Application Support/com.apple.TCC.db, take a peek at an entry, and map the columns to the values. In this case, we're looking at the system extension from Red Canary's Red Canary Mac Monitor tool.
kTCCServiceEndpointSecurityClient - service (a system extension with the Endpoint Security entitlement)
com.redcanary.agent.securityextension - client (generally the Bundle Identifier (or path) of the client making the request)
0 - client_type (the client is a bundle ID(0) or an absolute path(1), which is common for debug tools or Xcode projects)
2 - auth_value (user action taken - denied(0), unknown(1), allowed(2), limited(3))
4 - auth_reason (how the user took the action)
1 - auth_version
"X'212 bytes'" - csreq (binary blob)
NULL - policy_id
0 - indirect_object_identifier_type
UNUSED - indirect_object_identifier (bundle ID or absolute path of the client interaction)
NULL - indirect_object_code_identity
0 - flags
1681493977 - last_modified (last time it was modified in epoch time)
NULL - pid
NULL - pid_version
UNUSED - boot_uuid
0 - last_reminded
Understanding these different fields can help us navigate all what TCC is tracking.
MDM Overrides
One odd caveat of TCC is the MDMOverrides.plist located in the same com.apple.TCC directory. This binary property list contains MDM-specific TCC permissions. Via MDMs, administrators can deploy payloads, called PPPC payloads, that get added to the System Settings > Profiles. Here, admins can specify TCC permissions they want enabled or not. This is paramount in allowing admins to deploy software silently, run commands on the endpoint, and lots more.
However, because these permissions are added to the MDMOverrides.plist, as opposed to the TCC.db, they sometimes go unreflected in the UI. This can make triage of deployment issues tedious while attempting to cross reference files. In the meantime, most users cannot assist since the UI goes unchanged.
We've also seen issues where MDMs give some system binaries too broad of permissions. In one case, we observed an MDM giving bash full disk access (FDA) to its out-of-the-box, primary payload. Unfortunately, because they didn't only give their own signed agent permissions, then call bash from their agent, they gave (and actively give) bash carte blanche to the entire system. When I discovered this, I checked my TCC permissions in the UI, then I checked the actual sqlite database, via sqlite3 /Library/Application Support/com.apple.TCC/TCC.db before I realized that this was buried roughly halfway through my MDMOverrides file. Although I can understand Apple's design idea behind this—making it so MDMs can operate behind the scenes to add these permissions, if administrators are unaware of the effect of the payloads they're deployed, this could be an easy way for a threat actor to easily live-off-the-land.
Wrap Up
TCC is arguably one of the primary user-facing security features provided by Apple out of the box and is one of the first lines of defense to protect against on-disk abuse. Understanding its building blocks and operations can help security professionals and administrators, and even end users, navigate its labyrinth.
Next time, on Full Transparency, we’ll discuss the MDMOverrides property list and all of the nuances therein.
