Here we are! Another edition of Ask the Mac Guy! In this series, we've been discussing some of the basic principles around macOS security, such as debunking common macOS security myths and the basics of securing Macs.
Today, we're going to get slightly more granular and drill down into Apple's technology.
In other articles, I've spoken about the technology that Apple ships with their product—their built-in security tools, if you will. One of the ways that Apple attempts to keep users safe is with Transparency, Consent, and Control (TCC). The TL;DR is that TCC is a collection of SQLite databases on disk, and when software desires to access parts of your hardware or software that may contain sensitive/personal information, it gives the users an interactive alert that requires the user to Allow or Deny the request. It makes explicit approval by the user a requirement for the software to access the service it's requesting. For example, if I am a Zoom user, the first time I try to turn on my camera, macOS will prompt me to Allow or Don't Allow Zoom's access to my camera. If I say 'Don't Allow,' then Zoom cannot toggle my camera on. I give this context because today, we're talking about a very specific part of TCC, which is a service called Full Disk Access.
Understanding Full Disk Access for macOS
Why is Full Disk Access (FDA) important? Good question. Certain applications, Zoom being a prime example, cannot operate properly or to their fullest potential without specific TCC permissions. In some cases, this TCC permission is FDA. This is applicable to the future of Managed EDR for macOS, as we start to build that out here at Huntress.
The FDA permission within the TCC database is arguably one of the most critical services when it comes to privacy. When TCC bypasses have been disclosed, the largest concern typically centers around FDA. We’ve seen TCC bypassed by some sophisticated malware like XCSSET, where malware was able to piggyback on other TCC permissions. If the malware had full disk access, it would be able to access all of the user’s sensitive data. This could lead to lateral movement across the network, higher chances for future social engineering attacks, spying on users, etc. On the flip side, if I were a blue teamer and needed to perform incident response on an endpoint using Aftermath, my Terminal would need full disk access so my IR tool could collect all of the relevant and important data from the device in order to perform a proper investigation.
In the TCC database, Apple refers to Full Disk Access using the field
kTCCServiceSystemPolicyAllFiles . When we see this field in the database, you can see the client that made the request.
To the end user, if you navigate to
System Settings >
Privacy & Security >
Full Disk Access , you can see all of the applications (
clients - as they're referred to in the database) that have requested FDA and whether or not the user approved or denied the request.
In our second edition of Ask the Mac Guy, we spoke about FDA when it comes to best practices for securing your Mac. Here, we spoke about auditing your TCC permissions. One way, at the business level, to ensure these are not tampered with is to roll Mobile Device Management (MDM) software. There are a handful of MDMs that are out there—Microsoft Intune, Jamf Pro, Addigy, and more.
MDMs get more leeway from Apple when it comes to TCC and FDA. MDMs have features called PPPC (Privacy Preferences Policy Control). This allows administrators to deploy a payload that contains a series of key/value pairs. Having specific keys and values can grant software TCC access, such as FDA.
For example, if I want to give the Huntress agent full disk access permissions, I would create a payload in my MDM and push it to the endpoint. To view it, I would check
System Settings >
This image shows how the Huntress agent is allowed full disk access using the bundle identifier
It's worth noting how helpful an MDM can be when deploying software or working with applications and software on macOS. It can deploy software to multiple devices at once, as well as grant permission to applications, without the need to physically be on the device itself.
If you’re ever interested in taking a deeper dive into the TCC databases on the system—one at the root level and one for each user, you can do so from the Terminal or whatever CLI you prefer. Although the schema for these two databases is identical, what they hold within differs. The root TCC database, which lives at /Library/Application Support/com.apple.TCC/TCC.db, holds more sensitive information, such as full disk access, screenshots, or input monitoring. The per-user TCC database, located at ~/Library/Application Support/com.apple.TCC/TCC.db, holds the permissions for microphone access, camera access, folder access (Desktop, Downloads, etc.), location data, and more.
If we take a look at our local TCC database, you can see a list of what applications (based on their bundle identifier), what they requested, and the action taken. Here, the command I run is:
sqlite3 ~/Library/Application\ Support/com.apple.TCC/TCC.db
This will open my user (~) TCC database; then, I run the following SQLite command.
SELECT client, service, auth_value, auth_reason, datetime(last_modified, "unixepoch") FROM access ORDER BY last_modified DESC;
This can apply to full disk access as well, and much more information about TCC can be found in our Built-In macOS Security Tools blog.
When applications are not functioning as expected, ensuring the application has the proper or necessary permissions—like full disk access—should be a common troubleshooting step. It often trips up administrators and end users, and can cause frustrations in usability. The design by Apple is to help restrict applications from overreaching, and although it's replete with 0-days, I truly believe that the desire behind it was honest and well-intended.