5 ms·

Bypassing macOS TCC user privacy protections by accident and design

159 points by adib 5y ago

judge2020 5y ago
I think the original title would be better > 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.
- dang 5y ago
  Ah yes. Changed now. Submitted title was "macOS Privileged Access Backdoor" Submitters: "Please use the original title, unless it is misleading or linkbait; don't editorialize." https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
philistine 5y ago
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?
csande17 5y ago
> 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?
- crazygringo 5y ago
  Yes it's essentially sudo. By default, a user can't see another user's files.
- adib 5y ago
  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.
noizejoy 5y ago
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?
- dasyatidprime 5y ago
  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.
- salawat 5y ago
  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!" Except now we have two permission problems...
crazygringo 5y ago
> 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.
- my123 5y ago
  https://filebin.net/uwboypi04o23yzj8/Screenshot_2021-07-05_at_01.00.09.png https://filebin.net/uwboypi04o23yzj8/Screenshot_2021-07-05_a... It is explicitly detailed as such. Full disk access actually means full disk access under that system. > Time Machine backups [...] for all users on this Mac
  - GekkePrutser 5y ago
    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.
    - easton 5y ago
      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.
lilyball 5y ago
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.
- Dah00n 5y ago
  It gives full sudo access.
  - lilyball 5y ago
    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.
    - lilyball 5y ago
      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.
      - tsimionescu 5y ago
        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.
interactivecode 5y ago
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.
- tsimionescu 5y ago
  > 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.
GekkePrutser 5y ago
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.

159 points by adib 5y ago

judge2020 5y ago

I think the original title would be better > 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.

dang 5y ago
Ah yes. Changed now. Submitted title was "macOS Privileged Access Backdoor" Submitters: "Please use the original title, unless it is misleading or linkbait; don't editorialize." https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html

philistine 5y ago

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?

csande17 5y ago

crazygringo 5y ago
Yes it's essentially sudo. By default, a user can't see another user's files.
adib 5y ago
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.

noizejoy 5y ago

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?

dasyatidprime 5y ago
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.
salawat 5y ago
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!" Except now we have two permission problems...

crazygringo 5y ago

> 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.

my123 5y ago
https://filebin.net/uwboypi04o23yzj8/Screenshot_2021-07-05_at_01.00.09.png https://filebin.net/uwboypi04o23yzj8/Screenshot_2021-07-05_a... It is explicitly detailed as such. Full disk access actually means full disk access under that system. > Time Machine backups [...] for all users on this Mac
- GekkePrutser 5y ago
  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.
  - easton 5y ago
    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.

lilyball 5y ago

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.

Dah00n 5y ago
It gives full sudo access.
- lilyball 5y ago
  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.
  - lilyball 5y ago
    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.
    - tsimionescu 5y ago
      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.

interactivecode 5y ago

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.

tsimionescu 5y ago
> 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.

GekkePrutser 5y ago

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.