[HN Gopher] Bypassing macOS TCC user privacy protections by acci...
       ___________________________________________________________________
        
       Bypassing macOS TCC user privacy protections by accident and design
        
       Author : adib
       Score  : 82 points
       Date   : 2021-07-04 18:39 UTC (4 hours ago)
        
 (HTM) web link (labs.sentinelone.com)
 (TXT) w3m dump (labs.sentinelone.com)
        
       | crazygringo wrote:
       | > _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.
        
       | lilyball wrote:
       | 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.
        
       | judge2020 wrote:
       | 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 wrote:
         | 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
        
       | csande17 wrote:
       | > 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 wrote:
         | Yes it's essentially sudo.
         | 
         | By default, a user can't see another user's files.
        
       | philistine wrote:
       | 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?
        
       | noizejoy wrote:
       | 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 wrote:
         | 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.
        
       ___________________________________________________________________
       (page generated 2021-07-04 23:00 UTC)