{
	"id": "d5a79850-097b-4966-8676-8d247877b1d0",
	"created_at": "2026-04-06T00:06:11.033392Z",
	"updated_at": "2026-04-10T13:12:35.45747Z",
	"deleted_at": null,
	"sha1_hash": "b6cc06da4b5917a4b2002ed14e6613a4374b1282",
	"title": "Bypassing macOS TCC User Privacy Protections By Accident and Design - SentinelLabs",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 5409077,
	"plain_text": "Bypassing macOS TCC User Privacy Protections By Accident and\r\nDesign - SentinelLabs\r\nBy Phil Stokes\r\nPublished: 2021-07-01 · Archived: 2026-04-05 19:11:26 UTC\r\nExecutive Summary\r\nTCC is meant to protect user data from unauthorized access, but weaknesses in its design mean that\r\nprotections are easily overridden inadvertently.\r\nAutomation, by design, allows Full Disk Access to be ‘backdoored’ while also lowering the authorization\r\nbarrier.\r\nMultiple partial and full TCC bypasses are known, with several actively exploited in the wild.\r\nTCC does not prevent processes reading and writing to ‘protected’ locations, a loophole that can be used to\r\nhide malware.\r\nIntroduction\r\nIn recent years, protecting sensitive user data on-device has become of increasing importance, particularly now\r\nthat our phones, tablets and computers are used for creating, storing and transmitting the most sensitive data about\r\nus: from selfies and family videos to passwords, banking details, health and medical data and pretty much\r\neverything else.\r\nWith macOS, Apple took a strong position on protecting user data early on, implementing controls as far back as\r\n2012 in OSX Mountain Lion under a framework known as ‘Transparency, Consent and Control’, or TCC for short.\r\nWith each iteration of macOS since then, the scope of what falls under TCC has increased to the point now that\r\nusers can barely access their own data – or data-creating devices like the camera and microphone – without\r\njumping through various hoops of giving ‘consent’ or ‘control’ to the relevant applications through which such\r\naccess is mediated.\r\nThere have been plenty of complaints about what this means with regards to usability, but we do not intend to\r\nrevisit those here. Our concern in this paper is to highlight a number of ways in which TCC fails when users and\r\nIT admins might reasonably expect it to succeed.\r\nWe hope that by bringing attention to these failures, users and admins might better understand how and when\r\nsensitive data can be exposed and take that into account in their working practices.\r\nCrash Course: What’s TCC Again?\r\nApple’s latest platform security guide no longer mentions TCC by name, but instead refers to ‘protecting app\r\naccess to user data’. The current version of the platform security guide states:\r\nhttps://www.sentinelone.com/labs/bypassing-macos-tcc-user-privacy-protections-by-accident-and-design/\r\nPage 1 of 12\n\n“Apple devices help prevent apps from accessing a user’s personal information without permission using various\r\ntechnologies…[in] System Preferences in macOS, users can see which apps they have permitted to access certain\r\ninformation as well as grant or revoke any future access.”\r\nIn common parlance, we’re talking about privacy protections that are primarily managed by the user in System\r\nPreferences’ Privacy tab of the Security \u0026 Privacy pane.\r\nSystem Preferences.app provides the front-end for TCC\r\nMac devices controlled by an MDM solution may also set various privacy preferences via means of a Profile.\r\nWhere in effect, these preferences will not be visible to users in the Privacy pane above. However, they can be\r\nenumerated via the TCC database. The command for doing so changes slightly with Big Sur and later.\r\nmacOS 11 (Big Sur) and later:\r\nsudo sqlite3 /Library/Application Support/com.apple.TCC/TCC.db \"SELECT client,auth_value FROM access\r\nmacOS 10.15 (Catalina) and earlier:\r\nsudo sqlite3 /Library/Application Support/com.apple.TCC/TCC.db \"SELECT client,allowed FROM access WHE\r\nhttps://www.sentinelone.com/labs/bypassing-macos-tcc-user-privacy-protections-by-accident-and-design/\r\nPage 2 of 12\n\nThe command line also presents users and administrators with the /usr/bin/tccutil utility, although its claim to\r\noffer the ability “to manage the privacy database” is a little exaggerated since the only documented command is\r\nreset . The tool is useful if you need to blanket wipe TCC permissions for the system or a user, but little else.\r\nThe spartan man page from tccutil\r\nUnder the hood, all these permissions are managed by the TCC.framework at\r\n/System/Library/PrivateFrameworks/TCC.framework/Versions/A/Resources/tccd .\r\nStrings in tccd binary reveal some of the services afforded TCC protection\r\nLooked at in a rather narrow way with regard to how users work with their Macs in practice, one could argue that\r\nthe privacy controls Apple has designed with this framework work as intended when users (and apps) behave as\r\nintended in that narrow sense. However, as we shall now see, problems arise when one or both go off script.\r\nhttps://www.sentinelone.com/labs/bypassing-macos-tcc-user-privacy-protections-by-accident-and-design/\r\nPage 3 of 12\n\nFull Disk Access – One Rule That Breaks Them All\r\nTo understand the problems in Apple’s implementation of TCC, it’s important to understand that TCC privileges\r\nexist at two levels: the user level and the system level. At the user level, individual users can allow certain\r\npermissions that are designed only to apply to their own account and not others. If Alice allows the Terminal\r\naccess to her Desktop or Downloads folders, that’s no skin off Bob’s nose. When Bob logs in, Terminal won’t be\r\nable to access Bob’s Desktop or Downloads folders.\r\nAt least, that’s how it’s supposed to work, but if Alice is an admin user and gives Terminal Full Disk Access\r\n(FDA), then Alice can quite happily navigate to Bob’s Desktop and Downloads folders (and everyone else’s)\r\nregardless of what TCC settings Bob (or those other users) set. Note that Bob is not afforded any special\r\nprotection if he is an admin user, too. Full Disk Access means what it says: it can be set by one user with admin\r\nrights and it grants access to all users’ data system-wide.\r\nWhile this may seem like good news for system administrators, there are implications that may not be readily\r\napparent, and these implications affect the administrator’s own data security.\r\nWhen Alice grants FDA permission to the Terminal for herself, all users now have FDA permission via the\r\nTerminal as well. The upshot is that Alice isn’t only granting herself the privilege to access others’ data, she’s\r\ngranting others the privilege to access her data, too.\r\nSurprisingly, Alice’s (no doubt) unintended permissiveness also extends to unprivileged users. As reported in\r\nCVE-2020-9771, allowing the Terminal to have Full Disk Access renders all data readable without any further\r\nsecurity challenges: the entire disk can be mounted and read even by non-admin users. Exactly how this works is\r\nnicely laid out in this blog post here, but in short any user can create and mount a local snapshot of the system and\r\nread all other users’ data.\r\nEven Standard users can read Admin’s private data\r\nThe ‘trick’ to this lies in two command line utilities, both of which are available to all users: /usr/bin/tmutil\r\nand /sbin/mount . The first allows us to create a local snapshot of the entire system, and the second to mount that\r\nhttps://www.sentinelone.com/labs/bypassing-macos-tcc-user-privacy-protections-by-accident-and-design/\r\nPage 4 of 12\n\nsnapshot as an apfs read-only file system. From there, we can navigate all users data as captured on the\r\nmounted snapshot.\r\nIt’s important to understand that this is not a bug and will not be fixed (at least, ‘works as intended’ appears to be\r\nApple’s position at the time of writing). The CVE mentioned above was the bug for being able to exploit this\r\nwithout Full Disk Access. Apple’s fix was to make it only possible when Full Disk Access has been granted. The\r\ntl;dr for Mac admins?\r\nWhen you grant yourself Full Disk Access, you grant all users (even unprivileged users) the ability to read all\r\nother users’ data on the disk, including your own.\r\nBackdooring Full Disk Access Through Automation\r\nThis situation isn’t restricted only to users: it extends to user processes, too. Any application granted Full Disk\r\nAccess has access to all user data, by design. If that application is malware, or can be controlled by malware, then\r\nso does the malware. But application control is managed by another TCC preference, Automation.\r\nAnd here lies another trap: there is one app on the Mac that always has Full Disk Access but never appears in the\r\nFull Disk Access pane in System Preferences: the Finder.\r\nAny application that can control the Finder (listed in ‘Automation’ in the Privacy pane) also has Full Disk Access,\r\nalthough you will see neither the Finder nor the controlling app listed in the Full Disk Access pane.\r\nBecause of this complication, administrators must be aware that even if they never grant FDA permissions, or\r\neven if they lock down Full Disk Access (perhaps via MDM solution), simply allowing an application to control\r\nthe Finder in the ‘Automation’ pane will bypass those restrictions.\r\nhttps://www.sentinelone.com/labs/bypassing-macos-tcc-user-privacy-protections-by-accident-and-design/\r\nPage 5 of 12\n\nAutomating the Finder allows the controlling app Full Disk Access\r\nIn the image above, Terminal, and two legitimate third party automation apps, Script Debugger and FastScripts, all\r\nhave Full Disk Access, although none are shown in the Full Disk Access privacy pane:\r\nhttps://www.sentinelone.com/labs/bypassing-macos-tcc-user-privacy-protections-by-accident-and-design/\r\nPage 6 of 12\n\nApps that backdoor FDA through Automation are not shown in the FDA pane\r\nAs noted above, this is because the Finder has irrevocable FDA permissions, and these apps have been given\r\nautomation control over the Finder. To see how this works, here’s a little demonstration.\r\n~ osascript\u003c\u003cEOD\r\nset a_user to do shell script \"logname\"\r\ntell application \"Finder\"\r\nset desc to path to home folder\r\nset copyFile to duplicate (item \"private.txt\" of folder \"Desktop\" of folder a_user of item \"Users\" of\r\nset t to paragraphs of (do shell script \"cat \" \u0026 POSIX path of (copyFile as alias)) as text\r\nend tell\r\ndo shell script \"rm \" \u0026 POSIX path of (copyFile as alias)\r\nt\r\nEOD\r\nAlthough the Terminal is not granted Full Disk Access, if it has been granted Automation privileges for any reason\r\nin the past, executing the script above in the Terminal will return the contents of whatever the file “private.txt”\r\ncontains. As “private.txt” is located on the user’s Desktop, a location ostensibly protected by TCC, users might\r\nhttps://www.sentinelone.com/labs/bypassing-macos-tcc-user-privacy-protections-by-accident-and-design/\r\nPage 7 of 12\n\nreasonably expect that the contents of this file would remain private if no applications had been explicitly granted\r\nFDA permissions. This is demonstrably not the case.\r\nBackdooring FDA access through automating the Finder\r\nThe obvious mitigation here is not to allow apps the right to automate the Finder. However, let’s note two\r\nimportant points about that suggestion.\r\nFirst, there are many legitimate reasons for granting automation of the Finder to the Terminal or other productivity\r\napps: any mildly proficient user who is interested in increasing their productivity through automation may well\r\nhave done so or wish to do so. Unfortunately, this is an “All-In” deal. If the user has a specific purpose for doing\r\nthis, there’s no way to prevent other less legitimate uses of Terminal’s (or other programs’) use of this access.\r\nSecond, backdooring FDA access in this way results in a lowering of the authorization barrier. Granting FDA in\r\nthe usual way requires an administrator password. However, one can grant consent for automation of the Finder\r\n(and thus backdoor FDA) without a password. A consent dialog with a simple click-through will suffice:\r\nA simple ‘OK’ gives access to control the Finder, and by extension Full Disk Access.\r\nhttps://www.sentinelone.com/labs/bypassing-macos-tcc-user-privacy-protections-by-accident-and-design/\r\nPage 8 of 12\n\nWhile the warning text is explicit enough (if the user reads it), it is far from transparent that given the Finder’s\r\nirrevocable Full Disk Access rights, the power being invested in the controlling app goes far beyond the current\r\nuser’s consent, or control.\r\nAs a bonus, this is not a per-time consent. If it has ever been granted at any point in the past, then that permission\r\nremains in force (and thus transparent, in the not-good sense, to the user) unless revoked in System Preferences\r\n‘Automation’ pane or via the previously mentioned tccutil reset command.\r\nThe tl;dr: keep a close and regular eye on what is allowed to automate the Finder in your System Preferences\r\nPrivacy pane.\r\nThe Sorry Tale of TCC Bypasses\r\nEverything we’ve mentioned so far is actually by design, but there is a long history of TCC bypasses to bear in\r\nmind as well. When macOS Mojave first went on public release, SentinelOne was the first to note that TCC could\r\nbe bypassed via SSH (this finding was later duplicated by others). The indications from multiple researchers are\r\nthat there are plenty more bypasses out there.\r\nThe most recent TCC bypass came to light after it was discovered being exploited by XCSSET malware in August\r\n2020. Although Apple patched this particular flaw some 9 months later in May 2021, it is still exploitable on\r\nsystems that haven’t been updated to macOS 11.4 or the latest security update to 10.15.7.\r\nOn a vulnerable system, it’s trivially easy to reproduce.\r\n1. Create a simple trojan application that needs TCC privileges. Here we’ll create an app that needs access to\r\nthe current user’s Desktop to enumerate the files saved there.\r\n% osacompile -e 'do shell script \"ls -al /Users/sphil/Desktop \u003e\u003e /tmp/lsout\"' -o /tmp/ls.app\r\n2. Copy this new “ls.app” trojan to inside the bundle of an app that’s already been given TCC permission to\r\naccess the Desktop.\r\n% cp -R /tmp/ls.app /Applications/Some Privileged.app/\r\nOne way you can find the current permitted list of apps is from the ‘Files and Folders’ category in the\r\nPrivacy tab of System Preferences’ Security \u0026 Privacy pane (malware takes another route, as we’ll explain\r\nshortly).\r\n3. Execute the trojan app:\r\n% open /Applications/Some Privileged.app/ls.app\r\nSecurity-minded readers will no doubt be wondering how an attacker achieves Step 2 without already having\r\nknowledge of TCC permissions – you can’t enumerate the list of privileged apps in the TCC.db from the Terminal\r\nhttps://www.sentinelone.com/labs/bypassing-macos-tcc-user-privacy-protections-by-accident-and-design/\r\nPage 9 of 12\n\nunless Terminal already has Full Disk Access.\r\nAssuming the target hasn’t already granted Terminal FDA privileges for some other legitimate reason (and who\r\nhasn’t these days?), an attacker, red teamer or malware could instead enumerate over the contents of the\r\n/Applications folder and take educated guesses based on what’s found there, e.g., Xcode, Camtasia, and Zoom\r\nare all applications that, if installed, are likely to be privileged.\r\nSimilarly, one could hardcode a list of apps known to have such permissions and search the target machine for\r\nthem. This is precisely how XCSSET malware works: the malware is hardcoded with a list of apps that it expects\r\nto have screen capture permissions and injects its own app into the bundle of any of those found.\r\nDecoded strings from XCSSET malware reveals a list of apps it exploits for TCC permissions\r\nUnfortunately, the fix for this particular bug doesn’t effectively stop malware authors. If the bypass fails, it’s a\r\nsimple matter to just impersonate the Finder and ask the user for control. As with the Automation request, this\r\nonly requires the user to click-through their consent rather than provide a password.\r\nFake Finder App used by XCSSET malware to access protected areas\r\nhttps://www.sentinelone.com/labs/bypassing-macos-tcc-user-privacy-protections-by-accident-and-design/\r\nPage 10 of 12\n\nAs we noted above, the (real) Finder already has Full Disk Access by default, so users seeing a request dialog\r\nasking to grant the Finder access to any folder should immediately raise suspicion that something is amiss.\r\nTCC – Just One More Thing\r\nThat almost wraps up our tour of TCC gotchas, but there’s one more worth pointing out. A common\r\nmisunderstanding with Apple’s User privacy controls is that it prevents access to certain locations (e.g., Desktop,\r\nDocuments, Downloads, iCloud folders). However, that is not quite the case.\r\nAdministrators need to be aware that TCC doesn’t protect against files being written to TCC protected areas by\r\nunprivileged processes, and similarly nor does it stop files so written from being read by those processes.\r\nA process can write to a TCC protected area, and read the files it writes\r\nWhy does this matter? It matters because if you have any kind of security or monitoring software installed that\r\ndoesn’t have access to TCC-protected areas, there’s nothing to stop malware from hiding some or all of its\r\ncomponents in these protected areas. TCC isn’t going to stop malware using those locations – a blind spot that not\r\nevery Mac sys administrator is aware of – so don’t rely on TCC to provide some kind of built-in protected ‘safe-zone’. That’s not how it works, when it works at all.\r\nConclusion\r\nWe’ve seen how macOS users can easily and unknowingly expose data they think is protected by TCC simply by\r\ndoing the things that macOS users, particularly admins, are often inclined to do. Ironically, most of these\r\n‘inadvertent breaches’ are only possible because of TCC’s own lack of transparency. Why, for example, is the\r\nFinder not listed in the Full Disk Access pane? Why is it not clear that Automation of the Finder backdoors Full\r\nDisk Access? And why is password-authentication downgraded to a simple consent prompt for what is,\r\neffectively, the same privilege?\r\nOther questions raised by this post concern whether consent should have finer grained controls so that prompts\r\ncan be optionally repeated at certain intervals, and – perhaps most importantly –  whether users should be able to\r\nprotect their own data by being allowed to opt out of FDA granted by other users on the same device.\r\nWe know that malware abuses some of these loopholes, and that various TCC bugs exist that have yet to be\r\npatched. Our only conclusion at this point has to be that neither users nor admins should place too much faith in\r\nthe ability of TCC as it is currently implemented to protect data from unauthorized access.\r\nhttps://www.sentinelone.com/labs/bypassing-macos-tcc-user-privacy-protections-by-accident-and-design/\r\nPage 11 of 12\n\nSource: https://www.sentinelone.com/labs/bypassing-macos-tcc-user-privacy-protections-by-accident-and-design/\r\nhttps://www.sentinelone.com/labs/bypassing-macos-tcc-user-privacy-protections-by-accident-and-design/\r\nPage 12 of 12",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://www.sentinelone.com/labs/bypassing-macos-tcc-user-privacy-protections-by-accident-and-design/"
	],
	"report_names": [
		"bypassing-macos-tcc-user-privacy-protections-by-accident-and-design"
	],
	"threat_actors": [],
	"ts_created_at": 1775433971,
	"ts_updated_at": 1775826755,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/b6cc06da4b5917a4b2002ed14e6613a4374b1282.pdf",
		"text": "https://archive.orkl.eu/b6cc06da4b5917a4b2002ed14e6613a4374b1282.txt",
		"img": "https://archive.orkl.eu/b6cc06da4b5917a4b2002ed14e6613a4374b1282.jpg"
	}
}