Live data from Hacker News

You can't trust macOS Privacy and Security settings

eclecticlight.co

91–100 of 175 posts

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

#91
post #32

Earlier quoted context omitted.

The problem is that this given permission doesn’t show in Files & Folders, and after turning it on and off there it still persists. The only way to revoke it is using some CLI command and restart the computer.

You “feed” it the document. Same way you select a picture on iOS. It is your deliberate decision and intent to open the document with that application. That is totally different from the application having permission to scan and view anything in for example the downloads folder

When you use iOS's "limited access" permissions to give an app access to some of your photos but not the whole library, the photo picker UI does a pretty good job of letting you easily do three things:

1) Grant access to a photo

2) Identify which photos you've granted access to

3) Revoke previously granted access

macOS's concession to give access to whole folders at a time is necessary for real software to work, but they haven't done a good job of items 2 and 3.

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

#92

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 exactly. It's not a "new" attack vector, any software which was malicious would have already been able to attack when you first gave it permission (a prerequisite for this sticky permission issue). If you had downloaded an app and discovered it was malicious the remedy would generally be to uninstall the app, not just "revoke the permission for the one folder". It's not a good look for Apple, and it's not great t…

> If you had downloaded an app and discovered it was malicious the remedy would generally be to uninstall the app

There are many apps that themselves are not malicious but they run untrusted code via plugins and stuff. Like VS Code for example.

So you gave it a permission and then revoked it thinking all is fine. tomorrow an extension was hijacked and it now reads your files. cool?

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

#94
post #77

So the title should be something more like "macOS apps retain access to folders after access is removed by the user".

Nope. The user is not revoking the access that they granted. They are revoking general access to a folder, but since there is no way to revoke specific access nothing happens.

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

#95
post #93

It turns out the issue is a com.apple.macl extended attribute that gets set on the Documents folder and can't be removed, due to SIP.

Doesn’t seem like a bug to me - it’s just a poor UI. Two different security systems both working properly but only one has a UI to show the protections.

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

#96
post #46
post #42

Earlier quoted context omitted.

The point is that (a) it’s misleading that the app has access to the folder while the settings claim that it doesn’t, and (b) there is no reasonable way for the user to revoke the implicitly given permission.

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…

I don't think any long-term implicit consent is acceptable. I would not expect that after opening one document in a folder without being shown any permission prompt, that permissions have been permanently altered. I would never even go look to see if it was "implicitly permitted".

Without a prompt or notice, I would expect only that the app has access to the file or directory I chose until the app is closed/quit.

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

#97
post #81
post #78

The post misunderstands how the permission system works. Giving access to a file via the Open and Save panel is an explicit declaration of consent. Because the panel is provided by OS itself, the app doesn't get access to the item until the user has selected a folder or file through that panel.

No, this is definitely a bug. The Privacy and Security panel is part of Settings, which is definitely part of the OS. Saying the Open and Save panel somehow has priority suggests that the Privacy and Security panel is not looking at the same parameters as the Open and Save panel, ergo a bug.

It’s not a bug and that is clear if you don’t use the documents folder as your example. When granting specific access it is not the same system as when granting general Documents folder access.

The UI just doesn’t reflect this.

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

#98
post #45
post #39

Earlier quoted context omitted.

This reminds me of the early days of MacOS where "repair permissions" was the magic fix to everything, or so it was rumored.

Whoa you are bringing back some memories. And it absolutely was a magic fix. I stand by it.

Safari is snappier now

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

#99

Earlier quoted context omitted.

Apple Security would instantly close it as "don't see the problem here" if you reported it to them. They have a poor reputation around TCC bug reports.

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.

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

#100
post #95
post #93

It turns out the issue is a com.apple.macl extended attribute that gets set on the Documents folder and can't be removed, due to SIP.

Doesn’t seem like a bug to me - it’s just a poor UI. Two different security systems both working properly but only one has a UI to show the protections.

Why would you think it's "working properly"?

The app somehow gained a permanent permission that I didn't give and that I can't remove no matter what I do. That's not working properly in any sense.

Post reply on HN