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.
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.
> 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.
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.
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).
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.
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.
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.)
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.
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.
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.
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.
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.
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.
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).
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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!
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.
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.
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.
> 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
> Your computer password is used to unlock your local keychain, but it itself is not stored in your keychain.
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].
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.