> At least, that’s how it’s supposed to work, but if Alice is an admin user and gives Terminal Full Disk Access (FDA), then Alice can quite happily navigate to Bob’s Desktop and Downloads folders (and everyone else’s) regardless of what TCC settings Bob (or those other users) set... 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... Any application granted Full Disk Access has access to all user data, by design.
This indeed seems dangerously counterintuitive.
I, like most other people I'd think, always assumed the permission dialogs ("TCC") were a layer of restrictions on top of traditional UNIX user permissions. Not overriding them.
In other words, granting full-disk access to an app would give it access to everything my user can access. Not "sudo" access to other users' data as well.
Why would an app ever need that level of access? For installing files, maybe, but not while running.
Can anyone else confirm this is how macOS actually works? And if there's some justification I'm missing? It seems so crazy that I can't actually believe it without somebody else verifying it.
The problem isn't that TCC grants a Unix file permission bypass - because it doesn't, at least not on it's own. The problem is that ordinary users can create APFS snapshots via Time Machine, and then mount them with Unix permissions disabled (noowners). When Apple was told about this they decided to gate the snapshot mounting stuff... behind Full Disk Access, not being an admin. And Finder has FDA, because of course it does, otherwise users wouldn't be able to use their own filesystem rights at all.
All of this smacks of different parts of the macOS core team not understanding their security model. One half seems to think Full Disk Access just means "has the user's file system permissions instead of sandboxed access" (hence why Finder has it), while the other thinks it means "access the whole disk, regardless of other permissions". Both interpretations are reasonable but become unreasonable when combined into a single system.
To an extent neither are wrong - full disk access doesn't directly bypass the live filesystem's Unix permissions. But it does explicitly grant full access to Time Machine backup images regardless of admin/superuser privileges, including the ability to create new up-to-date snapshots, which is equivalent to full read-only access ignoring Unix permissions (on a short time delay.)
... in this case it _does_, albeit in a roundabout way via Time Machine local snapshots. In short, the attacker can bypass Unix file permissions by mounting a local backup with owners disabled.
> In other words, granting full-disk access to an app would give it access to everything my user can access. Not "sudo" access to other users' data as well.
> Why would an app ever need that level of access? For installing files, maybe, but not while running.
Though bootable full disk backups aren’t possible anymore with the recent releases of macOS, there are applications such as Carbon Copy Cloner and SuperDuper! that need full disk access to create a backup of the entire volume. This is a limited case, but there are many people who use these (instead of or in addition to Time Machine).
That seems like the less likely parsing of the actual text. The more plausible reading would have the "for all users" apply only to the bit about "certain administrative settings", which may by their nature need to apply to all users instead of per-user.
A less ambiguous warning is needed if this is truly meant to be such a powerful setting that overrides regular user-based permissions.
True but the other point mentioned in the article: - giving automatic access to Finder automatically leading to that app getting FDA access without appearing in the list - is very counterintuitive I think.
Intuitive to a end-user, perhaps not (but why are they modifying those settings anyway? Well behaved apps don’t ask for FDA), but for a developer or power user it should be. If I allow Terminal.app FDA it means that any executables it hatches have FDA, or else it would be super confusing if you give it FDA and then wonder why nothing seems to have changed.
> but why are they modifying those settings anyway?
This is exactly the Apple attitude that bothers me. The idea that a user shouldn't be messing with settings. This is why they remove them as much as they can.
But sometimes there's a good reason to want to change something. Apple's vision isn't always right for everyone. And some users just have more complex needs. Imagine telling an Arch Linux user 'why would you want to change settings anyway?' :) It would break the entire idea behinds the that distribution.
In this case they do even offer the setting (so even Apple see the need for it) but it's not very transparent what it does.
PS: I'm not saying the arch method would work for Apple of course ;) But I am saying that what is configurable should be well documented, and that Apple should probably have a bit more configurability in my opinion.
> Bypassing macOS TCC User Privacy Protections By Accident and Design
Simply because 'backdoor' is especially vague - I first thought it was about Apple backdooring their users perhaps, but it's a way for malware to abuse Finder to bypass the 'Full Disk Access' permission prompt. It's also not an editorialized title.
It’s been too many years, since I had detailed professional involvement with computer and network security, so I apologize if this question is stupid and I’m not even sure, if it’s even phrased quite right by modern standards:
On a computer shared by multiple people and multiple applications, shouldn’t privileges be assigned at the intersection between user and app (and or groupings thereof)? And if there was some sort of privileges table, it would have a composite key consisting of app-id and user-id.
Is any modern OS actually set up that way and if yes, is there any way to generate a report to show the combination of user/app privileges?
Last I checked (which was quite a while ago), Android with multi-user support did in fact assign one Linux UID to each (user, app) tuple! But I don't recall there being a particularly rich privilege model available in practice for the multi-user sharing case, only for isolation. Inter-app intents were handled using Binder IPC underneath; I don't know what use that made of the Linux credentials.
Many server applications handle user separation internally, without reference to the underlying OS, while application separation is much stronger (separate VMs, SELinux, etc.), and desktop platforms have user separation but often-unsandboxed apps, so those are in some ways duals of each other…
I'm not sure what Windows does with UWP and sandboxed apps from the Microsoft Store, but that would be a good place to look.
I'm fairly sure that anything permission related has been completely mangled beyond all recognizability in this brave new world of "why should users be burdened with understanding the basic abstractions and mechanics of computing, just give them an app!"
> At least, that’s how it’s supposed to work, but if Alice is an admin user and gives Terminal Full Disk Access (FDA), then Alice can quite happily navigate to Bob’s Desktop and Downloads folders (and everyone else’s) regardless of what TCC settings Bob (or those other users) set.
How does this interact with regular Unix file permissions? Is the assumption that Alice is using sudo, or do modern macOS versions mark all user files world-readable?
Alice finds a recent Time Machine local snapshot and mount that elsewhere with owners disabled. Then Alice can browse everyone else's (recent) files – without needing sudo access.
I really think Apple should be clearer about what all this stuff does. They're adding a layer of what looks like security but it's not always clear how it behaves.
I feel Apple tries to hide complexity from the user too much. I understand they want to do this by default but there should be a way for technical users to know what's going on. I don't think that's the case well enough now.
Especially that thing with the full disk access cascading though the automation permission is very vague.
This shit is bananas! I had no idea, as the average user, about such glaring holes in the protection. Any app can read and write its own files in the protected folders? How on earth could that be intended?
As I understand it full disk access means the app can read the disk outside of the usual (strict) app sandbox or explicit user actions like file modals.
This is completely separate from the unix user permissions.
> This is completely separate from the unix user permissions.
It's supposed to be separate, but, with the Time Machine hole, it actually overrides them. So, if an admin enables FDA for Terminal (so that they can actually use it), then a Guest account on the system can use Terminal to create a TM snapshot, mount it, and read any file on the system, from any user, regardless of Unix file permissions.
How does granting automation access to Finder allow other users to access Alice’s data? TCC doesn’t negate standard Unix file permissions, and other users couldnt read Alice’s data before TCC. And the standard user directories (such as Desktop) are not accessible by other users.
(1) Create a snapshot of the entire file system;
(2) or find a recent Time Machine local snapshot; then
(3) mount the snapshot obtained in [1] or [2] without owners enabled, effectively granting Alice read-only access to other people's files without having administrative privileges.
The Finder doesn’t create or mount APFS snapshots. And while I haven’t tested it, I fully expect Time Machine to still enforce Unix file permissions. You really need to be using the command line to do what you’re describing.
I haven’t tested the Finder case though. Nevertheless there is the `tell ‘Finder’ ... do shell script ... end tell` construct that _may_ be able to get the Finder to launch an arbitrary subprocess (and may inherit full disk access) just like how Terminal would.
However I’ve tested mounting a local snapshot using the Terminal having full disk access and found out that it is possible to mount a local snapshot and make the mounted copy ignore Unix file permissions.
Finder doesn’t run as sudo though. TCC is layered on top of Unix file permissions. It prohibits access to files, it doesn’t open a hole through pre-existing protections.
Basically, it acts as a sandbox rule. Sandboxing your app doesn’t allow you access to new files, it just denies access as determined by the sandbox profile.
I just took another look at the article and it appears I misunderstood what it was saying. I thought it was saying automation of Finder granted access to other users' files. This is not the case. It was talking about accessing other users' files in the previous section, but in this one it's merely claiming that allowing automation of Finder means being able to read data owned by your user that would otherwise be blocked by TCC.
And honestly, that's not a surprise. "Granting an app the ability to automate the Finder means granting it the ability to access any data the Finder can access" seems fairly obvious.
The article's point is that, while understandable, the UI completely hides these facts from you. Finder is not mentioned as having FDA in the settings app, and so, even if you realize that Automation of FDA app means having FDA, you won't be able to tell implicitly that apps having Automation of Finder rights also have FDA through this mechanism.
Furthermore, in principle there is nothing stopping OSX from giving me a prompt when Automation AppX without FDA access wants to access my files through Finder specifically.
This indeed seems dangerously counterintuitive.
I, like most other people I'd think, always assumed the permission dialogs ("TCC") were a layer of restrictions on top of traditional UNIX user permissions. Not overriding them.
In other words, granting full-disk access to an app would give it access to everything my user can access. Not "sudo" access to other users' data as well.
Why would an app ever need that level of access? For installing files, maybe, but not while running.
Can anyone else confirm this is how macOS actually works? And if there's some justification I'm missing? It seems so crazy that I can't actually believe it without somebody else verifying it.