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.
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.
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.
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].
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.
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.
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.
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.
> 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.
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
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.
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.
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.
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.
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.
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.
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.
(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!)
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).
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
> 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.
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.
> 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
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
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.
An 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 assuming that Apple would have included a patch in all of the releases. It was only later, when I checked the security release notes, that I saw I was not credited under the other two releases. I reached out to Apple to clarify if these releases were patched. As of writing, I have not heard back.
I chose to do my own testing and spun up a virtual machine. After some difficulties I got it updated to macOS Sonoma 14.7.6 and was able to compile and run my proof of concept. It still worked. I would assume the same is true for macOS Ventura 13.7.6. I'm not sure why Apple didn't include the patch in these two releases.
I will update the post when I have more information and/or context.
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 automate clicking yes.
Last I checked there was no solution for this on Linux though. Heck I couldn't even find a way to switch it to use biometrics.
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.
At least Windows now makes the UAC dialog distinct from the rest of the OS and any other Window. macOS (and most linux DEs too) just look like any other application dialog, easily spoofed.
UAC on Windows opens up on the secure desktop, which is isolated in protected memory and not accessible to other processes. It's also visually distinct, hiding all other UI elements, and nothing else can present the actual secure desktop, only UAC can. Granted, I've seen some fairly convincing looking fake prompts (that regular users would fall for) but to me they were still obviously fake, and they were unable to hide all UI elements like UAC does.
The secure desktop for UAC is also supposed to help prevent cursor offsets and other attacks (replacing the system cursor with fake one that shows as if it's over the "no" button but is actually going to click on "yes").
macOS could really use something like that for it's prompts, and I don't know why any other OS hasn't implemented something like UAC's secure desktop.
The most important feature of the secure desktop is one that is rarely ever mentioned: you can hit CTRL+ALT+DELETE on a real UAC prompt. This is something similar Linux prompts lack (as Linux lacks a similar privileged shortcut sequence); GNOME has full-screen, top-level, UAC-like prompts for PolKit and sudo, but it's hard to figure out if it's real or a fullscreen application.
There are ways to avoid the CTRL+ALT+DELETE safeguard, but it's a lot harder than it is to spoof a password prompt that looks like the OS one. It's kind of unfortunate that KDE went with the macOS/Windows XP approach rather than doing what Windows does.
Every time I update an app I have to be told I downloaded it from the Internet and do I trust it. Can this app look on the local network?
Constantly being nagged to the point I don't even check/care anymore.
Exactly what Vista used to do.
This isn't what Vista "used to do". Vista had a single elevation popup dialog / shatter attack prevention screen. Any request that required elevation required this popup.
macOS has not only elevation requests but entitlements. Using the local network is an entitlement. What macOS gets very wrong is any denied entitlements will re-prompt next time you perform that action with the app, which may simply be starting the app. It also does one entitlement at a time, i.e. if you have an app that requires screen sharing and camera, you'll get the first entitlement, restart app, go to do action you wanted again, second entitlement.
Both OSes have MoTW, but Apple goes beyond with the notarization warning/block.
macOS users are going to suffer from prompt fatigue. And the /r/macos "secure cus UNIX!" will be wrong on two points.
Technically you're right. From an end-user standpoint, it's irrelevant. Apple's mock vista ad applies just as well to Ventura: they're all annoying and a security theater if the user is just told to input admin password into any random popup.
Quick clarification on terminology. From a developer perspective, entitlements a static dictionary (or a collection of key-value pairs) attached to the app at code-signing time. The entitlements you mentioned don't "entitle" the app to access resources, as user consent is still required.
FWIW, Vista's level of prompts is the only way to run UAC in any kind of secure fashion. The configuration that has been the default since Windows 7 makes it trivial for a low-privilege application to gain UAC privileges.
Microsoft doesn't regard UAC as a security boundary if you're logged in as an admin (https://learn.microsoft.com/en-us/previous-versions/tn-archi...). You can use UAC as one as part of a defence-in-depth approach by logging in as a non-administrator user (like everyone tells you to do but nobody wants to do) and entering a password for every prompt, but for that to work well you'd need to make sure to turn UAC prompts back to max (read: Vista level or worse). I don't think I'd set up a system like that without a fingerprint reader or Windows Hello facial recognition camera, because typing out the password that often is just a massive pain.
Windows, as configured by default, barely runs any downloaded files. You can pay hundreds of euros for a certificate, sign your installer, and still have users get told off by SmartScreen for daring to open an executable file. I don't think Apple's notarization has done anything useful so far, but their security prompts are a lot less scary than Windows'. I think it's a matter of time before unsigned Windows executables with the MotW simply won't open by default like those on macOS.
The local network popup thing is too overdone in my opinion. However, I do think it is a good choice (in some respects) for Apple to have the "this is a program downloaded from the Internet", even if it can be annoying. It might also be a push to get developers to publish on the App Store (where Apple can be more sure (hopefully) that the apps are safe).
It's a double-edged sword in my opinion. I think it's good that the OS is looking out for the user in a lot of cases. I also understand how it can give the users pop-up fatigue.
> It might also be a push to get developers to publish on the App Store (where Apple can be more sure (hopefully) that the apps are safe).
Apps on macOS need to be signed and notarised. Apple has the exact same capability to scan for malicious behaviour and revoke your keys regardless of how you publish. We all know the real reason they want to push apps towards the app store.
"This is a program downloaded from the internet" isn't a push to the app store. It predates the Mac App Store, iirc.
It's another quick security hack (as they often are in any OS). Many years ago someone noticed that apps can pick any icon they want. And, therefore, if you could convince a browser to download a file to ~/Downloads (not hard), the user might look inside and find what appears to be a harmless JPEG or Word document, double click it and are immediately pwnd because back then there was no app sandboxing of any kind, no SIP etc. macOS in that era was a conventional desktop UNIX.
So the quick hack - make apps that download things mark files with extended attributes, and if the Finder sees that, it pops up the warning and then removes them. Now the user realizes (maybe) that the document-looking-thing was actually an app.
That's a fair point. But did Mac have the same issue as Windows where file extensions were not shown by default? That feels like it would have been the core issue.
There is a "show all file name extensions" option in Finder, but I don't recall if it's on by default or not as I haven't had to set up a fresh macOS install in a while and I've always had it turned on.
But, macOS isn't like Windows - the file extension doesn't matter. I can have a "file.txt" but it's actually a .xlsx excel workbook, and Excel will open it just fine (albeit, with a warning that the file extension doesn't match but that's dependent on the application presenting a warning). Windows actually uses the file extension to determine the type, macOS (and other *nixes) don't, they'll use some other file metadata. You can put whatever extension you want on a file, it doesn't matter except for determining what default app will attempt to open it when double clicking it in Finder.
> It might also be a push to get developers to publish on the App Store (where Apple can be more sure (hopefully) that the apps are safe).
This is exploitation of developers, plain and simple. Apple should secure their runtime, not roleplay as a software rent-a-cop that manually (and fallibly) inspects submissions. The App Store is a blatant moneymaking racket, on mobile and desktop alike. "Security" is a fig leaf for the perverse incentive Apple has to corral developers under their thumb.
I think entitlements are the correct direction to move in. I don't like Apple's implementation. But it gives us that fine-grained control of what an app can and cannot do with things outside of the app's "bubble" (or sandbox). We need Discretionary Access Control.
And to NSO Group's delight, they don't review SMS messages or Safari contents either. The "curated security" shtick is a lie, it does not protect anyone and doesn't function reliably in the first place. Both targeted malware and generic scams are rampant and unrestrained on iOS. Many of them are promoted as iPhone Search Ads, or suggested Siri results.
The knock-on effects it has are even worse. By relying on this game of shuffling private entitlements around, Apple has less incentive to actually review what developers are doing with them. Look at the Uber iPhone app's screenrecord permissions, or when TikTok stole iOS clipboards.
Apple uses "secure" review as an excuse to not review apps or secure their runtime.
Apple's review sucks but you are very confused about your "takedown" of their security practices. It's not meant to protect against everything. Even well-made security boundaries can fail against sophisticated attackers, or be too onerous against generic malware.
Honestly, I think you have a fair point there. I personally don't believe that any system could be 100% secure. But I do think there is a point to be made on the efficacy of securing the runtime compared to individual app inspection.
In macOS 15, there is no GUI bypass. Right click -> Open no longer works. xattr is "the way". I'm sure someone has probably created an Automation or something for it.
There's a small section in System Settings that they don't really tell you about that pops up when the OS blocks a file from opening. You can then override the block there. Yes, it's extremely annoying.
> where Apple can be more sure (hopefully) that the apps are safe
Ha, they'd love to capture the 30% Apple tax on macOS too, I'm sure.
I don't think the mark-of-the-web feature is bad, but I am particularly annoyed that I have to open the system settings app to open an application.
Honestly, when I first tried modern macOS, I was surprised how bad the popups and warnings were. This is exactly what Apple (rightfully) made fun of when Vista came around. I've caught myself mindlessly approving prompts because there are so many of them and most of them don't make much sense at all ("do you want to allow iTerm access to your downloads" after I've explicitly dragged the thing to the special "developer tools" setting? what the heck?).
Slight tangent: Apple TV constantly has MLS (major league soccer) and Apple TV+ in the left-side pop up Home menu, taking up real-estate for something I will never access. So annoying.
Why, as someone from England — with arguably the best football league in the world — would I want to watch American Soccer? I don’t even watch the English league.
The menu is:
———————
* Search
* Home
* Apple TV+
* MLS
* Store
* Library
———————
Title: Channels & Apps
* This is where all the channels I have actually opted for live — separate from the Apple products that I don’t want
———————
Both Apple TV+ and MLS should not be on that menu permanently. And it should be possible to turn them off.
> Why, as someone from England — with arguably the best football league in the world — would I want to watch American Soccer? I don’t even watch the English league.
So you're the type that doesn't watch the Special Olympics I take it? MLS is the geriatric retirement league for super star players, or the not quite good enough to play in the other leagues league. One season, I tried to get into MLS. At one point I tried using a stop watch to clock how much time the ball was out of play in MLS compared to "real" leagues, and it was close to 20% which is not far away from amateur kids level of play.
I don't blame you for not liking the MLS branding. However, I'm guessing they paid a couple of shiny coins for that privilege, so they're naturally going to try to do anything to recoup that money
I don’t watch football at all. If it’s not cricket… well it ain’t cricket!
But even if it was a channel dedicated to test cricket (the greatest sport in the history of sport), I would still resent the foisting. These are clearly anti-competitive practices and that always leads to worse products eventually.
Speaking of installed-by-default, it's even more stupid that you can't even uninstall apps like Photos. Supposedly it's 'required for your Mac to function.' I'm sorry, I do not have a need for a photo library on a computer used exclusively to write software.
> Apple Music is just an advertisement by default and "conveniently" opens every sound file mimetype
Not only that, but you get the advertisement every time it starts and then it doesn't play the actual file. So unless you join the service the process is: try to open the audio file, close the advert, go back to source, open the file again.
Sometimes I consider looking switching back to MacOS (left because OS X 10.7 was becoming too much like iOS and I don't like the idea of apps having to be signed and/or in an app store) and holy shit I am glad I left.
I did Linux for a bit, but I was really impressed with Windows 10 once I disabled all the junk. Good window management, WSL is fantastic, I really like a few windows-specific utilities, and programs. I like having the Adobe suite + a nix env.
That being said, Windows 11 is making me consider jumping back to Linux, along with me being increasingly annoyed by Adobe.
For development work, I honestly prefer Windows. At least WSL knows what you want to do and gets out of the way. Comparatively, making a "correct" shell on MacOS often entails QEMU and local NAS, alt-tabbing between that and your native terminal for version control. Or you build your server software to be MacOS-native for debugging and port it to Linux later like a neanderthal.
Just... no. MacOS looks pretty but the workflow is uglier than Satan's taint. I don't get paid to work around Apple's dysfunction.
> iCloud nags never go away if you don't log into iCloud
I don't get people who buy macs and refuse to login to iCloud.
You don't have to use iCloud for storage or anything else, all that can be disabled in settings.
The biggest benefit of logging into iCloud is protection if your device gets stolen. It means the thiefs can't just wipe and resell your device. It means you can track and remote-wipe it in Find My.
I hear you, but 10y of MacOS usage habit will make that to you, it's easier for me to work around MacOS quirks and Apple's authoritarianism than it is to try and get a Linux distro I like to work perfectly for me for more than 6 months, or worse, go back to win
From the beginning, TCC has been a house of cards. It only impedes legitimate developers and tortures users with permission prompts that Apple ridiculed back in the day, while malicious apps can easily bypass the "security" (theater) in countless ways that researchers continue to uncover and report. I'm not a professional security researcher, just a Mac developer, but I've discovered a number of bypasses myself. It's almost as if Apple engineers don't even understand the technology they're using. And maybe they don't! How many remain from the pre-iPhone era?
The continuous incorporation of basic system features into TCC has drastically increased the friction of deploying enterprise management software on Macs (especially for education), to the point where I would question the overall value proposition.
I say this as a dedicated macOS (Cocoa) developer since 2003.
My work Mac regularly pops up an alert box claiming that Slack is “trying to install a new helper tool”. I have no idea why or what it means. I asked IT how I could verify it was legit and they didn’t know.
I often wonder if this could also be exploited because it asks for a password and it keeps popping back up every time I click cancel.
This dialog comes from the System Management framework [1]. Slack is probably installing a privileged helper tool (conceptually similar to a setuid root binary) so that it can update itself regardless of where it is installed or which user originally installed it.
Seems like it should only need to do this once. I get this with almost every Slack and VSCode update. The correct solution for me is to quit Slack.app and let my company's management software do the update for me.
Chances are they have some kind of management software like SentinelOne that is preventing Slack from doing this (or storing the permission to do so), so it just asks over and over. Which is arguably worse.
Discord does this as well I believe. I often needed to enter the administrator password to install a helper after the system had been off for a couple days.
A software updater was going to be my best guess at what this was. I guess I understand the flexibility it brings, but it definitely does have some security trade-offs.
I'm not aware of the "helper tool" popup, but I would definitely be skeptical of it. Even if it is Slack, Slack is just a messaging application. I don't know what legitimate need it would have for a helper tool. I would ask Slack support, though (and hopefully you can get a real answer and explanation).
I kinda like this angle. While Slack makes an effort to work basically everywhere with low effort, I wonder what would follow if it wasn't the case.
For instance if for some stupid legal reason Slack was banned from macos, how many people would just switch to another OS ? I'd bet it would be a non trivial amount of users at this point.
> I kinda like this angle. While Slack makes an effort to work basically everywhere with low effort, I wonder what would follow if it wasn't the case.
This idea of respecting user preference is not the way, though. For example, back when Skype existed, you couldn't remove its icon from the macOS menu bar, because (1) Microsoft didn't believe you had the right to choose to remove that item, and (2) macOS believes an app developer should have more control over what goes in my menu bar than I do.
In environments like this, my trusted colleagues and I communicated using Signal (and before that, WhatsApp).
One somewhat paranoid department that was convinced they were being spied on (they weren’t; I saw the Slack admin dashboard and management was too cheap to pay for the retention and spying features) maintained the use of an ancient Jabber based group chat for their own internal communications.
This was around 8 years ago, but there was no MDM installed on our cell phones, regardless of if BYOB or company paid for device.
The only restriction was if you went to China, you took a burner phone (one of the old company phones, usually) and weren’t supposed to ever use it again once you left. I think they just sold them to a liquidator.
I guess that's a fair point. It cuts both ways, but given that so many people use Slack as opposed to talking, the exact words people used and when are could be open to view. Whereas, before all of this, you may only just have the minutes of any official meetings. Any side chatter not in the meeting room and/or exact phrasings would be lost to time.
That does sound like it could be exploited, but with only as much exploitability as some random app that requires your password (for analogy consider a Linux binary that refuses to run unless being run as root). Ultimately it's a matter of deciding whether you trust the developer of the app and whether you trust this app is really from that developer. The day Apple prevents users from giving root access to a third-app app is when the Mac fully becomes a walled garden, and you can expect pages of HN complaints.
Overall I think it's good paranoia to not grant root permissions to apps that do not clearly need them such as Slack.
Being paranoid, would it be possible that another app already installed (but not trusted enough to give privilege, let’s say a shady mouse driver or screenshot app) detect when slack (more trustfully) does launch to open a dialog at that precise time and deceive the user? Let’s say the shady app is named « SIack » or something close enough to be missed - but brand itself as innocents « screenshotPro4000 » in the app itself graphics so you’re not suspicious.
> The day Apple prevents users from giving sudo access to a third-app app is when the Mac fully becomes a walled garden, and you can expect pages of HN complaints.
I can see this happening, but it probably won't anytime soon. macOS is still open enough, and with the assumption that sometimes processes need root (see third-party Launch Daemons).
It would probably break quite a lot. But I wouldn't be surprised if they eventually gradually move macOS in that direction.
And it so annoying because it steals focus so as you're writting a message it suddenly stops taking your input and "helpfully" continues typing your text into the password box.
These types of ‘security’ blockers are so dumb because they train people to act dumb. Even if they’re real, the next time they may not be.
It’s like how my bank often calls and wants me to give them my personal info for ‘data protection’ before we can speak. These are legit bank calls, training people to give out personal info to strangers.
As of the latest macOS update, every app is now asking every few days if it can have access to devices on your local network, or something to that tune. My theory right now is it's something in chromium that automatically asking for this and Electron apps will do this out of the box, but I can't remember which apps exactly have been doing this.
Regardless, yes it causes the exact issue you're talking about. I don't even read what the popups say anymore, I'm just blindly hitting an accept button.
When you make an iOS app and requested permission for something - photo library or location etc. you MUST write out a sentence of what you’ll use it for which is shown to the user.
I likewise refuse the bank’s call and they’re always really confused why I’d do such a thing - so clearly they have successfully trained all their other customers to be morons - and then they will no doubt blame them when they get conned.
And they somehow stack in time. So after a weekend it's popping up over and over until I give up and quit Slack. It's been like this for a year I'd say. There's no way to stop them and they always get focus, which is extremely annoying. How can I revoke this permission from Slack? Seems pretty abusive.
Not an os-x developer, but I've always wondered are there any OS guardrails against any (malicious) application showing a window styled the same way as that popup box and just stealing your password?
I mean, I don't know how there would be? Unless they were scanning the text of every pop-up for words convincing the user to enter their computer password. There would be no way to determine intention without some sort of language analysis.
Yeah. I'm guessing there must be some legitimate (internal?) use cases for the behavior I found and they spent all that time working out the kinks to allow those edge cases while also not allowing malicious ones. Or perhaps it wasn't as high on their priority list as it required a higher level of user interaction (the user had to click "Allow"). In any case, though, I do believe that a year is a shockingly long time for them to take.
I once sent an email to Steve Jobs back in 2009 or so
I told him that the MacOS permissions dialog could easily be spoofed, and that Macs should have a secret phrase or icon that you choose that they’d display inside these dialogs, and prevent their screen capture like what they had been doing with their recent DRM features.
Never heard back from him
And it never got implemented. Any program can still continue to spoof it and grab your system password.
I mean, at that point and app could just put up a fake prompt using the UI framework. And I think users would be more hesitant to type a full password than just click a button. But if you're talking about a bug similar to mine where an attacker could use the OS's own code against it and make it show a prompt with misleading content, you might be able to report it to Apple Product Security and maybe get a bounty.
I wonder why they don't add a little led to their laptops that would indicate that it really is the system asking for your password. Kind of like the camera led.
When they had the touchbar on the MacBook Pros, they would put the authentication in there since that was something only the OS could take full control over.
That's an interesting idea. I do think it would be nice to have some way of knowing "is this prompt coming from the operating system or some third-party app?". However, I don't think it would have helped in the case of my vulnerability, because it abused a legitimate OS prompt.
I mean, a website could display a crafty popup-appearing box and try to get you to type in your username and password. Not really sure how you can prevent that.
Vista used the “the background dims quite a bit” to try to deal with that.
Problem is most users will not care or understand it. Someone will spoof the dialog without the special icon or phrase and users would still enter the password.
Yeah. I think the key thing in my vulnerability is that it abused a legitimate OS prompt and had the consequences of that prompt be applied to something separate from what the prompt text itself said it would.
I agree with you. However, in this case, I was abusing a legitimate OS prompt (not just making my own), so I don't know if a security image would be a barrier there. It would definitely be one for instances where malicious apps make their own pop-ups.
No word from them on the payout, yet. They only start deciding on if and how much to pay after the patch. I know for a fact it doesn't fall under the $1,000,000 reward tier as that is for their Private Cloud Compute platform. But it may fall under some of their other categories.
man, i think this really is the last time im buying Apple products, the string of CVEs, the many issues with hardware, iPhone as well....im over the hype and switching to Android and Windows
I miss being able to play games. I miss having a phone without lock-ins and security vulnerabilities that do not get patched.
Oh you're going to _hate_ Windows - I say this as someone who switched in the last 2 years. MacOS can be very annoying, Windows is just one big advertisement these days in a badly skinned window manager.
Yeah, I basically keep Windows just for Word and Excel and Windows-exclusive video games, and use Linux most of the time because of this. There's no perfect system out there.
This is Apple-specific, though. So there aren't really any other vendors that are relevant to this specific scenario. I will say, they have been quicker with my other reports; taking just a few months as opposed to a full year.
Thank you for your kind words. To respond: 1. I'm not a "he", I would prefer "they". 2. As I mentioned in another comment, I have not received word back yet on any reward.
I think their "Hall of Fame" (or at least whatever people colloquially refer to as that) is their credits for people who found bugs in their web servers, so I don't think that counts here. I did get credited, so I'm happy about that. Now I just have to wait and see if they determine it's worth a reward (and, if so, how much).
It is absolutely worthy of a reward, and it should be worth a few months of your time. This is a nasty security issue, and you showed a ton of restraint not losing patience with Apple.
Honestly, it's bullshit that you don't already know whether or not you're going to get a bounty.
I will definitely admit, it can be a bit of a pain point that Apple sometimes takes a lot of time to determine a bounty. I'm just waiting patiently now to see what they say. I appreciate your kind words and encouragement.
I honestly think this is a good skepticism to have. I generally don't hit "Accept" (or "Allow" or whatever) on any permission pop-up unless I know exactly what it's doing and what I need it for.
At this point, “permission fatigue” is real. You almost get trained to click ‘Allow’ just to get work done—which defeats the whole point. Would love a tiered trust model, not binary prompts.
> You almost get trained to click ‘Allow’ just to get work done
I had an interesting experience of this with a normal/non-technical user when my wife asked for help setting up some money remittance app. Early in the install it popped up some dialog, something about whether you wanted to transfer money via credit card or...except she clicked the "OK" button before I could read more than that. As in, she clicked it literally as fast as she could process there was a pop-up and move her finger there.
I asked her why she clicked the pop-up away without reading it, it might have been important...and she literally began to argue with me that there hadn't been a pop-up and what was I talking about.
Just like how our brain has learned to edit out blinking, it seems like (at least in some circumstances) her brain has learned to edit out pop-ups and essentially muscle memory is clicking "Okay" as fast as possible to get back to whatever she was doing.
tbh i just don't trust any of these permission dialogs at this point - makes me wonder if good security even starts with the ui or it's all just kinda broken underneath?
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.
Not really helpful.
> 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.
They also run L4 variants below and besides XNU, on same cores as the rest https://randomaugustine.medium.com/on-apple-exclaves-d683a2c...
Ooh! Thanks for the links!
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.
The Plessey 250 was a great one... https://en.wikipedia.org/wiki/Plessey_System_250
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.)
Oh nice! I'll take a look at these.
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.
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.
They are definitely not always awful.
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.
---
[0] https://kagi.com/proxy/latest?c=LsHiRSPxhD29sXqLhdI0j1EsQ98n...
[1] https://youtu.be/6-fkYFV7rOY?t=242
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.
This is pretty straightforward for a malicious application to simulate.
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.
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/
Thanks for posting. I’ve had this vividly in my mind for years, but didn’t remember the source. Makes so much sense.
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.
The passkey pop-ups which are indistinguishable from javascript pop-ups are a particularly egregious security mistake.
What's the problem here? Javascript popups can't read your fingerprint so what would be the endgame of a fake passkey popup?
timeout after 10 seconds "fingerprint can't be read, please enter password"
They’re saying they shouldn’t look similar because it conveys authority otherwise.
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.
Hijacking this current top comment to let everyone know there is an important update to this article: https://news.ycombinator.com/item?id=43969087
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.
Plot twist: That dialog never existed! You already fell for it!
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?
Just realized that it asked for your system password if you don't have Touch ID.
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.
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.
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.
Please provide evidence for a claim that logging into iCloud necessarily sends your plaintext local password to the server.
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...
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" :
> 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].
[1] https://developer.apple.com/documentation/security/protectin...
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
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.
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…
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.
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".
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.
> 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.
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
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.
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.
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.
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.
There are three of them, two you've mentioned, and ~/Applications for each graphical user too.
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.
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.
Now imagine that home directory was on your iPhone and you could plug it in to any Mac anywhere you went!
Or on your iPod. https://forums.appleinsider.com/discussion/36380/home-direct...
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!)
If you install an app in ~/Applications, it can auto update without root, but any sus code can overwrite it without root rights too
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).
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
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.
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.
> 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
Which is madly insecure, right?
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
> 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).
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.
I don't even have a ~/Applications on macOS 15.4.1.
You need to manually create it.
In the Finder it is translated to your system language. For example, „Programme“ in German. It is still Applications in the terminal.
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.
You can still choose to install apps to ~/Applications if you are an admin.
I'll definitely start considering it.
Oh interesting, thank you! I wonder doing this will fix the issue where slack repeatedly asks admin password for updating.
An 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 assuming that Apple would have included a patch in all of the releases. It was only later, when I checked the security release notes, that I saw I was not credited under the other two releases. I reached out to Apple to clarify if these releases were patched. As of writing, I have not heard back.
I chose to do my own testing and spun up a virtual machine. After some difficulties I got it updated to macOS Sonoma 14.7.6 and was able to compile and run my proof of concept. It still worked. I would assume the same is true for macOS Ventura 13.7.6. I'm not sure why Apple didn't include the patch in these two releases.
I will update the post when I have more information and/or context.
Edit made: Ventura and Sonoma will remain vulnerable. Apple made the decision to only patch this in Sequoia.
I remember the I'm a Mac and I'm a PC ads that mocked this on Vista. And now my Mac is worse than Vista. It's so annoying.
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 automate clicking yes.
Last I checked there was no solution for this on Linux though. Heck I couldn't even find a way to switch it to use biometrics.
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.
Yes, Windows has had quite a few years to improve the experience of UAC, on the other hand there are plenty of other stuff to complain about.
At least Windows now makes the UAC dialog distinct from the rest of the OS and any other Window. macOS (and most linux DEs too) just look like any other application dialog, easily spoofed.
UAC on Windows opens up on the secure desktop, which is isolated in protected memory and not accessible to other processes. It's also visually distinct, hiding all other UI elements, and nothing else can present the actual secure desktop, only UAC can. Granted, I've seen some fairly convincing looking fake prompts (that regular users would fall for) but to me they were still obviously fake, and they were unable to hide all UI elements like UAC does.
The secure desktop for UAC is also supposed to help prevent cursor offsets and other attacks (replacing the system cursor with fake one that shows as if it's over the "no" button but is actually going to click on "yes").
macOS could really use something like that for it's prompts, and I don't know why any other OS hasn't implemented something like UAC's secure desktop.
The most important feature of the secure desktop is one that is rarely ever mentioned: you can hit CTRL+ALT+DELETE on a real UAC prompt. This is something similar Linux prompts lack (as Linux lacks a similar privileged shortcut sequence); GNOME has full-screen, top-level, UAC-like prompts for PolKit and sudo, but it's hard to figure out if it's real or a fullscreen application.
There are ways to avoid the CTRL+ALT+DELETE safeguard, but it's a lot harder than it is to spoof a password prompt that looks like the OS one. It's kind of unfortunate that KDE went with the macOS/Windows XP approach rather than doing what Windows does.
Mostly because Windows bad attitude by most hackers.
Yes it has plenty of a stuff to complain about, and Microsoft keeps adding to it, yet it also has plenty of cool ideas.
We should explore more what alternative approaches are there to operating systems, instead of doing UNIX and Windows clones all the time.
Out of curiosity, what do you find annoying about it?
Every time I update an app I have to be told I downloaded it from the Internet and do I trust it. Can this app look on the local network? Constantly being nagged to the point I don't even check/care anymore. Exactly what Vista used to do.
This isn't what Vista "used to do". Vista had a single elevation popup dialog / shatter attack prevention screen. Any request that required elevation required this popup.
macOS has not only elevation requests but entitlements. Using the local network is an entitlement. What macOS gets very wrong is any denied entitlements will re-prompt next time you perform that action with the app, which may simply be starting the app. It also does one entitlement at a time, i.e. if you have an app that requires screen sharing and camera, you'll get the first entitlement, restart app, go to do action you wanted again, second entitlement.
Both OSes have MoTW, but Apple goes beyond with the notarization warning/block.
macOS users are going to suffer from prompt fatigue. And the /r/macos "secure cus UNIX!" will be wrong on two points.
Technically you're right. From an end-user standpoint, it's irrelevant. Apple's mock vista ad applies just as well to Ventura: they're all annoying and a security theater if the user is just told to input admin password into any random popup.
https://www.youtube.com/watch?v=VuqZ8AqmLPY
Quick clarification on terminology. From a developer perspective, entitlements a static dictionary (or a collection of key-value pairs) attached to the app at code-signing time. The entitlements you mentioned don't "entitle" the app to access resources, as user consent is still required.
An app with [the com.apple.security.device.usb entitlement](https://developer.apple.com/documentation/bundleresources/en...) is technically always going to have that entitlement attached to the app regardless of user consent.
FWIW, Vista's level of prompts is the only way to run UAC in any kind of secure fashion. The configuration that has been the default since Windows 7 makes it trivial for a low-privilege application to gain UAC privileges.
Microsoft doesn't regard UAC as a security boundary if you're logged in as an admin (https://learn.microsoft.com/en-us/previous-versions/tn-archi...). You can use UAC as one as part of a defence-in-depth approach by logging in as a non-administrator user (like everyone tells you to do but nobody wants to do) and entering a password for every prompt, but for that to work well you'd need to make sure to turn UAC prompts back to max (read: Vista level or worse). I don't think I'd set up a system like that without a fingerprint reader or Windows Hello facial recognition camera, because typing out the password that often is just a massive pain.
Windows, as configured by default, barely runs any downloaded files. You can pay hundreds of euros for a certificate, sign your installer, and still have users get told off by SmartScreen for daring to open an executable file. I don't think Apple's notarization has done anything useful so far, but their security prompts are a lot less scary than Windows'. I think it's a matter of time before unsigned Windows executables with the MotW simply won't open by default like those on macOS.
The one that I find really obnoxious is granting permission to read from a “removable” drive. Like the one my steam library lives on.
How often do you face that? I would think the OS would save your response in a way it could refer back to.
Frequently. The problem is it’s per app not per drive. I had my entire homedir on there for a while but the prompts just got to be too obnoxious.
Damn, that sucks.
The local network popup thing is too overdone in my opinion. However, I do think it is a good choice (in some respects) for Apple to have the "this is a program downloaded from the Internet", even if it can be annoying. It might also be a push to get developers to publish on the App Store (where Apple can be more sure (hopefully) that the apps are safe).
It's a double-edged sword in my opinion. I think it's good that the OS is looking out for the user in a lot of cases. I also understand how it can give the users pop-up fatigue.
> It might also be a push to get developers to publish on the App Store (where Apple can be more sure (hopefully) that the apps are safe).
Apps on macOS need to be signed and notarised. Apple has the exact same capability to scan for malicious behaviour and revoke your keys regardless of how you publish. We all know the real reason they want to push apps towards the app store.
"This is a program downloaded from the internet" isn't a push to the app store. It predates the Mac App Store, iirc.
It's another quick security hack (as they often are in any OS). Many years ago someone noticed that apps can pick any icon they want. And, therefore, if you could convince a browser to download a file to ~/Downloads (not hard), the user might look inside and find what appears to be a harmless JPEG or Word document, double click it and are immediately pwnd because back then there was no app sandboxing of any kind, no SIP etc. macOS in that era was a conventional desktop UNIX.
So the quick hack - make apps that download things mark files with extended attributes, and if the Finder sees that, it pops up the warning and then removes them. Now the user realizes (maybe) that the document-looking-thing was actually an app.
That's a fair point. But did Mac have the same issue as Windows where file extensions were not shown by default? That feels like it would have been the core issue.
There is a "show all file name extensions" option in Finder, but I don't recall if it's on by default or not as I haven't had to set up a fresh macOS install in a while and I've always had it turned on.
But, macOS isn't like Windows - the file extension doesn't matter. I can have a "file.txt" but it's actually a .xlsx excel workbook, and Excel will open it just fine (albeit, with a warning that the file extension doesn't match but that's dependent on the application presenting a warning). Windows actually uses the file extension to determine the type, macOS (and other *nixes) don't, they'll use some other file metadata. You can put whatever extension you want on a file, it doesn't matter except for determining what default app will attempt to open it when double clicking it in Finder.
> It might also be a push to get developers to publish on the App Store (where Apple can be more sure (hopefully) that the apps are safe).
This is exploitation of developers, plain and simple. Apple should secure their runtime, not roleplay as a software rent-a-cop that manually (and fallibly) inspects submissions. The App Store is a blatant moneymaking racket, on mobile and desktop alike. "Security" is a fig leaf for the perverse incentive Apple has to corral developers under their thumb.
I think entitlements are the correct direction to move in. I don't like Apple's implementation. But it gives us that fine-grained control of what an app can and cannot do with things outside of the app's "bubble" (or sandbox). We need Discretionary Access Control.
Apple does both. They secure the runtime and review apps.
And to NSO Group's delight, they don't review SMS messages or Safari contents either. The "curated security" shtick is a lie, it does not protect anyone and doesn't function reliably in the first place. Both targeted malware and generic scams are rampant and unrestrained on iOS. Many of them are promoted as iPhone Search Ads, or suggested Siri results.
The knock-on effects it has are even worse. By relying on this game of shuffling private entitlements around, Apple has less incentive to actually review what developers are doing with them. Look at the Uber iPhone app's screenrecord permissions, or when TikTok stole iOS clipboards.
Apple uses "secure" review as an excuse to not review apps or secure their runtime.
Apple's review sucks but you are very confused about your "takedown" of their security practices. It's not meant to protect against everything. Even well-made security boundaries can fail against sophisticated attackers, or be too onerous against generic malware.
But they do secure their runtime. It's not an excuse not to.
Honestly, I think you have a fair point there. I personally don't believe that any system could be 100% secure. But I do think there is a point to be made on the efficacy of securing the runtime compared to individual app inspection.
*the App Store where apple can be more sure they'll get a 30% cut
I simply run `xattr -d downloaded-app.dmg` on apps I download that I trust to turn off this behaviour.
yeah, 'cause that's so much easier than just saying yes to the prompt, or right-clicking and selecting open from the context menu
In macOS 15, there is no GUI bypass. Right click -> Open no longer works. xattr is "the way". I'm sure someone has probably created an Automation or something for it.
There's a small section in System Settings that they don't really tell you about that pops up when the OS blocks a file from opening. You can then override the block there. Yes, it's extremely annoying.
I have an alias set in my shell for `xattr -d ~/Downloads/.{dmg,zip,z}`.
> where Apple can be more sure (hopefully) that the apps are safe
Ha, they'd love to capture the 30% Apple tax on macOS too, I'm sure.
I don't think the mark-of-the-web feature is bad, but I am particularly annoyed that I have to open the system settings app to open an application.
Honestly, when I first tried modern macOS, I was surprised how bad the popups and warnings were. This is exactly what Apple (rightfully) made fun of when Vista came around. I've caught myself mindlessly approving prompts because there are so many of them and most of them don't make much sense at all ("do you want to allow iTerm access to your downloads" after I've explicitly dragged the thing to the special "developer tools" setting? what the heck?).
Microsoft was right.
Oh god, don't get me started...
1. iCloud nags never go away if you don't log into iCloud
2. Apple Music is just an advertisement by default and "conveniently" opens every sound file mimetype
3. Functionally useless subscription slopware like AppleTV+ comes installed by-default for no reason
4. Package management is a colossal clusterfuck that can't even enforce package parity across system architectures
5. Apple still doesn't trust their users enough to have modern amenities like a native Vulkan runtime or Nvidia GPU drivers
Vista was terrible, but it didn't suffer from this level of identity crisis.
Slight tangent: Apple TV constantly has MLS (major league soccer) and Apple TV+ in the left-side pop up Home menu, taking up real-estate for something I will never access. So annoying.
Why, as someone from England — with arguably the best football league in the world — would I want to watch American Soccer? I don’t even watch the English league.
The menu is:
———————
* Search
* Home
* Apple TV+
* MLS
* Store
* Library
———————
Title: Channels & Apps
* This is where all the channels I have actually opted for live — separate from the Apple products that I don’t want
———————
Both Apple TV+ and MLS should not be on that menu permanently. And it should be possible to turn them off.
> Why, as someone from England — with arguably the best football league in the world — would I want to watch American Soccer? I don’t even watch the English league.
So you're the type that doesn't watch the Special Olympics I take it? MLS is the geriatric retirement league for super star players, or the not quite good enough to play in the other leagues league. One season, I tried to get into MLS. At one point I tried using a stop watch to clock how much time the ball was out of play in MLS compared to "real" leagues, and it was close to 20% which is not far away from amateur kids level of play.
I don't blame you for not liking the MLS branding. However, I'm guessing they paid a couple of shiny coins for that privilege, so they're naturally going to try to do anything to recoup that money
I don’t watch football at all. If it’s not cricket… well it ain’t cricket!
But even if it was a channel dedicated to test cricket (the greatest sport in the history of sport), I would still resent the foisting. These are clearly anti-competitive practices and that always leads to worse products eventually.
Speaking of installed-by-default, it's even more stupid that you can't even uninstall apps like Photos. Supposedly it's 'required for your Mac to function.' I'm sorry, I do not have a need for a photo library on a computer used exclusively to write software.
+1 I dont understand why Macos cant be more like iOS
Unrelated, but I wish they merged macOS and iOS into the best of both, but... they would probably make macOS worse if they tried
> Apple Music is just an advertisement by default and "conveniently" opens every sound file mimetype
Not only that, but you get the advertisement every time it starts and then it doesn't play the actual file. So unless you join the service the process is: try to open the audio file, close the advert, go back to source, open the file again.
Agreed the default experience is bad. You can however change the default app for each of the relevant file types. I’ve set my default to be iina
I recall being able to access the equivalent of 'Settings' in Vista without it crashing constantly.
Sometimes I consider looking switching back to MacOS (left because OS X 10.7 was becoming too much like iOS and I don't like the idea of apps having to be signed and/or in an app store) and holy shit I am glad I left.
it's still better than windows. Compared to Gnome or KDE one could argue either way
I did Linux for a bit, but I was really impressed with Windows 10 once I disabled all the junk. Good window management, WSL is fantastic, I really like a few windows-specific utilities, and programs. I like having the Adobe suite + a nix env.
That being said, Windows 11 is making me consider jumping back to Linux, along with me being increasingly annoyed by Adobe.
For development work, I honestly prefer Windows. At least WSL knows what you want to do and gets out of the way. Comparatively, making a "correct" shell on MacOS often entails QEMU and local NAS, alt-tabbing between that and your native terminal for version control. Or you build your server software to be MacOS-native for debugging and port it to Linux later like a neanderthal.
Just... no. MacOS looks pretty but the workflow is uglier than Satan's taint. I don't get paid to work around Apple's dysfunction.
> iCloud nags never go away if you don't log into iCloud
I don't get people who buy macs and refuse to login to iCloud.
You don't have to use iCloud for storage or anything else, all that can be disabled in settings.
The biggest benefit of logging into iCloud is protection if your device gets stolen. It means the thiefs can't just wipe and resell your device. It means you can track and remote-wipe it in Find My.
I agree that it's weird that Apple TV comes pre-installed. The others I have less experience with so I can't really comment on them.
you might like https://github.com/philocalyst/infat to change the mimetypes associations
I might prefer respectful default apps that delight the user and don't cost anything more than what I paid for at checkout.
MacOS isn't for me, I guess.
I hear you, but 10y of MacOS usage habit will make that to you, it's easier for me to work around MacOS quirks and Apple's authoritarianism than it is to try and get a Linux distro I like to work perfectly for me for more than 6 months, or worse, go back to win
The tradeoff between security and extensibility is something which seems to be unavoidable.
But the goalposts have moved a bit. At least macOS is not plagued with malicious processes like was common on windows. Or maybe I'm just careful?
Neither was Windows if you knew what you were doing.
I ran Windows XP for years without antivirus back in the early 2000s and so did others.
From the beginning, TCC has been a house of cards. It only impedes legitimate developers and tortures users with permission prompts that Apple ridiculed back in the day, while malicious apps can easily bypass the "security" (theater) in countless ways that researchers continue to uncover and report. I'm not a professional security researcher, just a Mac developer, but I've discovered a number of bypasses myself. It's almost as if Apple engineers don't even understand the technology they're using. And maybe they don't! How many remain from the pre-iPhone era?
The continuous incorporation of basic system features into TCC has drastically increased the friction of deploying enterprise management software on Macs (especially for education), to the point where I would question the overall value proposition.
I say this as a dedicated macOS (Cocoa) developer since 2003.
My work Mac regularly pops up an alert box claiming that Slack is “trying to install a new helper tool”. I have no idea why or what it means. I asked IT how I could verify it was legit and they didn’t know.
I often wonder if this could also be exploited because it asks for a password and it keeps popping back up every time I click cancel.
This dialog comes from the System Management framework [1]. Slack is probably installing a privileged helper tool (conceptually similar to a setuid root binary) so that it can update itself regardless of where it is installed or which user originally installed it.
[1]: https://developer.apple.com/documentation/servicemanagement/...
Seems like it should only need to do this once. I get this with almost every Slack and VSCode update. The correct solution for me is to quit Slack.app and let my company's management software do the update for me.
Chances are they have some kind of management software like SentinelOne that is preventing Slack from doing this (or storing the permission to do so), so it just asks over and over. Which is arguably worse.
I don't use slack except in the browser. I never get a prompt for VSCode. It must be one of your extensions.
I've got them both installed through a corp-managed "software center". Don't have any exciting extensions that I've installed.
Maybe it's smart enough to require re-authorization when the binary changes?
Why would the helper binary change that much? A setuid-ish binary should be ultra simple and not constantly changing I'd assume.
...and it should be able to replace itself.
I installed Slack from the app store and never see this popup.
Discord does this as well I believe. I often needed to enter the administrator password to install a helper after the system had been off for a couple days.
Discord, Slack and VS Code desktop apps are all built using Electron, so I'm guessing this is an Electron issue.
And they are sooooo insistent. Just keep bugging you forever
A software updater was going to be my best guess at what this was. I guess I understand the flexibility it brings, but it definitely does have some security trade-offs.
I get this popup all the time.
It contains no information that I can reasonably use to match a decision on whether or not to allow it, so I always click cancel on it.
I use Slack as a web app, but not in the browser: https://support.apple.com/en-us/104996
Discord can be installed this way as well. It's (imo) a better usage experience than their Electron apps.
Nearly every Electron app is better this way.
I'm not aware of the "helper tool" popup, but I would definitely be skeptical of it. Even if it is Slack, Slack is just a messaging application. I don't know what legitimate need it would have for a helper tool. I would ask Slack support, though (and hopefully you can get a real answer and explanation).
> Slack is just a messaging application.
I kinda like this angle. While Slack makes an effort to work basically everywhere with low effort, I wonder what would follow if it wasn't the case.
For instance if for some stupid legal reason Slack was banned from macos, how many people would just switch to another OS ? I'd bet it would be a non trivial amount of users at this point.
> I kinda like this angle. While Slack makes an effort to work basically everywhere with low effort, I wonder what would follow if it wasn't the case.
This idea of respecting user preference is not the way, though. For example, back when Skype existed, you couldn't remove its icon from the macOS menu bar, because (1) Microsoft didn't believe you had the right to choose to remove that item, and (2) macOS believes an app developer should have more control over what goes in my menu bar than I do.
or you know, just use the web app
If it was a legal ban I'd assume Apple would go pretty far to make it happen, app or not.
> Slack is just a messaging application
its sold more as a way to store and all conversations than the ability to be a messaging application.
the original pitch was to make all information, even private conversation of previous employees, searchable.
It doesn't need special permissions on your Mac to do that.
Damn. That sounds pretty dystopian. But typical for American corporate life.
I don't really expect my 1:1 conversations on the company chat to be invisible to the company.
In environments like this, my trusted colleagues and I communicated using Signal (and before that, WhatsApp).
One somewhat paranoid department that was convinced they were being spied on (they weren’t; I saw the Slack admin dashboard and management was too cheap to pay for the retention and spying features) maintained the use of an ancient Jabber based group chat for their own internal communications.
if signal is on company hardware, they have crowdstrike for that.
This was around 8 years ago, but there was no MDM installed on our cell phones, regardless of if BYOB or company paid for device.
The only restriction was if you went to China, you took a burner phone (one of the old company phones, usually) and weren’t supposed to ever use it again once you left. I think they just sold them to a liquidator.
I don't either. But it's still a bit creepy regardless.
Why? Companies already have to retain the data (in case of lawsuits, etc.).
Slack is also used because it allows to create persistent channels that are searchable. So they often end up being a knowledge base for the company.
I guess that's a fair point. It cuts both ways, but given that so many people use Slack as opposed to talking, the exact words people used and when are could be open to view. Whereas, before all of this, you may only just have the minutes of any official meetings. Any side chatter not in the meeting room and/or exact phrasings would be lost to time.
That does sound like it could be exploited, but with only as much exploitability as some random app that requires your password (for analogy consider a Linux binary that refuses to run unless being run as root). Ultimately it's a matter of deciding whether you trust the developer of the app and whether you trust this app is really from that developer. The day Apple prevents users from giving root access to a third-app app is when the Mac fully becomes a walled garden, and you can expect pages of HN complaints.
Overall I think it's good paranoia to not grant root permissions to apps that do not clearly need them such as Slack.
Being paranoid, would it be possible that another app already installed (but not trusted enough to give privilege, let’s say a shady mouse driver or screenshot app) detect when slack (more trustfully) does launch to open a dialog at that precise time and deceive the user? Let’s say the shady app is named « SIack » or something close enough to be missed - but brand itself as innocents « screenshotPro4000 » in the app itself graphics so you’re not suspicious.
> The day Apple prevents users from giving sudo access to a third-app app is when the Mac fully becomes a walled garden, and you can expect pages of HN complaints.
I can see this happening, but it probably won't anytime soon. macOS is still open enough, and with the assumption that sometimes processes need root (see third-party Launch Daemons).
It would probably break quite a lot. But I wouldn't be surprised if they eventually gradually move macOS in that direction.
And it so annoying because it steals focus so as you're writting a message it suddenly stops taking your input and "helpfully" continues typing your text into the password box.
These types of ‘security’ blockers are so dumb because they train people to act dumb. Even if they’re real, the next time they may not be.
It’s like how my bank often calls and wants me to give them my personal info for ‘data protection’ before we can speak. These are legit bank calls, training people to give out personal info to strangers.
As of the latest macOS update, every app is now asking every few days if it can have access to devices on your local network, or something to that tune. My theory right now is it's something in chromium that automatically asking for this and Electron apps will do this out of the box, but I can't remember which apps exactly have been doing this.
Regardless, yes it causes the exact issue you're talking about. I don't even read what the popups say anymore, I'm just blindly hitting an accept button.
I’m surprised Apple have let this happen.
When you make an iOS app and requested permission for something - photo library or location etc. you MUST write out a sentence of what you’ll use it for which is shown to the user.
Why not the same for Mac apps?
Why not the same for Mac apps?
How would Apple enforce that?
iOS apps go through the App Store, so proper behavior can be enforced.
The apps people are complaining about here are downloaded from the vendor. Apple is not involved.
Apple controls the OS and permission system. They could just automatically reject all permission requests with an empty/short reason.
Nobody knows what they are; Apple provides no tools to diagnose what it is.
This is chrome for sure. There a bunch of threads if you search the actual error message you'll get hits on stackoverflow and in apple forums
If someone cold calls me and asks me to verify myself, I refuse.
If it’s an expected call or they give me a good reason to, I’ll call their listed contact number back.
So far I have not missed out on anything of consequence by refusing to identify myself to someone who initiated contact with me.
I likewise refuse the bank’s call and they’re always really confused why I’d do such a thing - so clearly they have successfully trained all their other customers to be morons - and then they will no doubt blame them when they get conned.
And they somehow stack in time. So after a weekend it's popping up over and over until I give up and quit Slack. It's been like this for a year I'd say. There's no way to stop them and they always get focus, which is extremely annoying. How can I revoke this permission from Slack? Seems pretty abusive.
Not an os-x developer, but I've always wondered are there any OS guardrails against any (malicious) application showing a window styled the same way as that popup box and just stealing your password?
I mean, I don't know how there would be? Unless they were scanning the text of every pop-up for words convincing the user to enter their computer password. There would be no way to determine intention without some sort of language analysis.
I get this from every Electron-based app that I have run as multiple OS users.
VSCode does this too on work-issued Mac.
I've been ignoring both for literally years.
same but nordVPN
It took Apple a full year to release the fix. That is a very long time.
2024-05-04 I leave several additional update messages as I continue testing my PoC
2025-05-12 The patch is released
Yeah. I'm guessing there must be some legitimate (internal?) use cases for the behavior I found and they spent all that time working out the kinks to allow those edge cases while also not allowing malicious ones. Or perhaps it wasn't as high on their priority list as it required a higher level of user interaction (the user had to click "Allow"). In any case, though, I do believe that a year is a shockingly long time for them to take.
I once sent an email to Steve Jobs back in 2009 or so
I told him that the MacOS permissions dialog could easily be spoofed, and that Macs should have a secret phrase or icon that you choose that they’d display inside these dialogs, and prevent their screen capture like what they had been doing with their recent DRM features.
Never heard back from him
And it never got implemented. Any program can still continue to spoof it and grab your system password.
I mean, at that point and app could just put up a fake prompt using the UI framework. And I think users would be more hesitant to type a full password than just click a button. But if you're talking about a bug similar to mine where an attacker could use the OS's own code against it and make it show a prompt with misleading content, you might be able to report it to Apple Product Security and maybe get a bounty.
I wonder why they don't add a little led to their laptops that would indicate that it really is the system asking for your password. Kind of like the camera led.
When they had the touchbar on the MacBook Pros, they would put the authentication in there since that was something only the OS could take full control over.
You can draw arbitrary content into it though?
That's honestly a pretty smart move.
Yeah it's a shame it's just such an overengineered/expensive thing.
That's an interesting idea. I do think it would be nice to have some way of knowing "is this prompt coming from the operating system or some third-party app?". However, I don't think it would have helped in the case of my vulnerability, because it abused a legitimate OS prompt.
I mean, a website could display a crafty popup-appearing box and try to get you to type in your username and password. Not really sure how you can prevent that.
Vista used the “the background dims quite a bit” to try to deal with that.
I just told you how… it would show your special icon or phrase inside so you’d confirm it before you typed anything.
The phrase would be managed through a system screen, like a login screen
Problem is most users will not care or understand it. Someone will spoof the dialog without the special icon or phrase and users would still enter the password.
Banks did this years ago, but a few surveys showed nobody actually checked for their key phrase or image.
Yeah. I think the key thing in my vulnerability is that it abused a legitimate OS prompt and had the consequences of that prompt be applied to something separate from what the prompt text itself said it would.
Well, today Mac OS told me Chrome wants to access bluetooth, which of course I denied.
So I guess sometimes the permission system works.
This is one of those places where having a selected “security image” makes sense. That popup should not just be easily spoofed text.
I agree with you. However, in this case, I was abusing a legitimate OS prompt (not just making my own), so I don't know if a security image would be a barrier there. It would definitely be one for instances where malicious apps make their own pop-ups.
Adobe Creative Cloud will keep multiple processes running in the background even when you explicitly configure it to not do that in the OS settings.
Creative Cloud is malware IMO.
Love this guy's research, such good presentation!
Thank you very much! Although I'm not a guy, just fyi! I'm just a person :)
> Apple confirms that I will be credited
congratulations on the credit
and they also paid you $1,000,000 or whatever their top bug bounty payout is right?
No word from them on the payout, yet. They only start deciding on if and how much to pay after the patch. I know for a fact it doesn't fall under the $1,000,000 reward tier as that is for their Private Cloud Compute platform. But it may fall under some of their other categories.
man, i think this really is the last time im buying Apple products, the string of CVEs, the many issues with hardware, iPhone as well....im over the hype and switching to Android and Windows
I miss being able to play games. I miss having a phone without lock-ins and security vulnerabilities that do not get patched.
Oh you're going to _hate_ Windows - I say this as someone who switched in the last 2 years. MacOS can be very annoying, Windows is just one big advertisement these days in a badly skinned window manager.
Yeah, I basically keep Windows just for Word and Excel and Windows-exclusive video games, and use Linux most of the time because of this. There's no perfect system out there.
> The patch is released
I assume that is with 15.5...
> which was patched in today's releases of macOS Sequoia 15.5 et al.
Correct.
Correction (longer explanation elsewhere): only 15.5. Apple didn't patch it in the other two releases.
Almost a year to release a patch. If Apple takes that long, there is no hope for other vendors.
This is Apple-specific, though. So there aren't really any other vendors that are relevant to this specific scenario. I will say, they have been quicker with my other reports; taking just a few months as opposed to a full year.
Why is there no hope for other vendors?
Author didn't disclose if got a reward for his work. Hope he did!
Thank you for your kind words. To respond: 1. I'm not a "he", I would prefer "they". 2. As I mentioned in another comment, I have not received word back yet on any reward.
Maybe they'll put you into their "Hall of Fame"
I think their "Hall of Fame" (or at least whatever people colloquially refer to as that) is their credits for people who found bugs in their web servers, so I don't think that counts here. I did get credited, so I'm happy about that. Now I just have to wait and see if they determine it's worth a reward (and, if so, how much).
It is absolutely worthy of a reward, and it should be worth a few months of your time. This is a nasty security issue, and you showed a ton of restraint not losing patience with Apple.
Honestly, it's bullshit that you don't already know whether or not you're going to get a bounty.
I will definitely admit, it can be a bit of a pain point that Apple sometimes takes a lot of time to determine a bounty. I'm just waiting patiently now to see what they say. I appreciate your kind words and encouragement.
Trust nothing.
Honestly, I don't really trust any permissions popups on anything anymore. They are often porous enough to count as "security theater".
And at $Corp I get constant popups to enter my password or confirm an action. Like 50-100 a day.
I bet threat actors are just salivating at the thought of giving you a fake password prompt.
Yeah. I am very hygienic at work in terms of what sites I visit but you can never be too careful. To me the main threat vector is my dev curiosity!
Lol, I know that curiosity feeling.
I honestly think this is a good skepticism to have. I generally don't hit "Accept" (or "Allow" or whatever) on any permission pop-up unless I know exactly what it's doing and what I need it for.
At this point, “permission fatigue” is real. You almost get trained to click ‘Allow’ just to get work done—which defeats the whole point. Would love a tiered trust model, not binary prompts.
> You almost get trained to click ‘Allow’ just to get work done
I had an interesting experience of this with a normal/non-technical user when my wife asked for help setting up some money remittance app. Early in the install it popped up some dialog, something about whether you wanted to transfer money via credit card or...except she clicked the "OK" button before I could read more than that. As in, she clicked it literally as fast as she could process there was a pop-up and move her finger there.
I asked her why she clicked the pop-up away without reading it, it might have been important...and she literally began to argue with me that there hadn't been a pop-up and what was I talking about.
Just like how our brain has learned to edit out blinking, it seems like (at least in some circumstances) her brain has learned to edit out pop-ups and essentially muscle memory is clicking "Okay" as fast as possible to get back to whatever she was doing.
tbh i just don't trust any of these permission dialogs at this point - makes me wonder if good security even starts with the ui or it's all just kinda broken underneath?