Live data from Hacker News

Can you trust that permission pop-up on macOS?

wts.dev

231–240 of 261 posts

Re: Can you trust that permission pop-up on macOS?

#231
post #200

Earlier quoted context omitted.

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 d…

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.

Re: Can you trust that permission pop-up on macOS?

#232
post #93

Earlier quoted context omitted.

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…

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.

Re: Can you trust that permission pop-up on macOS?

#233

Earlier quoted context omitted.

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.

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…

> 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?).

Re: Can you trust that permission pop-up on macOS?

#234
post #90

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…

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.…

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.

Re: Can you trust that permission pop-up on macOS?

#235

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 t…

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.

Re: Can you trust that permission pop-up on macOS?

#236

Earlier quoted context omitted.

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.…

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.

Re: Can you trust that permission pop-up on macOS?

#237

Earlier quoted context omitted.

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.

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.

Re: Can you trust that permission pop-up on macOS?

#238
post #200

Earlier quoted context omitted.

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 d…

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.

Re: Can you trust that permission pop-up on macOS?

#239

Earlier quoted context omitted.

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 ter…

I think you are wrong about Unix model only existing for compatibility 1. OK, so it requires terminal to have some entitlement first I guess. If you needed to grep some app's bundle in the past you probably gave it already. 2. many apps ask for admin user/password when updating. including say Docker. some developer software specifically says "we ask you this because we need to sudo" stuff under SIP I think includes s…

Grepping is always allowed because it's read only.

Yes some dev tools like Docker ask for admin passwords, but that's not typical of most Mac users experience.

Root still exists, but outside of software originally built for Linux or some odd edge cases, you won't encounter it.

Re: Can you trust that permission pop-up on macOS?

#240

Earlier quoted context omitted.

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 wei…

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.

Post reply on HN