Hacker News Reader

> is that MacOS allows any command to read the entire contents of your keychain (yes, with all your passwords).

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

> Linux any application also can read any user's file

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

The default permissions are up to the distro(umask settings), but AFAIK most use 0644 by default, making every home folder readable by every user.

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

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

Custom keychains are also available if you worry about malware dumping unlocked keychain data via kernel privilege escalation (to bypass ACLs). For critical items that you decrypt once a year, it doesn't make much sense to use the resident login and iCloud keychains.

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.

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

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.

> 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

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?

Access is gated upon `/usr/bin/security`, not the Terminal app.

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.

>Warnings like this are useless when they bundle genuinely dodgy software along with software from legitimate companies I already trust and know.

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.

Where does GP suggest any new restrictions at all?

I think it's entirely fair to say that their post essentially summarizes as "what we currently have is probably not enough" and ends in an implied "maybe we need more [though I would personally rankle at it]". So in some ways they did.

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-accidentally-trigger-able ways around it seems roughly ideal IMO.

I think OSX hits that balance 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. It's both effective and friendly, and going further in either direction seems like it requires major sacrifices in the other. And when you do want those sacrifices, you can get them (non-admin account or disable it entirely).

> No auth, no checks, just full access via the `security` command.

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

To sign your software you need to dox yourself to your users and pay a fee for a cert. I think there should be organizations that will sign open source software for you with their certificate, not sure if this is allowed.

Why otherwise would end-users trust individual developers or tiny orgs, esp. from countries without much rule of law? What else gives your users assurance a binary isn't bundled with adware, malware, trojans, or privacy compromises, either now or won't sneakily be at any time in the future when the developers might cash out to some unknown org, or else simply want to generate a sneaky new revenue stream without their users' informed consent?

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]

[3]: https://hn.algolia.com/?q=sourceforge

Do what mobile OS do and make the app ask for permissions just before it needs to do something special. Make it impossible to ask for root. Sandbox apps.

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.

macOS already does all of that for all programs. I think the main problem here is that macOS only protects certain directories and not others. Programs can request access to Documents or Downloads, or they can request full-disk access (e.g. to read Library/Messages).

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.

That's an aspiration. It's not what Android does these days. Mobile OS permissions (at least Android) have become pretty weaselly. Protecting you from malware blatantly asking for root is obviously very important. Sandboxing is important. But the sneakier use of permissions for privacy exploits and data harvesting is different and more subtle.

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.

[0]: https://news.ycombinator.com/item?id=30636730

How does signing dox you? It doesn’t really include much in the way of identifiable information

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.