6 ms·

> It lures users to download the software, run it, ignore the OS warning that the code isn’t signed, and then enter their password. Warnings like this are usel

by ghusto 4y ago

> It lures users to download the software, run it, ignore the OS warning that the code isn’t signed, and then enter their password. 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?

Groxx 4y ago
>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.
- Kinrany 4y ago
  Where does GP suggest any new restrictions at all?
  - Groxx 4y ago
    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).
js2 4y ago
> 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-on-mac-keychains 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-protection-secb0694df1a/web https://support.apple.com/guide/security/keychain-data-prote... https://support.apple.com/guide/security/icloud-keychain-security-overview-sec1c89c6f3b/web https://support.apple.com/guide/security/icloud-keychain-sec...
- dvzk 4y ago
  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.
- js2 4y ago
  > 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.
tempaccount420 4y ago
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.
- deleted 4y ago
  [deleted]
- smcin 4y ago
  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 https://en.wikipedia.org/wiki/SourceForge#Controversies] [1]: "A Cautionary Tale from the Decline of SourceForge" [https://news.ycombinator.com/item?id=31110206 https://news.ycombinator.com/item?id=31110206] [2]: "Why SourceForge Lost" [https://news.ycombinator.com/item?id=2739995 https://news.ycombinator.com/item?id=2739995] [3]: https://hn.algolia.com/?q=sourceforge https://hn.algolia.com/?q=sourceforge
  - tempaccount420 4y ago
    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.
codedokode 4y ago
> 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).
- pcthrowaway 4y ago
  > 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
  - silisili 4y ago
    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.
wkat4242 4y ago
> 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 https://youtu.be/VuqZ8AqmLPY

by ghusto 4y ago

Groxx 4y ago

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

Kinrany 4y ago
Where does GP suggest any new restrictions at all?
- Groxx 4y ago
  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).

js2 4y ago

> 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-on-mac-keychains 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-protection-secb0694df1a/web https://support.apple.com/guide/security/keychain-data-prote... https://support.apple.com/guide/security/icloud-keychain-security-overview-sec1c89c6f3b/web https://support.apple.com/guide/security/icloud-keychain-sec...

dvzk 4y ago
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.
js2 4y ago
> 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.

tempaccount420 4y ago

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.

deleted 4y ago
[deleted]
smcin 4y ago
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 https://en.wikipedia.org/wiki/SourceForge#Controversies] [1]: "A Cautionary Tale from the Decline of SourceForge" [https://news.ycombinator.com/item?id=31110206 https://news.ycombinator.com/item?id=31110206] [2]: "Why SourceForge Lost" [https://news.ycombinator.com/item?id=2739995 https://news.ycombinator.com/item?id=2739995] [3]: https://hn.algolia.com/?q=sourceforge https://hn.algolia.com/?q=sourceforge
- tempaccount420 4y ago
  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.

codedokode 4y ago

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

pcthrowaway 4y ago
> 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
- silisili 4y ago
  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.

wkat4242 4y ago

> 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 https://youtu.be/VuqZ8AqmLPY