Posted by zdw 4 hours ago
“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 reflection of those that are actually applied. It’s possible for an app to have unrestricted access to one or more protected folders while its listing in Files & Folders shows it being blocked from access, or for it to have no entry at all in that list.”
It's because in step 6 the user explicitly selected the Documents folder.
The app can access the Documents folder because the user chose that directory in the native file browse dialog during the same run of the app. IMO that's a reasonable trade-off.
The Privacy settings applies only to access to the Documents folder without the user interaction.
I think it's reasonable to expect that an application gets access to a file you access through open/save, but the fact that the access to the directory and all the items in that directory persists after that isn't necessarily expected. Especially given that the near equivalent workflow on iOS doesn't behave like this and that's what a lot of users would probably expect. On iOS an app can ask for access to your photos, which you can allow, or limit to specific photos or deny. If you allow access to specific photos and then the photo selector appears, even if you chose an album, the app will only get and retain access to the specific individual photos you gave it access to. It can not read the contents or even the names of any of the other photos in your library.
It seems pretty reasonable to expect that if the "Documents" folder permission is turned off for an app on macOS and you have given the application access to a specific document inside your documents folder, that the application would not also get (and retain) access to read from all the other folders and files within your documents folder.
I agree that this is the default behavior of most desktop OSes (including macOS), but it's also something that seems reasonable for Apple to change given how important sandboxing is to them in general, and how important it is in the broader context of always connected computers with multitudes of arbitrarily networked applications running.
No, it is, the comment you're replying to is correct in what it said to you.
> The Privacy settings applies only to access to the Documents folder without the user interaction.
Yes, BUT, the user interaction is irrevocable. There are two user interactions here, one is "please access Documents this one time" and the second is "please don't let this app access Documents again."
Of course, if the stakes were higher you wouldn't even think to defend this behavior. Like if you were dealing with a nuclear weapon launcher and there was a big panel saying "TARGETING SYSTEMS: 0 targets (Permission Lock sandbox excluding 450 potential targets needing approval)" and then you poked around and found out "uh... why can I still go into the interface and target Milan and the big glowy 'launch missiles' light then starts lighting up and presumably I can launch a nuclear strike on Milan?!" and someone says, "oh yeah, that's because back when we were demoing it, the general had us punch in a random city to show what the targeting UI looked like, and we randomly chose Milan... it's okay, to fix it someone just needs to go and manually remove the warhead and put in a different one and then we'll restart the system and it'll forget all its targeting data for the old warhead" -- that'd strike you as unsustainable.
But this is very low-stakes for us so it seems less outrageous, but fundamentally it is a solid buggy behavior, "The UI makes it sound like there is only one system at play here, but there are actually two and the other system can override a specific revocation that's placed at the level the UI controls." Even if there are going to be two systems, you expect that their security controls will both be followed, or that the second one will know enough to be able to say "I say no, but I am being overruled" in its status panel.
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.
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 you _really_ want to you can see every dir that every app has ever accessed, but the vast majority of users don't care.[0]
I'm less caffeinated this morning though so maybe I misread the whole argument.
[0] edit: And whether the app still has access to that dir. Which maybe that was the point of the article. I am just skeptical generally of these kinds of exposés because while they're generally pretty fair, they'll inevitably get picked up by the geniuses on r/pcmasterrace who will spin it into "Apple Privacy and Security Settings Let Terrorists Invade Your Family Photos"
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.
Shouldn't a temporary access be temporary? Possibly scoped by time? Possibly scoped to a single access?
8. Confirm that Documents access for Insent is still disabled in Files & Folders.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
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.
But the proper api call to make is selecting a picture. Not access to the photo library. That is an api design flaw, and simply a bad / obsolete implementation by the app developer.
The complaint of the OP is that he can still open a file which is in the downloads folder. But that’s not what the user is doing.
There’s no reason to give folder access at all. (Except for file sorting apps etc).
The only “reason” would be that it’s more difficult for developers to atomically overwrite a file in the same locations. And quite frankly, they should (and perhaps already do) have api calls for exactly that. I think this is why many apps request access sometimes.
This behavior gets used all the time in things like opening a folder in your IDE so it can access the whole project.
The OS does allow file pickers that can only pick files and not directories (set canChooseDirectories = false), and if an app has no legitimate reason to need a directory they should do that, but the fact that you can grant permissions isn't the problem. What they need to fix is that you're granting permanent permissions with no indication that you've done it and no way to remove them.
To anyone at Apple reading this - please do not draw the conclusion "permissions to access a previously opened file or folder should expire after 24 hours" there are already more than enough permission prompts.
Is this part true? The article's fix involves running a command and rebooting the computer. If restarting the app was sufficient, surely you wouldn't need the command/reboot?
There's no privilege escalation here, but there is a misleading privacy settings UI, which offers no obvious way to audit/revoke permissions in the second case
- it's non-obvious that the second mechanism (a file picker) is a permission granting mechanism.
- it's non-obvious that the second mechanism (a file picker) is a permission granting mechanism whose permission survives the action context that triggered the file picker (e.g "pick a folder to do action A" also magically imbues similarly gated actions B C D and Z with access to that folder, possibly non-interactively even).
- it's non-obvious that the second mechanism (a file picker) is a permission granting mechanism whose permission propagates to an action gated by the first mechanism, a first mechanism for which "Yes" means yes but "No" means "Maybe, depending on past unrelated actions that triggered an unrelated permission mechanism"
This is a result of trying to retrofit a series of tighter security measures on top of a system that was not originally designed for them, in a way that is both understandable to users but also doesn't break back-compat with APIs (and therefore a lot of existing third-party apps that are seldom updated) too badly. I'm not saying Apple did a perfect job here, but it's a hard problem.
Yes, the problem could probably be "solved" by adding more UI, but "more UI" is not always a good solution. The more UI that exists, the less likely the user is to successfully navigate it. On the other hand, adding additional complexity to an existing UI is also fraught with potential for new bugs and edge cases. Again, not defending the status quo, but I can see how it might have ended up like this.
This is worth spending more time on trying to improve, and perhaps it is reasonable to expect better from an almost-$4tn company. But at the same time, a potential solution is far from easy or obvious, and there is a risk of making things worse if not done with an extreme level of thought and consideration.
(Alternate pessimistic take: A large number of users don't care or read anything, they just click "allow" on anything that gets in their way. A smaller set of users are terrified and disgusted by repeated invasions of the privacy and click "deny" on everything. None of these implementations are doing any good for either group. The allow/deny design pattern is badly broken and in need of rethinking.)
> In this Friday’s magic demonstration, I’m going to show how what you see in Privacy & Security settings can be misleading, when it tells you that an app doesn’t have access to a protected folder, but it really does.
And specifically they could show some code snippet to reveal what exactly the Insent app was doing. Was it calling startAccessingSecurityScopedResource of the NSURL class?
I could absolutely be missing something here, but the title would be accurate in saying, “MacOS ACLs aren’t terribly intuitive”. But I think the behavior they’re documenting is intended behavior.
“Word” would like to access the files in your “Documents” folder
“Terminal” would like to access the files in your “Downloads” folder.
Yes, because I am telling them to access the files.
All that remains is an algorithm to reliably determine which programs do "shady shit". How is it that you determine that Microsoft updates have not been tampered?
(insincere) apologies for the snarky tone. You are making light of a very hard problem and default deny until confirmed by the user isn't a bad first approximation.
you hand-audit every update for every program you run? can you share your workflow to do this?
otherwise, i am not sure how you can possibly guarantee that the programs you are running "dont do shady shit" (or, "wont do shady shit" in the future). there have been several compromises of non-shady programs and libraries in recent memory.
> 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
Even if you're not an Apple fan, these sorts of stories are kind of great for learning about product development and companies in general, I think. jwz's stories of Netscape are also phenomenal. (Just don't click on any HN links that go to jwz.org, or you'll have to clear cookies to see any content there in the future. He's not a fan of the exploitation that startups frequently do to their employees and views HN as a primary channel of promoting that exploitation.)
I had the privilege of working with John Carmack as a technology evangelist at Apple when he ported Quake III Arena to Rhapsody, Apple’s internal name for the OpenStep/Mach kernel based MacOS X. I enjoyed John's reminiscence about working with Steve and Apple and thought I would share a few of my own memories from that time which provided me with some of the most satisfying moments and lessons of my career.
John was the first game developer I ever worked with. Three weeks after I sent him development hardware (an iMac) he informed me that the PC and Mac versions of Quake III Arena were in “feature parity.” I still recall my shock upon reading that email from him.
John agreed to come to Cupertino and meet with several teams to share his development experiences with them. I picked him up in the lobby of the Fairmont Hotel in downtown San Jose. He stood unassumingly in the lobby, framed in the background by a Christmas Tree.
On day one, we met with several internal teams at Apple. I was accustomed to see 3rd party developers emerge somewhat awed by their meetings with Apple engineers. In John’s case the reaction was reversed. I’ve never seen anyone grok complex systems and architectures so quickly and thoroughly as John. Amusingly, he walked around the Apple campus unrecognized by all but for the occasional, former NeXT employee.
On Day 2, John was to meet with Steve. I never knew whether it was by design or not, but on that day John wore a T-shirt that featured a smiley face with a bullet hole in the forehead from which trickled a few drops of blood. After an hour of waiting for Steve in IL1, he marched into the room, and immediately mistook me for John Carmack, extending his hand to shake mine (we had never met). I locked eyes with Steve Jobs and looked down significantly at the Apple badge on my belt. Without missing a beat, Steve shifted his extended hand to John's.
That’s when Steve noticed the T-shirt and the meeting, as soon as it had begun, took a turn for the worse.
Steve’s jaw muscles visibly tensed and he became stone-faced. Clearly deeply offended by John’s T-shirt, he sat down at the conference table and looked straight ahead, silent.
John kicked off the meeting by saying, “So I’ve been working with MacOS for the past month and here’s what I learned.” His #1 concern (at an extremely high level) concerned OpenGL permissions and security for which he felt Apple needed a better solution than what he’d learned about the day before in meetings with the graphics team, even if it came at a slight cost in performance for 3D games. This was, suffice to say, typical of John in that he was approaching an issue from an objective engineering perspective and arguing for the most technically correct solution rather than pushing for something that might be of benefit to his personal projects.
Steve listened and abruptly said, “That’s not what we’re doing!” Then he looked at the three Apple employees in the room and asked, “Is it?” I confirmed that what John was raising as a concern came from a meeting with the graphics architecture team the day before. Without batting an eye, Steve stood up, tramped over to a Polycom phone and dialed from apparent memory the phone number of the engineering director whose admin informed Steve that he was at an offsite in Palo Alto. Steve hung up, sat down, and about 30 seconds later the phone rang with the engineering director on the line.
Steve said, “I’m here with a graphics developer. I want you to tell him everything we’re doing in MacOS X from a graphics architecture perspective.” Then he put his elbows on the table and adopted a prayer-like hand pose, listening to and weighing the arguments from his trusted director of engineering and from the game guy with the bloody smiley-face T-shirt. And what happened next was one of the most impressive things I’ve ever witnessed about Steve or any Silicon Valley exec. Early on in the discussion, the Apple engineer realized that “graphics engineer” in the room was John Carmack. And he realized that he was going to need to defend his technical decision, on the merits, in front of Steve. After extended back and forth, the Apple engineer said, “John, what you’re arguing for is the ideal …”
He never made it to the next word because Steve suddenly stood bolt upright, slamming both palms onto the desk and shouting, “NO!!!!”
“NO!!! What John is saying is NOT the ideal. What John is saying is what we have to do!!! Why are we doing this? Why are we going to all this trouble to build this ship when you’re putting a TORPEDO IN ITS HULL?!!!!”
All of this was said with the utmost conviction and at extremely high volume. To his credit, John, seated directly next to a yelling Steve Jobs, didn’t even flinch.
What was so impressive to me in that meeting was not the drama so much as it was that Steve Jobs made a decision on the merits to side with John on a technical issue rather than his longstanding and trusted graphics engineer. He overcame his original distaste for the T-shirt and made the right call. Most CEOs would have dismissed John’s comments or paid them lip service. Steve listened to both sides and made a call that would have long lasting implications for MacOS.
As a comical aftermath to the story, John next told Steve point blank that the iMac mouse “sucked.” Steve sighed and explained that “iMac was for first-time computer buyers and every study showed that if you put more than one button on the mouse, the users ended up staring at the mouse.” John sat expressionless for 2 seconds, then moved on to another topic without comment.
After the meeting ended, I walked John to the Apple store on campus (this was before there were actual Apple stores) and asked him on the way what he thought of Steve’s response to the mouse comment. John replied, “I wanted to ask him what would happen if you put more than one key on a keyboard. But I didn’t.”
Good call, John
> I was brought in to talk about the needs of games in general, but I made it my mission to get Apple to adopt OpenGL as their 3D graphics API. I had a lot of arguments with Steve.
https://old.reddit.com/r/Games/comments/8l9qw2/john_carmack_...
Sounds like a Watchmen Comedian logo t-shirt. It could be construed as a bold choice but was probably just what was on the top of his t-shirt stack that day.
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.
Simply go to Security and Privacy and turn the permission on then back off :)
What happens here is the UI displaying the permission state is buggy, but the permission actually works. It's just hard to see its state.
Buggy UI, modern Apple...
By the way there is another problem with that UI. The checkbox is blue when on and grey when off... but only when the window has focus. When the window is not focused it's grey in both cases. Different greys but still greys. And if you don't spend all day looking at checkboxes in Mac OS, you may forget if left or right is on.
And this is on Sequoia not <the low contrast update>.
Edit: I wonder if a reboot would also make security and privacy read the status properly. But it would ruin my uptime, so I'll let someone who has an OS update to install check :)
Edit 2: And I just noticed. I have a TB drive hanging off my Mac Mini and my games are on it. So there's a bunch of games in security and privacy (mostly crossover entries, but also for example euro truck simulator which is native) because they requested access to "removable volumes". No shit, they're installed on said removable volume.
But also, once they've explicitly granted access, and then implicitly granted access to the same folder, disabling explicit access changes nothing.
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 for power users is infuriating at times. Multiple restarts of Mac and various processes (and when you realize not enough scopes have been granted, another subsequent restart). I think Mac forcing all users into its sandbox system has been one of my least favorite impacts since upgrading macOS, leading to the enshittification of macOS.
The craziest thing is background processes started by Terminal/iTerm (such as tmux) can inherit Terminal or iTerm’s elevated status even when Terminal or iTerm are no longer running, dead, or killed. So you’ll have a bunch of elevated processes without the elevated parent or grandparent process running—it makes me feel the whole permissions scheme is more performative than actually useful.
The way macOS handles permissions with user prompts might be the wrong UX, but giving every program carte blanche by default is definitely not the answer either.
It’s dangerous, particularly for those of us who are developing and publishing software that’s used by many thousands of people — we’re juicy targets and every time we disable protections in the name of convenience and carelessly run random third party software with unfettered access we’re playing with fire. I find myself consistently stunned by the flippant attitude SWEs take towards securing their systems. Our confidence that we’re too smart to fall victim is entirely misplaced.
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...
I would say that TCC is working as intended, unfortunately, with many obscure behaviors to avoid breaking existing apps.
It's even more unfortunate that a lot of apps that could be easily sandboxed aren't.
I would like to be able to run arbitrary code with gradual/granular privilege escalation. (e.g iOS/android with more affordances and escape hatches. macOS is getting there, but it's been a pretty bumpy/potholed road). Right now if I download a random github repo, I'd put it in a docker container and give it ports/volumes/etc.
I feel like it should still be much easier, but the general sandboxing model seems directionally functional. (My understanding is containerization isn't a silver bullet security-wise, still requires fiddling, and would be a resource hog ram-wise if not CPU?)
I wish I could pick a parent folder/file and get a box to control everything (network/disk/folders/peripherals/accessibility).
It has the https://xkcd.com/1200/ problem on almost all end-user setups.
As a precaution would it be a good idea to run that reset command for all apps?
I go into "Privacy & Security", "Full Disk Access". A bunch of apps added themselves in there (Anki, Fission, Microsoft Autoupdate, WhatsApp), the toggle is disabled and I've never enabled it. Ok, whatever.
But when I go into "Files & Folders", and under those apps I see "Full Disk Access" in gray. Apps that have Full Disk Access toggled on look identical, with "Full Disk Access" in gray. What the hell am I supposed to make of that?
Is it a bug? Do they have full disk access? Is the UI trying to imply that those apps are solely controlled by the FullDisk toggle and are ineligible to request granular permissions for Desktop/Documents? Or that they are eligible, but haven't requested it? Or maybe they did request it, and I granted it, but I don't get to see it? Who knows?
It's really confusing that some of those settings can be toggled on/off, while the Full Disk Access is greyed out and can only be toggled under "Privacy & Security".
To add to the confusion, toggling FDA off just protects a few selected folders that Apple decided are extra sensitive, like:
Messages ~/Library/Messages
Safari browsing history ~/Library/Safari
Cookies ~/Library/Cookies
Identity services ~/Library/IdentityServices
Spotlight data ~/Library/Metadata/CoreSpotlight
Phone call history ~/Library/Application Support/CallHistoryDB
Facetime data ~/Library/Application Support/Facetime
TCC database ~/Library/Application Support/com.apple.TCC.db
"Normal" files and folders on your disk (including Desktop, Documents, Downloads, network volumes, and removable volumes) can always be accessed (even with FDA permission revoked!) after a simple prompt. [1][1] https://support.apple.com/guide/security/controlling-app-acc...