Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

You can't trust macOS Privacy and Security settings

eclecticlight.co

Post reply on HN
Print view View original

41–50 of 175 posts

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

#41

Post by ethanrutherford »

throwaway290 wrote: post #6

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 that the permission revocation basically doesn't actually work, but any malware that could have infected the system due to this issue would have also been able to infect the system while the permission was still (intentionally) enabled.

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

#42

Post by layer8 »

mh8h wrote: post #35
layer8 wrote: 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.

That's not what's happening here. Forget about the first 5 steps. If you install the app and start from step 6, the behaviour will be the same. If the user chooses the Documents folder in the browse window in an app, the app can use the contents of the Documents folder without the need for that permission in the Settings page. The Privacy settings applies only to access to the Documents folder without the user intera…

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.

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

#43

Post by altairprime »

Angostura wrote: post #12

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

One might expect macOS to recognize “you selected a folder that’s already got a UI associated with it” and to wire this up on the backend through the UI rather than creating a simple path exception that leaves the UI nonfunctional. I would have just filed a feedback report about it; but, the outrage-framing of that is, in historical context for this particular site, normal. They have posted extensively about Gatekeeper and TCC issues and seem to encounter them rather more reliably than others do, and released various tools (including today’s!) to support debugging, so certainly I empathize!

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

#44

Post by iamcalledrob »

jasonjei wrote: post #7

The problem with Mac’s sandbox system is that it’s giving me some PTSD of Windows UAC. It’s inventing a solution to a problem that might exist in small doses, but instead gives users permission fatigue. I personally think the traditional *nix model has served us quite well, and elective sandboxing using containers (à la Docker and so on) is quite good. The Mac sandbox model is probably ok for most normal users, but f…

Plus, Apple exempt their own apps from a bunch of these permissions (because it would be an unacceptable user experience for their customers)

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

#45

Post by dangus »

bombcar wrote: post #39
dangus wrote: post #37

The first thing I wondered after reading this article is whether there might be a scheduled task to run the permission reset similarly to how the author ran it via the command line. It seems most likely that this is some kind of bug where that command or its underlying actions should be called every time the user unchecks something in the settings panel. This is what we get when the iPhone’s permission system is graf…

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.

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

#46

Post by mh8h »

layer8 wrote: post #42
mh8h wrote: post #35

Earlier quoted context omitted.

That's not what's happening here. Forget about the first 5 steps. If you install the app and start from step 6, the behaviour will be the same. If the user chooses the Documents folder in the browse window in an app, the app can use the contents of the Documents folder without the need for that permission in the Settings page. The Privacy settings applies only to access to the Documents folder without the user intera…

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 settings page as well, and have a way to revoke it.

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

#47

Post by jjtech »

jasonjei wrote: post #7

The problem with Mac’s sandbox system is that it’s giving me some PTSD of Windows UAC. It’s inventing a solution to a problem that might exist in small doses, but instead gives users permission fatigue. I personally think the traditional *nix model has served us quite well, and elective sandboxing using containers (à la Docker and so on) is quite good. The Mac sandbox model is probably ok for most normal users, but f…

Note that this isn't "Mac's sandbox system", it's TCC. That's an important distinction to make, because apps that have opted into the proper App Sandbox can't do this... they don't even have the ability to display a prompt for direct access to Documents/.

With the App Sandbox, sandbox extensions are issues whenever you open a file using the file picker. They only last until the app is restarted.

A caveat is that you can save "Security Scoped bookmarks" (basically a signed base64 blob [1]) and pass that around to preserve access, but that isn't very common.

[1] https://www.mothersruin.com/software/Archaeology/reverse/boo...

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

#49

Post by mixmastamyk »

layer8 wrote: post #17
Angostura wrote: post #12

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

Yes, you need to read more carefully. In particular: “8. Confirm that Documents access for Insent is still disabled in Files & Folders. “9. Whatever you do now, the app retains full access to Documents, no matter what is shown or set in Files & Folders.” […] “Access restrictions shown in Privacy & Security settings, specifically those to protected locations in Files & Folders, aren’t an accurate or trustworthy reflec…

Screen time is swiss cheese as well, not surprised.

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

#50

Post by sillyfluke »

eviks wrote: post #36

That's the beauty of using a GUI-first operating system! > only way you can protect your Documents folder from access by Insent is to run the following command in Terminal: tccutil reset All co.eclecticlight.Insent then restart your Mac

Speaking of GUI weirdness, I've seen a couple of relatively newer macbooks do this thing where the laptop is shutdown with wifi disabled, but after login on startup the wifi icon displays the wifi scanning mode as if the wifi is enabled and looking for networks before reverting to the wifi disabled display icon.

Is this a GUI bug or is the wifi disabled setting overrided for a split second on startup? I haven't looked into it, but the latter would be extremely concerning.

Post reply on HN