macOS 11.4 Breaks Full Disk Access for Helper Tools

This change to TCC in macOS 11.4 was made to fix CVE-2021-30713:

https://arstechnica.com/gadgets/2021/05/hackers-exploit-a-macos-0day-that-allows-them-to-screenshot-infected-macs/

@Tim If so, it still seems like a bug to me. I think the exploit was that macOS was not detecting that the helper app had been added to the main app and that it was not signed with the same certificate. But a helper app should still inherit the main app’s authorizations if it’s legitimately part of the same signed bundle.

The whole TCC system is bizarre. Some facilities grant permissions to contained helper tools, while others require authorising both the parent and the helper.

And yes, I agree, the bug in the security failing was not in granting the subtool permission, it was in not detecting that the tool had been added, or the parent modified.

My app Find Any File also uses a helper tool that it invokes via NSTask, when searching entire volumes.

I just did a test in 11.4: Reset the TCC with `tccutil`, after which FAF asked for FDA again. Then I ran a search on the startup volume - the helper was able to search the entire volume and find files.

So, it seems that helpers that get run a child processes still inherit the TCC rights, at least. The new bug probably affects only bg helpers that are launched in other ways.

> This change to TCC in macOS 11.4 was made to fix CVE-2021-30713

Right, you shouldn't be able to place an arbitrary binary in a bundle and inherit its permissions. But…

* there already exists a mechanism by which the parent bundle blesses child binaries: an SMPrivilegedExecutables key in the Info.plist. Why not make an equivalent key for "allow these executables to inherit TCC settings". (One reason, I guess: because that wouldn't be backwards-compatible.)
* on top of that, there is another mechanism: the child binary should always have the same signing certificate as the parent binary.
* and another: the parent bundle's code signature gets invalidated if the bundle resources change. (I thought this was already the case anyway?)

> The whole TCC system is bizarre. Some facilities grant permissions to contained helper tools, while others require authorising both the parent and the helper.

Also, some permissions mandate that apps provide a reason in the Info.plist. Others don't.

Sometimes, the app can ask ahead of time if the permission needs to be authorized. Sometimes, it cannot.

As soon as an app requires mutliple permissions, multiple alerts come up, which, not a great experience.

>So, it seems that helpers that get run a child processes still inherit the TCC rights, at least. The new bug probably affects only bg helpers that are launched in other ways.

It's not clear from that thread, but my guess is what those people did was use SMJobBless to install the helper into /Library/PrivilegedHelperTools, so that it can run as root. Therefore, when running the tool, it doesn't actually launch from within the bundle (even though that is its origin), so maybe there's a new bug where TCC no longer recognizes that relationship.

TCC is definitely inconsistent and inscrutable. Some capabilities (Automation) have APIs to check whether you have permission, while others (Full Disk Access, Screen Recording) don't provide an API call and you have to try an operation to see if it fails, then prompt the user if it appears they haven't yet authorized your app. Some require that you develop UI to walk the user through Security & Privacy, while others like Screen Recording put up their own prompt, regardless of whether you want them to or not. There doesn't seem to have been any consistent API design or consideration of user interaction flows when putting together the privacy controls.

My experience with launching helper executables (bundled within my apps) via NSTask is that TCC permissions are inherited, and that seems to continue in 11.4. So, like Thomas says above, TCC inheritance must be broken when helper apps are launched in other ways (perhaps via launchd - which is actually how we're _supposed to do it, right?)

And regarding your comment about TCC failing randomly, Michael, I'm seeing that pretty regularly in my tech support stream. The TCC database seems to get confused / corrupted pretty frequently. Often it can be solved with 'tccutil reset ', but I've had a few occasions where I had to get a user to directly remove /Library/Application Support/com.apple.TCC/ to force a reset of all of TCC. The latter can be done without disabling SIP or anything though - just a simple 'sudo rm' is sufficient.

@Jon Is access to the com.apple.TCC folder new? I seem to recall that one could only delete—or even read—the database with SIP disabled. Was that by design or a symptom of other breakage on customer Macs? Here on Big Sur I can, as you say, delete the whole folder and even edit the database with sqlite3. I didn’t even have to authenticate as an admin like Dropbox did.

At least on Catalina and Big Sur, I haven’t seen any need to disable SIP. I’ll double check my support logs to see about earlier macOS releases, but I don’t recall any issues earlier either. Of course, I recommend using tccutil as the first course of action, so haven’t asked that many people to manually remove the DB.

I'm similarly going through hell of trying to get an AppleScript to run to input a username in a field which has worked previous to 11.4 but now prompts that our management service Jamf wants access to system events, but I am pushing a Privacy Profile that explicitly grants permission for jamf to use system events and accessibility. But something between the parent and child process seems broken for this as no matter what I try to white list, it no longer functions.