[dead]
Can you trust that permission pop-up on macOS?
251–260 of 261 posts
Re: Can you trust that permission pop-up on macOS?
#252Earlier quoted context omitted.
I think you are wrong about Unix model only existing for compatibility 1. OK, so it requires terminal to have some entitlement first I guess. If you needed to grep some app's bundle in the past you probably gave it already. 2. many apps ask for admin user/password when updating. including say Docker. some developer software specifically says "we ask you this because we need to sudo" stuff under SIP I think includes s…
Grepping is always allowed because it's read only. Yes some dev tools like Docker ask for admin passwords, but that's not typical of most Mac users experience. Root still exists, but outside of software originally built for Linux or some odd edge cases, you won't encounter it.
> Grepping is always allowed because it's read only.
This is false on multiple levels. For a fact it is absolutely NOT "always allowed". If you ever ran a find or ls that goes into dirs like Downloads or Documents for the first time you would know you always get a prompt. But once it IS allowed, you can write there.
You're right that there is protection and verification of some signed app bundles, and I was wrong to say you can easily edit apps. For most apps even if you can edit them macos should raise a stink and say the app is damaged IF SIP is enabled and macos checks the signatures.
But I don't know if it works if the app is modified before first launch and launched without Internet because this is verified through Apple notary servers. Also I wrote files and modify plist in some signed Tauri/Deno app and spctl did show a warning but macos didn't care and launched it without any alerts.
And anyway if you have xcode set up some sus code can also sign whatever they write and good luck then;)
TL;DR as I wrote in another comment using ~/Applications is not totally insecure with SIP and all but still less secure.
This comment was edited, my original comment was too dismissive and wrong.
Re: Can you trust that permission pop-up on macOS?
#253Re: Can you trust that permission pop-up on macOS?
#254On the off-chance someone at Apple reads this, I'll repeat my perennial beg that Apple stops popping up 'Give me your (local admin) password right now' dialogs randomly throughout the day because the computer has a hankering to install updates or something. Anyone with basic skills can whip up a convincing replica of that popup on the Web, and the "bottom 80%" (at least) of users in technical savvy would not think to…
This is why I've trained myself to ignore these dialogs if I did not perform any action that would then prompt it. It doesn't eliminate the risk but it rules out 80% of the low hanging fruit.
Re: Can you trust that permission pop-up on macOS?
#255Earlier quoted context omitted.
I find Linux even more annoying when it requires elevation. I get a password prompt rather than a yes/no dialog. I don't care about defending against an attack where I left my computer unlocked while I wasn't watching it, so the password request is pointless. The only thing I need to see is that I'm elevating something and the only extra security I want is that, like on Windows, it's impossible for an application to…
You can just make sudo not require a password... You'll never see any prompt again then.
But I want a yes/no prompt. Otherwise anything can request root access and get it without my input. Again, Windows handles this about as well as any system without granular permissions based access control can. A prompt comes up which is presented on the secure desktop, thus necessitating manual intervention but only requiring a single click since the secure desktop is only able to be interacted with by SYSTEM level processes anyway.
Re: Can you trust that permission pop-up on macOS?
#256An important correction, so hopefully this bubbles to the top (this will be appearing on the post as well): A previous version of this article mentioned below that this CVE was patched in macOS Sequoia 15.5 et al., but I was a bit mistaken in that. Despite being released today as well, it appears that macOS Ventura 13.7.6 and macOS Sonoma 14.7.6 are not patched against this vulnerability. I wrote that sentence assumi…
Edit made: Ventura and Sonoma will remain vulnerable. Apple made the decision to only patch this in Sequoia.
Re: Can you trust that permission pop-up on macOS?
#257Earlier quoted context omitted.
Grepping is always allowed because it's read only. Yes some dev tools like Docker ask for admin passwords, but that's not typical of most Mac users experience. Root still exists, but outside of software originally built for Linux or some odd edge cases, you won't encounter it.
> Grepping is always allowed because it's read only. This is false on multiple levels. For a fact it is absolutely NOT "always allowed". If you ever ran a find or ls that goes into dirs like Downloads or Documents for the first time you would know you always get a prompt. But once it IS allowed, you can write there. You're right that there is protection and verification of some signed app bundles, and I was wrong to…
It's not (entirely) signature based. Try editing Chrome's Info.plist. If you can do it your terminal or editor probably has app management or full disk access permissions. Note that signatures are only checked on native code binaries every time. For data files and bundle structure, it's only checked once the first time the app is run. The signature is checked even without internet access, and normally notarization can be checked too via stapling.
Re: Can you trust that permission pop-up on macOS?
#258Earlier quoted context omitted.
> Grepping is always allowed because it's read only. This is false on multiple levels. For a fact it is absolutely NOT "always allowed". If you ever ran a find or ls that goes into dirs like Downloads or Documents for the first time you would know you always get a prompt. But once it IS allowed, you can write there. You're right that there is protection and verification of some signed app bundles, and I was wrong to…
It's not (entirely) signature based. Try editing Chrome's Info.plist. If you can do it your terminal or editor probably has app management or full disk access permissions. Note that signatures are only checked on native code binaries every time. For data files and bundle structure, it's only checked once the first time the app is run. The signature is checked even without internet access, and normally notarization ca…
> Try editing Chrome's Info.plist. If you can do it your terminal or editor probably has app management or full disk access permissions
I can edit plists for a bunch of signed and popular apps but MOST of them would be "damaged" on next launch. However a Tauri template app was launched.
and malware doesn't need to modify apps. Just rm an app and put a modified version instead. You can do this in ~/Applications without sudo or app management permissions
Re: Can you trust that permission pop-up on macOS?
#259[dead]
Re: Can you trust that permission pop-up on macOS?
#260Earlier quoted context omitted.
I do agree that uninstallation can be hard on macOS. I think Apple just envisions a future where every app is self-contained and putting the app in the trash really does remove everything because it was all in there. Maybe that's not realistic, though. I still think there's something to be said about an installation/uninstallation process that relies purely on moving files around, no custom script execution.
The "drag it to Applications, move to Trash to remove" flow was invented decades ago, possibly even back in NeXTStep [0]. Application bundles are not meant to be writeable, user data cannot be written there. If Apple envisions a future change, they’re really terrible in implementing it. [0] https://www.nextcomputers.org/files/manuals/nd/Concepts/Inst...
I suspect Apple has little incentive to fix it since if an app stores a bunch of data in ~/Library/Application Support and then you Trash the app, then your 256GB SSD (still standard even on a 'professional' laptop, in 2025) is that much more filled, eventually prompting you to curse yourself for not spending $400 in nearly-pure-profit to upgrade that to 1TB.