[0]https://support.apple.com/guide/security/protecting-against-...
Unfortunately, I can only provide my anecdotal experience, but it seems to be in stark contrast to your comment.
if you have one thousand users of desktop computers distributed across geography and age groups, and you watch whatever behavior it is that you claim is "it" ... how many of the thousand users show the weakness or lack of care or lack of self-defense.. How many ? four? four hundred?
if four hundred users fall for some scammy website using a browser on the internet, you mean to say that every user must have bicycle training wheels and constant adult-supervision monitoring? Do you make money in some business-model that does that?
In other words, instead of a 2-step UX like this: (run as admin) + (let app do any admin type thing)
Your system should have multiple explicit 1-step UXs: (let app do admin thing X)
The later will presumably present a more clear explanation to the user of what they are doing.
Of course, no Real(tm) capability-based GUIs have ever been built to my knowledge, not even in academia, so this is an entirely theoretical argument and not a criticism of Apple.
On MacOS, applications by default don’t have the right to read your disk and show a list of files, they have the right to ask the OS to show a dialog that reads your disk shows a list of files, lets you pick one, and then grants that application the right to read that one file. Similarly, for saving files, the save dialog runs under OS control, and grants an application to write a single ‘file’ (which, on macOS, could be a directory containing multiple files)
Similarly, on iOS, apps can’t read photos, but can ask the OS to show a photo picker.
MacOS (¿still?) has system preferences that allow users to disable such checks, though, granting full file access to certain apps, for example, and also will ask users to grant apps the right to read entire file systems when they try to do so.
Yes you can still disable a lot of this stuff. But I wonder if this is a case where a hardware aspect could let Apple make that less necessary without degrading UI. In principle, with cryptographic signing for input peripherals keyboard/trackpad/mouse/etc, secure processing element routing through it, and the right low level protected kernel support and signed stack, it would be possible to have the OS be able to distinguish between "operator initiated" and "automated" access at a fairly granular level. It'd even be possible to pass that on from one Apple system (or others if it was a standard) to remote ones via SSH or the like. That in turn could enable the system to have different UX between the two classes. For example like a some other HNers I assume I currently grant Terminal full disk access right out of the box as one of my first setup steps just because it's a real irritation to not be able to navigate around and use it from the CLI as I expect without GUI stuff popping up. But instead a system could transparently make it so that when I typed in commands into the shell they'd actually be treated with different permissions than if an automated shell script did the exact same commands, and this could be the case everywhere with a high degree of security. Much more intelligent granting of capabilities would make the UX a lot less irksome and could help push a request for human attention and decision making from the default to the unusual, and that in turn would encourage leaving it on.
I think Apple does already do this to some extent actually? Like, in a native widget GUI app, if the user initiates the GUI open/save file finder they're able to navigate to places outside the sandbox? I might be misremembering. But at any rate extending that as a low level hardware backed feature could be an important step in capabilities usability. Security has to have its costs in line with perceived benefits, or users will just end up degrading it (classic "just write the password on a sticky note leave it on the monitor" issue). The human element isn't a bug it's a core requirement, so would really like to see more effort on that side of things as well.
I get why it doesn't (the problems it would cause for Uber and DraftKings immediately come to mind) but the more sketchy advertisers there are who want to track my location data, the more I want that data to be garbage.
This is a fantastic comment for someone (like me) hungry to learn about security concepts. Do you have any more pointers to useful info about security topics?
That being said, I used to be very interested in capability-based security because it promised solutions to so many security problems but nobody seemed to know about the ideas, and the people who had heard the term often had significant misunderstandings of what was possible with capabilities.
It's been about 20 years but I mostly had it right ;)
"No designation without authority"
This is a great place to start: https://srl.cs.jhu.edu/pubs/SRL2003-02.pdf
Warnings like this are useless when they bundle genuinely dodgy software along with software from legitimate companies I already trust and know. Those messages means nothing to me, and I ignore them, because they're warning me about something I already know "You're trying to run software you downloaded" — yeah, thanks.
> Make it impossible for user code to read the entire keychain
What I've always found kind of bonkers, is that MacOS allows any command to read the entire contents of your keychain (yes, with all your passwords). No auth, no checks, just full access via the `security` command.
> Containerize macOS more, making it impossible for user programs to access files written by other programs, in the way things work on iOS?
Maybe? I don't know if that's the right direction (it definitely isn't for me, and I'd jump ship), but perhaps that's the best thing for most people?
Since running unsigned apps is disabled by default, they are not bundled like this. One is prevented from running at all.
You can change the system to treat them as roughly equal parties (one still gets a warning while the other does not), but preventing this from being possible at all would be worth even more outrage.
If you want this kind of safety for someone who you can't trust to consider these kinds of risks, set their computer up so they can't change that setting and they don't have root access. That's just a second user account. Yes, they'll have to use the app store..... but that's the way it works everywhere.
But yes, I agree: they do not actually suggest any new restrictions, and I did not mean to imply that they did. I just meant to head off the obvious rebuttals, and make my stance clear: You cannot have "allow the knowledgeable to do X" and "prevent the un-knowledgeable from doing X" in the presence of social engineering at a technical level, and there is ample evidence that more popups and friction are not an effective solution. So a safe default and reasonably-ergonomic-but-not-accidental-friendly ways around it seems roughly ideal IMO. Apple hits that fairly well: block by default, right-click -> open to bypass individually (arguably accidental-able, but odd enough compared to double-click and there is still a clear warning displayed), or change settings to allow by default.
No, that's not true. macOS has multiple keychain APIs with different capabilities.
https://developer.apple.com/documentation/technotes/tn3137-o...
Items within the traditional keychain can have ACLs applied to them. When you run `security dump -d`, it will only be able to dump items from a traditional keychain that are either set to allow access to all apps, or that have an ACL that grants access to `security`. Very few items should be set to "Allow All". In my login keychain, almost none are.
For all other items you will get a security prompt with "Always Allow", "Allow", and "Deny" which requires you to enter your password. You can also set items to require confirmation but not require the keychain's password.
If you add `security` to an item's ACL--say because you need access to that item from a script--then any app can of course access that item by calling `security`. My advice would be not to add `security` to any item's ACL.
AFAIK, `security` has no access to the iCloud Keychain where Safari stores its passwords. If you don't have iCloud Keychain enabled, I believe Safari stores its passwords in a traditional file-based keychain but those items should have ACLs on them.
https://support.apple.com/guide/security/keychain-data-prote...
https://support.apple.com/guide/security/icloud-keychain-sec...
ACLs shouldn't be overlooked though: manual keychain items use the default ACL configuration and require user confirmation, which means you need to authenticate N times to access N items.
Clarifying my own comment.
Safari stores its passwords in the data protection keychain. This is called "Local Items" in the Keychain Access app if iCloud Keychain is not enabled. If it is enabled, it's called "iCloud Keychain". Either way, `security` does not enumerate any items from the data protection keychain, only from the file-based keychains. And again, all the items in those keychains should have ACLs on them.
Could it be that the Terminal has full access then? I've never been asked for a password, or had a restriction of any kind put on me, when using the `security` command. Those prompts you speak of are for the "Keychain Access" GUI, no?
The security prompt to "Allow All", "Allow", or "Deny" when a process tries to access a keychain item's value is a GUI window, but it's not part of any app.
Suggesting an umbrella organization give the primary assurance of trustworthiness is similar to what SourceForge used to do, until their practices destroyed their reputation back in 2013, and also greatly damaged the reputations of legit developers who used their site. [https://en.wikipedia.org/wiki/SourceForge#Controversies]
[1]: "A Cautionary Tale from the Decline of SourceForge" [https://news.ycombinator.com/item?id=31110206]
[2]: "Why SourceForge Lost" [https://news.ycombinator.com/item?id=2739995]
Linux distributions package applications (including binary ones) for their users, why can't macOS or Windows do this? Run automatic safety checks on them before deploying updates to users. The Windows Store and Apple's App Store (on macOS) are kind of like that, but they only have applications that developers chose to put there. I don't see Linux distributions asking developers for permission to package their application (there are proprietary packages on Arch and NixOS), so I don't see why Apple couldn't do the same.
Certificates are a bureaucratic half-solution.
For unprotected directories like Library/Keychains, programs can just copy the encrypted database. Since the malware obtains the keychain password with a fake password prompt, it can decrypt the database.
GasBuddy ("GasBuddy Is a Privacy Nightmare")[0] is a case in point. Geolocating users and selling that to everyone. Harvesting users' driving habits then selling those to Allstate subsidiary Arity ("turning mobility and driver data into meaningful behavioral insights, leveraging telematics to make transportation smarter, safer, and more useful for everyone!"). (But there's an opt-out!)
So are fitness apps and trackers. Private equity loves acquiring them.
Permissions can be abused in ways that aren't made obvious to users. Obvious example: just because you disable "location access", doesn't mean the app can't (indirectly) geolocate you in a variety of sneaky ways.
Even if the app doesn't intentionally crash if you disable its location access: indirectly geolocating users indirectly from IP addresses or metadata on photos they upload. Device fingerprinting from motion sensors, so that you can track a unique user across networks and devices, and develop "behavioral insights". And on and on.
Your idea would defeat the purpose of signing , which is to trust the delivery. If a company was sharing their signing certificate, nobody would know it came from you, and it would take just one malicious person also using that certificate to get everyone’s apps pulled.
In Windows and Linux any application also can read any user's file. And in Chrome and Firefox, any extension can read browser history, capture key presses and so on. If you install Python packages, they can do anything to your computer, if you download a plugin for Gimp the same issue exists. On desktop security is broken since forever. OS developers (especially Linux developers) cannot innovate and use outdated security model from 80s where users are isolated from each other but today most computers have a single user and it makes little sense. Today you need to isolate program from a program, and prevent them from fingerprinting user's device (for example, in Linux any app can read MAC addresses, hardware serial numbers, list of nearby WiFi points and nobody cares about that).
Surely you mean any root application? Or is my understanding of the Linux security model completely incorrect?
> And in Chrome and Firefox, any extension can read browser history, capture key presses and so on
Also no, extensions have different privileges you must accept. There are lots of problems with that security model, but it doesn't any extension can do those things
Indeed, that security command was definitely a misnomer.
However these days it's not as easy, you get a pop-up for every app that wants to access the keychain.
The bigger problem though is that Apple resorts to pop-ups way too much. Installing a new Mac with my work stuff I get 30 of them. This causes fatigue and totally fails to solve the problem.
In fact it does the exact same thing that Apple blamed Vista for in their Mac vs PC ad. In fact macOS is worse now than Vista ever was. https://youtu.be/VuqZ8AqmLPY
While there are some drawbacks in that you wouldn't be able share files/clipboard as easily, there are more ways to ensure more complete isolation.
I could forsee containerization being much more prone to social engineering of a novice non-technical user (i.e. stealing the clipboard, accidentally giving file access, etc.)
HN: "Apple products are so insecure, you can run anything on them!"
Also HN: "Apple products are too locked down. I can't run anything on them!"
tbh I think they're already doing the best option:
>ignore the OS warning that the code isn’t signed
OSX ships with "run unsigned apps" completely disabled by default, so normally that option won't even be presented.
You can of course socially engineer someone to run it anyway, by changing that system setting... but you'll never stop social engineering entirely. It's always a question of what degree you'll go to, not if it's possible or not.
I’m behind the upgrade curve, so I had to look this up to see if it’s changed but it hasn’t. The default still allows running unsigned apps without any configuration change. You just have to know how to do it, which is a pretty good sensible default. If you don’t know how, it’s a trivial search away.
> so normally that option won't even be presented.
Which is why it’s a good sensible default. Most users who don’t know how to work around it won’t bother, and they’ll benefit from it. The rest of us who do know how will take a brief pause to consider the risk before disregarding the warning.
The people who will just blanket turn off the protection are either very confident in their own risk assessment capabilities because they should be, or because they wouldn’t be protected by any mechanism whatsoever.
Now I’m pissed, because having endured the ordeal that was exporting the keychain, when migrating off of it to a proper password manager, I would have sworn it was already impossible to do so in any practical manner. Now I find out malware can do it? They’ve already made it nearly impossible to do legitimately!
Decades ago, when software warned users about potential dangers, they would either accept the risk or avoid it. Nowadays, software has been so infantilized that people expect a guaranteed positive outcome, even when ignoring warnings, while "free thinkers" online argue that every warning is a false positive.
Philosophically, I don't think we should cater to this mindset. If someone decides to fall prey to an evident scam or install malware on a critical system despite clear warnings, that's their prerogative. This principle holds true beyond just software.
I genuinely dislike the trend of dumbing down and infantilizing everything in the world. This includes simplifying education to stifle exceptional kids, prioritizing clickbait over nuanced news, the prevalence of exaggerated content on social media just because it's easier to consume, watered-down movies and music designed to exploit mass audiences, political populism obscuring real problems, a flood of shallow literature, and suppressing innovation in technology due to it being inherently risky (like the slow pace of space exploration-related advancements compared to the 1960s). Regrettably, software has not been spared from the "dumbing down" to accommodate the lowest common denominator. This philosophy leads to decadence, disempowerment, and a loss of richness in whatever field it infiltrates. In my view, it is regressive.
What has happened to critical thinking in recent decades? It used to be sufficient for us to navigate life despite a little danger, challenge, and risk. "Danger" should not be a shunned taboo concept, it is an inherent part of life.
In short, use critical thinking, don't listen to forums that say WhatsAppCracked100PercentSafe.apk/.dmg/.exe is not a security risk. Or take accountability for your actions if you still install it — it is your prerogative. But it shouldn't be anyone else's responsibility to make sure you don't harm yourself. Same as in other areas of life.
So, what should Apple do in response to such malware? Make it impossible for user code to read the entire keychain, even when running as admin? Containerize macOS more, making it impossible for user programs to access files written by other programs, in the way things work on iOS? Ignore it because, at some point, security becomes the user’s responsibility?
If tools like these get popular, I can see them getting blamed whatever they do or don’t do.