Can you trust that permission pop-up on macOS?
nmgycombinator | 377 points | 16day ago | wts.dev
xp84|16day ago
On 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 try dragging it out of the browser viewport or switching tabs to see if it is fake or real.
The only protection against this kind of stuff is to NOT teach users that legitimate software pops up random "enter your password" dialogs in front of your work without any prompting. That's what these dialogs are doing.
Display a colorful flashing icon in the menu bar. Use an interstitial secure screen like Windows does. Whatever. But the modern macOS 'security' UI is wildly bad.
whartung|16day ago
The thing I hate about these things is I have no idea why they’re asking this, and no idea what happens if I say No, even how to “manage” these settings should I wish to change it.
The UX is different from the apps saying “Hey, open the preferences panel and give us XXX” and there you can see the app, the capability toggle, decide to turn it on, or even go back to turn it back off.
These experiences have been why I’ve not a big fan of “capabilities” as a concept. The UX around them is awful, and almost has to be.
“Enable <root my computer> to enjoy your new app fully. “ This is what you get if the vendors have any say in what the messages should be.
Not really helpful.
josephg|16day ago
> These experiences have been why I’ve not a big fan of “capabilities” as a concept. The UX around them is awful, and almost has to be.
I don't think the UX has to be awful. The problem is just that they're kinda half baked on macos, and bolted on, and not really a first class citizen. There's no reason you couldn't have:
- A preferences dialog showing which long-lived capabilities you've granted to which application. (Which is almost exactly what the accessibility preferences pane already is.) Ideally this UI could have a log of ways in which the application has used that capability recently and the ability to revoke it. Maybe even the ability to review the app's use of the capability. Show the review score to other users when the app asks for the permission.
- A little blob of text saying why the application is asking for the specified permission. iOS requires this from all 3rd party apps. So its kinda weird that MacOS is missing explanatory text entirely on these popups.
- Clear indication of what would happen if you said no.
- Interdiction. In a good capability systems (eg SeL4), a capability object doesn't tell you what you can do with it. Eg, you can't ask a file handle which file its actually associated with. This means you can craft your own "virtual" capability which fakes the expected behaviour and pass that to an app instead. Any calls made using the capability come to you. Whenever phone apps ask for access to my contact address book, I'd love to be able to say yes, but give them access to like 100mb of fake entries instead.
- And on top of interdiction: logging, call whitelisting, "Little snitch", etc.
- More fine grained capabilities. I don't want to give any app a "root my computer" capability. I don't want that to be a thing applications ever need or get access to.
I think macos's problem is that its trying to bolt on capabilities after the fact. POSIX isn't built around capabilities. As a result, app developers don't think in terms of capabilities, and they expect their apps (new and old) to work without them. In a real capability based OS, fopen() should probably take a capability as a parameter. But making that change would require changing just about every program ever written for the platform. And modifying the standard library of all programming languages.
nmgycombinator|16day ago
As someone who's looked into the internals of macOS for a bit now, this is all incredibly fascinating. However, I am curious: do you think capabilities could be implemented like this at a really low level? Part of me thinks we have the security models we do in POSIX is because they're simple enough to represent in C code.
The capability systems you're mentioning sound cool, but they sound a lot more complex. And if that's true, and they aren't built with irreducible complexity, then it would be possible to work around it by just pulling out bits and pieces from the system and abusing them.
josephg|16day ago
SeL4 is a capability based operating system toolkit, entirely implemented in C. The core operating system is just a few thousand lines of code. Its even mathematically proven to be bug free - which is totally insane.
It even uses a capability to allocate (assign) memory. So you typically have a microservice (userland process) in charge of memory on the whole system. Other processes get heap memory allocated to them by asking that service for it. (Though typically you'll allocate large blocks, and divide it up using a normal allocator).
nmgycombinator|15day ago
I think Apple uses an L4 variant for their SEP co-processor, though I'm not sure if it's that specific one. Sounds like another OS I'll probably have to do a deep dive into at some point.
SSLy|15day ago
They also run L4 variants below and besides XNU, on same cores as the rest https://randomaugustine.medium.com/on-apple-exclaves-d683a2c...
nmgycombinator|15day ago
Ooh! Thanks for the links!
ryukafalz|16day ago
Capabilities themselves can certainly be implemented at a very low level; you might implement them as an array of capabilities associated with each process: https://en.wikipedia.org/wiki/C-list_%28computer_security%29
As that page points out, POSIX file descriptors are effectively c-lists. A capability operating system would use similar mechanisms to control access to resources other than just open files.
The other things GP mentioned (logging, interdiction, UIs for visibility/control, etc) are layers that you would implement on top of the lowest-level capability system.
FuriouslyAdrift|15day ago
The Plessey 250 was a great one... https://en.wikipedia.org/wiki/Plessey_System_250
ryukafalz|15day ago
Ah, thanks for the reference! Yes, there are a lot of very old capability systems in computing history.
I've got a copy of Capability-Based Computer Systems on my shelf that I've been meaning to read for a while, and it covers the Plessey System 250: https://homes.cs.washington.edu/~levy/capabook/
Very much not a new concept! Though note that this book was published in 1984 and there have been several newer developments in the capability literature since then. (Revocation for example, which is mentioned as an issue in chapter 10 but has since been addressed with some capability design patterns.)
nmgycombinator|16day ago
Oh nice! I'll take a look at these.
saagarjha|15day ago
Capability systems are often simpler. The issue is that a lot of Mac software expects POSIX so moving away from that would break a lot of things.
mike_hearn|15day ago
macOS already has the first UI. It's not just for accessibility, the Privacy & Security pane lists permissions in depth.
macOS doesn't show explanations because apps can come from outside the App Store meaning nobody is checking that the explanation is actually true, but users would reasonably assume someone has checked it.
Ditto for the explanation of what happens if you say no.
Fake entries would just be a very weird user experience if the user accidentally denied access, would freak people out, and be very un-Apple like.
macOS already has very fine grained capabilities. That's what the Privacy & Security pane shows you. In fact, on macOS every app is sandboxed out of the gate regardless of whether they opt in or not, and root is disempowered. This is better than other operating systems.
Der_Einzige|15day ago
Why do damage control for free for tech companies when you can get paid to save lives with your damage control skills in somewhere like the navy?
More seriously, I will never surrender to this stupid idea that "the app store" or "walled gardens" are good. They are not and simply being on the app store is not a signal of trust for anything at all.
mike_hearn|15day ago
I didn't argue they were good or bad, only that it allows Apple to verify things.
Actually macOS does use these explanations sometimes. Calendar access is one. Anything where the rationale can be intuitively checked seems to OK to use them.
Groxx|16day ago
Capabilities are what lets you open a file picker from an app that cannot read your files, giving you a seamless and secure interaction with no extra UI.
They are definitely not always awful.
spoonsort|15day ago
Yes, this is the whole issue with these kinds of systems. The message gets lost in translation to the user. An OG java applet would say "this app is signed, do you want to continue", and the engineer at the bottom is the only one that knows what that even really means, which is that the applet gets to run outside the sandbox if the user runs it. Windows UAC is similar, as are most Linux desktop security mechanisms.
pornel|16day ago
My non-techie relatives can't tell the difference between the local device password/passphrase and the iCloud/Apple ID password, so they'll enter them all until something works (I don't blame them, the UIs for these are unclear and inconsistent).
Apple used to make fun of Vista's UAC, but they've ended up with the same patchwork of sudden prompts, and even weaker UI.
nmgycombinator|16day ago
Yeah, to be perfectly honest, I understand. I think TCC is meant to be the primary consent system, but there are others (such as the Authorization system, and the Service Management framework).
dpacmittal|16day ago
This. Moved from Linux to Mac recently and I was so confused about the random root password pop-ups. It gives no explanation on which app or command is asking for root access or why it needs root access. So I started denying the request after granting access a few times. Now I don't get that pop-up anymore. I still have no idea what was causing those pop-ups and why they stopped
ronnieboy493|15day ago
If macOS still attached modals to windows I think this might be less of an issue [0]. Not fixed, but less bad. In the previous screenshot, the modal lays over the toolbar which really reads as "part of the application". Steve Jobs, when demoing Aqua, made a point of the pain that is detached modals[1].
But here we are, detached modals, because of Apple's weird fetish for mobile UI on everything.
---
[0] https://kagi.com/proxy/latest?c=LsHiRSPxhD29sXqLhdI0j1EsQ98n...
[1] https://youtu.be/6-fkYFV7rOY?t=242
LexGray|15day ago
I think Apple took a step in this direction when they started forcing you to navigate to Security & Privacy to enable the modal the first time when launching an untrusted app.
They could probably add an opt-out step two for consumer level use where that step is also required for all root permissions requests. I would add a fast blink of the webcam light to prove trusted modal is open.
Currently it is incredibly clunky (they should put a notification at the top of the settings like for software updates), but you have some indication what app is triggering it and the dialogue could be hidden until it is time to review updates. Showing all entitlements and privacy settings should also be required any time a root password is requested with changes being noted as unusual, including changes in developer accounts.
nmgycombinator|15day ago
Damn, that really puts things into perspective. Granted, attached modals presuppose there's a window to attach to. But I think that would probably be true 9 times out of 10.
bobbylarrybobby|15day ago
Even if not, attaching to the menu bar (with some “chrome” that goes above the menu bar itself, which normal windows don't (can't?) do) would be superior to attaching to nothing.
saagarjha|15day ago
This is pretty straightforward for a malicious application to simulate.
nothrabannosir|15day ago
I think parent commenter was solving the attack vector of a website showing a password modal to look like it just happens to float over the browser. By conditioning users that a password modal is always attached to the gui of the application requesting it, the hope is that a password modal on a browser window would raise suspicion with the user.
I think that was the idea, at least.
yencabulator|16day ago
Seems like it's time to re-post this golden oldie: The Line of Death https://textslashplain.com/2017/01/14/the-line-of-death/
WA|15day ago
Thanks for posting. I’ve had this vividly in my mind for years, but didn’t remember the source. Makes so much sense.
walrus01|15day ago
To give an example of how little thought the non technical user pays to scary pop ups and warnings, people running MacOS and Chrome will regularly fall for full blue screen "your computer has been locked by windows, call Microsoft support at this phone number to unlock". It doesn't even enter into their minds that they're not running a windows computer before they even contemplate that it's just scam content presented in a full screen browser window.
musicale|16day ago
The passkey pop-ups which are indistinguishable from javascript pop-ups are a particularly egregious security mistake.
sureIy|16day ago
What's the problem here? Javascript popups can't read your fingerprint so what would be the endgame of a fake passkey popup?
BetaMechazawa|15day ago
timeout after 10 seconds "fingerprint can't be read, please enter password"
Klonoar|15day ago
They’re saying they shouldn’t look similar because it conveys authority otherwise.
aranchelk|16day ago
I really appreciate the integrated fingerprint reader in these cases. I usually run with my laptop screen closed (with external monitor) but open it specifically to authenticate in system dialogs.
aequitas|16day ago
Apple also sells a wireless keyboard with touchid integrated. Works great. Especially if you also set pam to use touchid for sudo. They’re not cheap though.
nmgycombinator|16day ago
Hijacking this current top comment to let everyone know there is an important update to this article: https://news.ycombinator.com/item?id=43969087
jclardy|15day ago
They should really make it open as a dialog attached to the system preferences window, and within that include what app/service is requesting permissions. Having the free floating window isn’t good for anyone, and duplicating the settings app would at least make it slightly more difficult to fake.
phendrenad2|16day ago
Plot twist: That dialog never existed! You already fell for it!
matthewfcarlson|16day ago
What is the threat model of clicking on a fake popup? Isn't it a no-op because it isn't actually coming from the system?
matthewfcarlson|16day ago
Just realized that it asked for your system password if you don't have Touch ID.
jeroenhd|15day ago
Having Touch ID does not immediately make all password popups disappear. I think it may be because of MDM/security settings my company puts on my work macbook, but now I get the joy of password prompts that sometimes work with Touch ID and other times demand a password.
I prefer UAC over whatever the hell Apple is doing. I've had days where I close my applications after a day of work and find two or three password prompts just hovering in the background. Were they important? Should I still permit them? Who knows!
ziml77|15day ago
Nothing with MDM, it's just what happens with those. I have no idea why it happens but I suspect in some cases it's badly coded apps directly asking for creds rather letting the OS do it. Whatever the reason for it is though, it's very annoying and pretty sketchy.
xp84|16day ago
The ones I get on my work MacBook Pro (which has Touch ID, which I use many times a day to do 1Password) ask me for my account password. No idea why. Also they never explain why.
deafpolygon|14day ago
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.
ssd646|16day ago
When logging into iCloud, they show a pop-up asking for the local password to the computer. And then they upload that password to the iCloud servers.
DowsingSpoon|16day ago
Please provide evidence for a claim that logging into iCloud necessarily sends your plaintext local password to the server.
ssd646|16day ago
I never said it sends your plaintext password.
It says it 'encrypts' your password, because it needs to access your Keychain. The dialog says this, but there is no way to opt out.
You are 100% wrong.
EDIT: https://apple.stackexchange.com/questions/467137/are-keychai...
nmgycombinator|16day ago
As someone who dove deep into keychain items for a previous write-up, I believe you are misunderstanding this situation. As far as I understand it, many keychain items can be stored in your iCloud keychain. However, your local machine can have its own keychain that's different than the iCloud keychain, with items that are not sent to iCloud.
And besides all that, to my knowledge your local machine password (the password you use to login) isn't stored in a keychain item, so there's no way it could make itself into the iCloud keychain, or your local keychain.
You may be mistaking some explanations. Your computer password is used to unlock your local keychain, but it itself is not stored in your keychain. Your local keychain is also not your iCloud keychain, it's not stored in iCloud.
Again, I'm not an Apple developer, so there may be stuff I don't know, but I am a developer in general and I have researched this. The above is my current understanding.
traceroute66|15day ago
> many keychain items can be stored in your iCloud keychain. However, your local machine can have its own keychain
Yes. That's pretty obvious to anyone who opens Keychain Access.
On the left you will see the following under "default keychains" :
- login
- iCloud
Yes. That's a fundamental, and again obvious requirement. Your keychain has to be encrypted somehow, and this is (IIRC) derived from your user password.
Software developers can further secure keychain by using enclave tied keychain entries[1].
[1] https://developer.apple.com/documentation/security/protectin...
cypherpunks01|16day ago
Just recently learned I should be installing mac apps into my home directory Applications, not the system Applications (as every single app installer suggests). Of course, only makes sense for a single-user machine.
If I downgrade myself to a non-admin user, and install apps into my home Applications, then I'm not bothered by permissions requests from apps to update themselves. Almost all of them can just do it, on their own, with non-admin permissions. The only exceptions I've found are Tailscale and other stuff that needs higher level OS integration.
Edit since upvotes: Non-admin user operation was recommended by the Pareto Security app, see info on this specific item: https://paretosecurity.com/mac/checks/not-using-admin
All Pareto security checks: https://paretosecurity.com/mac/checks
App: https://paretosecurity.com/mac and https://github.com/paretoSecurity/pareto-mac
Etheryte|16day ago
Unfortunately many (most?) application developers don't know this either, and many of them go so far as to explicitly require their apps to be installed in /Applications, they simply won't work otherwise.
Klonoar|15day ago
Apple themselves have a quirk in some cases where apps that aren’t in an Applications folder get mounted as read-only.
Granted I haven’t seen the bug in awhile, but I also never saw acknowledgement of it being fixed so…
mike_hearn|15day ago
That's not a bug, it's a security feature (hack?) called translocation. It happens if you run an app that was downloaded without moving it first using the Finder.
Klonoar|15day ago
I know what the feature is called.
I would not consider something so confusing to the end user to be a security feature. This is a bug, or you could use the label "broken".
xp84|16day ago
No comment on the overall topic, but I have long made a practice of installing into $HOME/Applications instead[1], and it's rare for me to encounter software that cares. A few apps have added popups to explain to beginners "Hey, you're running me from the Downloads folder, uhh, want me to properly move myself to /Applications/?" but that's about it.
The only apps I run from /Applications that aren't part of the OS are the ones that still use "Installers" like Adobe apps, because I assume they spew crap all over anyway. I haven't tried moving those, but I wouldn't be surprised if they deeply cared.
[1] The idea being that I could then migrate more easily by copying the whole home directory, and thus all my apps that didn't require "installation" would come over.
nmgycombinator|16day ago
> The idea being that I could then migrate more easily by copying the whole home directory, and thus all my apps that didn't require "installation" would come over.
Unrelated, but this is what I find so interesting and cool about the drag-and-drop to install method prevalent on macOS. People complain, but what I guess they don't realize is that all they're doing is moving a folder into their `Applications` folder and that the "wizard" way they're used to is far messier.
Granted, since I think it's up to the developers, they often seem to make the user drag and drop into the root `Applications` folder.
manwe150|16day ago
That’s fine, but also just means the “real” installer just runs on first launch instead in those cases, whether that is to ask for permissions or setup launch scripts or copy files to more places
But just think about how much fun phone apps could have been if you first installed an installer and than than that downloaded an app to install the side components before launching a configuration program for installing that specific software suite
Kwpolska|15day ago
The problem with the macOS "just drag it to Applications" approach is the uninstall. Deleting the folder will not delete user data (what if it's damaged?), and it won't delete any system stuff the app created on the first run. A typical Windows installer is likely to do the former and will definitely do the latter.
nmgycombinator|15day ago
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.
Kwpolska|15day ago
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...
xp84|12day ago
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.
jen729w|16day ago
Just so you know, there is something about dragging that app bundle to /Applications that causes something to happen. Because if you `mv` it in the terminal, the app often doesn't work.
It's been a while since I did this, and I can't remember the details. Sorry. Someone else might.
tonyedgecombe|15day ago
There is a bit of magic going on in Finder with /Applications. It’s actually two folders, one in the system partition which you can’t write into and one in the data partition where anything you install goes.
SSLy|15day ago
There are three of them, two you've mentioned, and ~/Applications for each graphical user too.
xp84|12day ago
Sadly though macOS never has and still doesn't do any magic for ~/Applications, such as showing your apps mixed in with the rest just by looking at "Applications." But yes, it does mix in the locked system apps such as Settings and Photos with the ones you have dropped into /Applications as though they're all in /Applications as they once were. I usually just add both folders to the sidebar, and forget which is which daily.
egypturnash|16day ago
All my Adobe apps are fine running from /Applications/gfx; I've never tried putting them into ~/Applications. They do also dump a bunch of stuff elsewhere.
mulmen|16day ago
Now imagine that home directory was on your iPhone and you could plug it in to any Mac anywhere you went!
hoherd|16day ago
Or on your iPod. https://forums.appleinsider.com/discussion/36380/home-direct...
xp84|16day ago
Now, that’s heresy! :D
(Although you could get closer to that with an iPod back in the day! Lots of my fellow Apple Store employees kept a lot of apps and things on their iPods!)
throwaway290|15day ago
If you install an app in ~/Applications, it can auto update without root, but any sus code can overwrite it without root rights too
mike_hearn|15day ago
Nope, that was fixed several releases back. macOS doesn't use the concept of a root user for years. It's there in the APIs for backwards compatibility but the actual enforced permission model is nothing like UNIX.
1. Apps can't tamper with each others files. Try writing an app that writes to another app's bundle, even if it's in $HOME, and you'll find you can't. One way to test this quickly is to ensure that your terminal app doesn't have "Manage applications" privilege in the settings app, restart it, then use vim to open a file in a bundle that appears to have user write permissions. You'll find it is read only.
2. root can't make arbitrary changes to the system unless you disable SIP (requires messing around in recovery mode terminals).
throwaway290|15day ago
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 some stock apps, some top level /bin and the like, but everything else is fair game for root. Which is a lot. If you use MacPorts then all of that is under sudo
mike_hearn|15day ago
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.
throwaway290|14day ago
> 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.
mike_hearn|14day ago
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.
throwaway290|13day ago
> 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
pbhjpbhj|15day ago
Which is madly insecure, right?
throwaway290|15day ago
I think so, somebody correct me if I'm wrong. Maybe if SIP is on and untrusted software is disabled then it would be caught, but if you have xcode then sus code can also probably sign whatever it created.
/Applications seems defense in depth for developer machines that often run untrusted code. Apps ask for admin to update & then I can deny it and go check the official site and stuff for download later
traceroute66|15day ago
> as every single app installer suggests
Not every single app installer, only those app installers written by incompetent devs.
Those written by educated devlopers give you the option to install "for all users" or "just me" (or words to that effect).
stefandesu|15day ago
I knew that ~/Applications exists, but never really used it until I started at my new job where I didn’t have admin permissions by default. Now I’ve configured Homebrew to install casks into ~/Applications and it works for almost all applications.
nyanpasu64|16day ago
I don't even have a ~/Applications on macOS 15.4.1.
p_ing|16day ago
You need to manually create it.
mschnell|16day ago
In the Finder it is translated to your system language. For example, „Programme“ in German. It is still Applications in the terminal.
nmgycombinator|16day ago
Fascinating! Personally, I need an admin account in my daily work, so I wouldn't do this, but for those it could help it definitely looks interesting.
mulmen|16day ago
You can still choose to install apps to ~/Applications if you are an admin.
nmgycombinator|16day ago
I'll definitely start considering it.
HnUser12|15day ago
Oh interesting, thank you! I wonder doing this will fix the issue where slack repeatedly asks admin password for updating.