Overview of TCC Bypasses by Accident and Design
Phil Stokes (via Hacker News):
Full Disk Access means what it says: it can be set by one user with admin rights and it grants access to all users’ data system-wide. […] When Alice grants FDA permission to the Terminal for herself, all users now have FDA permission via the Terminal as well. The upshot is that Alice isn’t only granting herself the privilege to access others’ data, she’s granting others the privilege to access her data, too.
Surprisingly, Alice’s (no doubt) unintended permissiveness also extends to unprivileged users. As reported in CVE-2020-9771, allowing the Terminal to have Full Disk Access renders all data readable without any further security challenges: the entire disk can be mounted and read even by non-admin users. Exactly how this works is nicely laid out in this blog post here, but in short any user can create and mount a local snapshot of the system and read all other users’ data.
[…]
Because of this complication, administrators must be aware that even if they never grant FDA permissions, or even if they lock down Full Disk Access (perhaps via MDM solution), simply allowing an application to control the Finder in the ‘Automation’ pane will bypass those restrictions. […] Granting FDA in the usual way requires an administrator password. However, one can grant consent for automation of the Finder (and thus backdoor FDA) without a password.
[…]
Administrators need to be aware that TCC doesn’t protect against files being written to TCC protected areas by unprivileged processes, and similarly nor does it stop files so written from being read by those processes.
Previously:
- Bypassing TCC By Changing the Environment
- Sandbox Doesn’t Protect Files From stat()
- mount_apfs TCC Bypass and Privilege Escalation
5 Comments RSS · Twitter
I'm a bit confused: If I, as an admin user, grant FDA to an app which I launched via Spotlight, Finder or Launchpad then do I grant it for myself alone (user-level) or for everyone (system-level)?
@Kentzo It is counterintuitive, because it doesn’t seem desirable and because the TCC database is stored in the home folder, but in my testing granting FDA to Terminal really does give other users FDA access to it as well. I was able to use this to access another user’s files via Time Machine, as described in the post.
It's the most unexpected outcome. I wonder if modern macOS is usable for single-user dev use under non-admin accounts. Does homebrew work? I guess I will have to find out.
> It is counterintuitive, because it doesn’t seem desirable and because the TCC database is stored in the home folder
Well, yes and no.
I have both /Library/Application Support/com.apple.TCC/TCC.db and ~/Library/Application Support/com.apple.TCC/TCC.db, and the "service" columns clearly differ. Things like kTCCServiceAddressBook are found in my per-user database, and kTCCServiceSystemPolicyAllFiles in the system-wide database. So that part matches my expectations of how the various Library domains should work.
Specifically, on my system, Accessibility, DeveloperTool, ListenEvent ("Input Monitoring"), PostEvent (?) and Screen Capture are across all users. AddressBook, AppleEvents ("Automation"), BluetoothAlways, Calendar, and Camera are only for my user. I find some of these categories baffling and also don't understand why they aren't even sorted in the UI. ("Accessibility" says "allow the apps below to control your computer", which doesn't really seem to be what accessibility is about, and then if that's the effect, how does that differ from "Automation"?)
Quality issues and alert fatigue aside, the UI needs work.
I'd say the main issue (and I don't mean to diminish it) is that the UI silently merges the two databases together, making it unclear that some settings apply to your user only, and others apply to everyone. (Though I will note that, as of 11.4, the Full Disk Access UI does explicitly say "for all users on this Mac"). Every all-user item in the table view should have a little icon with two faces or whatever, and a little note at the bottom explaining that icon.
Gha! Security theatre, extraordinaire. I don't have faith in any of it. Already disable SIP routinely. I think Apple's approach to this has been all wrong; they should have lured developers into a credible sandbox they could actually control with a proper carrot. Of course that would have required them to actually listen to developers, which they don't, so we get all this short-termism and breakage.
