Live data from Hacker News

You can't trust macOS Privacy and Security settings

eclecticlight.co

151–160 of 175 posts

Re: You can't trust macOS Privacy and Security settings

#151
post #46

Earlier quoted context omitted.

You don't need that permission if the user gives their implicit consent by selecting the Documents directory in the browse window. That's why most apps don't even show up in the Privacy Settings at all. Most apps don't need that, because they don't try to access that directory on their own. They only do it when the user selects the directory. I guess the improvement can be to show the implicit consent in the privacy…

Yeah, it's less of a "GOTCHA!" and more of a weird use case that Apple engineers probably didn't think through all the way. Doesn't seem like a difficult fix at all. If the app opens a window and prompts the user to select a directory to save a file or load a file, should that access be recorded in the privacy settings page? I'd argue that maybe there should be a verbose version of the privacy settings page, where if…

> Doesn't seem like a difficult fix at all.

Tell that to Apple engineering team who hasn’t been able to fix iCloud tab syncs after all this decade or so. Among hundreds of bugs that Apple users just live with, some even defend. Something tells me things in Apple’s OS architecture is so messily intertwined and too many things hardcoded that even competent software engineers at Apple will start having nightmares at the thought of touching them. Perils of a completely closed ecosystem (and don’t mean closed source).

Re: You can't trust macOS Privacy and Security settings

#152

Earlier quoted context omitted.

That makes it OK for you to not responsibly disclose a vuln? Cool I guess)

I have nothing to do with any of this. But since they don't consider these as vulnerabilities in the first place, then yeah, sure.

It's very common for large companies to "close" or downplay vulnerabilities. That doesn't exempt researchers from responsible disclosure timelines. There have been plenty of instances where a company reverses course after some back & forth and the looming threat of going public.

Re: You can't trust macOS Privacy and Security settings

#153

Earlier quoted context omitted.

It depends on the app whether that would make sense. If it is document centric, then yes. The user should explicitly open every time. If it doesn't make sense for the user to open it every time, it should ask for permanent permission and that should be recorded in system settings where it can be removed.

This seems like it would not work well with state restoration

What would not work? Give a specific example. The app has access to its own state data regardless. If it needs permanent access to one of my folders where I maintain my data, all it has to do is ask once.

Re: You can't trust macOS Privacy and Security settings

#154
post #115

Earlier quoted context omitted.

Isn’t it exactly the same on iOS? If you select a folder, the app gets a security scoped URL for the folder and can read/write the entire tree. The app can also then create a bookmark to persist the security scoped url and use it whenever in the future.

That URL should expire after a relatively short time.

Expiration depends on how the app has implemented the request for access. Granting access creates a security-scoped bookmark. The app can store it and use it the next time access is required which will bypass the prompt and the bookmark will remain valid in perpetuity (or until tcc reset), or the app can not store it and request permission every launch.

IIRC the bookmark is a base64 encoded plist containing bunch of data about the file/folder. A quick search got me this: https://www.mothersruin.com/software/Archaeology/reverse/boo...

Re: You can't trust macOS Privacy and Security settings

#155
post #20

I think I’m probably being dumb, but the gotcha here seems to be - ‘if I give an application permission to access a folder, it has access to the files in that folder’ - which is what I would expect??

The gotcha is “I gave it permission, then revoked permission in the UI, but it still has permission.”

So basically the opposite of Windows NTFS and SMB access. Windows is tricky but this is just bad.

Re: You can't trust macOS Privacy and Security settings

#156
post #115

Earlier quoted context omitted.

Isn’t it exactly the same on iOS? If you select a folder, the app gets a security scoped URL for the folder and can read/write the entire tree. The app can also then create a bookmark to persist the security scoped url and use it whenever in the future.

That URL should expire after a relatively short time.

This rules out entire classes of app and would make using a computer a miserable experience.

For example let's say you want to make an app that every day writes a backup to a particular location e.g. 1Password can do a daily backup of your encrypted passwords to a backup location.

Or, let's say you want to make a GUI around a command line program that stores its config as a dotfile.

Without a way to save access to file system locations persistently, apps would be forced to constantly shove open panels in your face all the time.

Re: You can't trust macOS Privacy and Security settings

#157
post #10

It seems that author basically found a 0day and published it. It's for sure better than selling it on the dark web but maybe it's better first tell it to Apple?

Not really, just an unintuitive security feature. You still need the user's permission to access that folder, but that permission is then persistent. I consider it a UX bug for sure but not an exploit.

if having to run an arcane terminal program to disable access while GUI is as if access was not granted is "unintuitive security feature" for you, I can't even.

Re: You can't trust macOS Privacy and Security settings

#159

Earlier quoted context omitted.

That makes it OK for you to not responsibly disclose a vuln? Cool I guess)

I have nothing to do with any of this. But since they don't consider these as vulnerabilities in the first place, then yeah, sure.

You literally made a statement justifying not responsibly disclosing vuln because apple process sucks

whether it is a vuln is different argument (it's sandbox escape and definitely usable as part of an exploit)

Re: You can't trust macOS Privacy and Security settings

#160
post #147

Earlier quoted context omitted.

That URL should expire after a relatively short time.

No, it shouldn’t. There are real reasons to give persistent access to a particular directory. Maybe you want your note taking app to put all notes in a directory for iCloud/dropbox/google drive/some other sync service.

I am baffled that anyone thinks implication-of-action ambiguity and hidden security states without obvious controls, are acceptable security practices.
Post reply on HN