6 ms·

There's an endless stream of bypasses on macOS, because the operating system was never designed for these granular permissions. You can't just add them later, o

by lapcat 2y ago

There's an endless stream of bypasses on macOS, because the operating system was never designed for these granular permissions. You can't just add them later, on top of the legacy Mac OS and NeXTSTEP technologies. I've found a number of bypasses myself, and I'm not even a security researcher, just a longtime app developer. I know where the bodies are buried, so to speak. However, I ultimately gave up looking, because Apple's security vulnerability reporting system is absolute trash; their only interest seems to be to keep you quiet for as long as possible. It's a waste of time. My overall feeling is that macOS has become the victim of security theater, harming both users and legitimate developers with enfeedbled software and an endless stream of permissions requests—much like Apple's old parody of Windows Vista—while doing nothing to stop real attackers, who can easily bypass the security theater whenever they want.

CraigJPerry 2y ago
>> You can't just add them later, on top of the legacy Mac OS SELinux managed it, what's fundamentally stopping MacOS?
- result2vino 2y ago
  Can your grandma use SELinux? Delusional.
  - mu53 2y ago
    SELinux is for distro and package maintainers to use. Not end users.
    - lmz 2y ago
      And yet for a large number of years any RHEL/CentOS SELinux issues with third party software were answered with "disable SELinux".
      - homebrewer 2y ago
        Same for Windows' UAC in the Vista era, which doesn't make it bad technology or place the fault on Microsoft. The world is full of terrible development practices, the answer shouldn't be "just disable your security mechanisms".
        lmz 2y ago
        So you agree that end users do use it and are often incapable of getting the things they want to work with it?
      - snakeyjake 2y ago
        A large number of years up to and including "this year, right now, like, yesterday".
  - johnnyjeans 2y ago
    My Grandma doesn't have a need for backwards compatibility or the million other things that stop Apple from just making a new operating system. Normal people's use cases for their computer is light file management, light document and productivity workflows and everything else is done in the browser. Hell, most of the document processing and productivity crap is in the browser these days too.
    - lapcat 2y ago
      In other words, your grandma could use an iPad rather than a Mac.
      - bombcar 2y ago
        This is the real answer - 90% of people can use a phone or an iPad for their general computational needs - and the PC/Mac itself will trend toward that, with harder and harder gates to bypass to get a truly "general" computer.
      - smm11 2y ago
        Chromebooks, actually.
  - homebrewer 2y ago
    > delusional That's rather self critical of you, even if deserved. My grandma also can't write software, or really do anything advanced, no should she be able to. SELinux, just like any other security and/or containerization technology, is supposed to be used by developers, sysadmins, distribution maintainers. Not by end users. Is the macos sandbox the odd one out? I'm not familiar with it, but find it very hard to believe that "my grandma" is its target audience.
  - cyberax 2y ago
    If she has an Android phone, she's already using it.
- lapcat 2y ago
  There's a [dead] reply that you may not see, but frankly I kind of agree with it: "Can your grandma use SELinux? Delusional." https://news.ycombinator.com/item?id=42087188 https://news.ycombinator.com/item?id=42087188
  - nolist_policy 2y ago
    Android uses SELinux.
    - lapcat 2y ago
      So? You can't compare Android to macOS. Compare Android to iOS, which had many more limitations built-in from the start than macOS. Incidentally, this is why iPad has never become the desktop replacement everyone claimed it would be. The hardware is plenty powerful, but it's always been very limited by the software. The greater freedom and capabilities of macOS is a huge advantage for desktop-class functionality.
      - hollerith 2y ago
        I think I disagree. If iOS or Android added robust support for external monitors, external keyboards and pointing devices, I'd probably switch to it to get the increased resistance against attacks. If I could continue to run Emacs, e.g., in a VM like WSL2 or Crostini, I'd probably switch right away. If not, it would take me a year or 2 to transition to a replacement before I switch (and, no, that replacement would not need to be able to run software written in Emacs Lisp: I'd be happy to replace, rewrite or walk away from any functionality I currently get from code written in Emacs Lisp).
        nextos 2y ago
        I use Linux, I would not switch to Android, but I agree the Linux userland should take sandboxing much more seriously. Things like Firejail show it can be done without much friction for the user. The current model, where executables can access any user file or resource, needs to go. We haven't learned anything from e.g. compromised pip packages that stole ssh keys.
- lmz 2y ago
  Usability. And/or good taste.
  - CraigJPerry 2y ago
    Usability is apple’s thing. My AirPods just work, every Bluetooth headset before just annoyed. Why can’t they achieve usability in this space? To be honest, redhat’s solution is pretty darned usable - in the context of an enterprise Linux box(1). it helps that they built that database of policy profiles but even creating my own policy is pretty straightforward (3 commands + whatever it takes to make my app exercise all its code paths) (1) apples context is obviously different
- acdha 2y ago
  SELinux can be part of the solution but it doesn’t solve the problem. The median Linux system is far behind the median Mac because while SELinux exists you still have to craft fine-grained policies and deal with all of the exceptions needed to have the system still be usable. This is more a function of budget than anything else.
  - CraigJPerry 2y ago
    >> SELinux can be part of the solution but it doesn’t solve the problem Hold on that’s changing the goalposts a bit here. SELinux doesn’t solve this problem on RHEL boxes by virtue of just existing. It is the tool that Redhat uses to solve the problem. And they have solved the problem by using this tool. To the point that for years now, by default, RH boxes are installed in enforcing mode. >> The median Linux system is far behind the median Mac I’m not really interested in the median because for better or worse, Redhat is the most serious game in town for SELinux. Comparing Mac to RHEL, there’s only one place where Mac is ahead and that is a default Mac install at least on Apple silicon will have an immutable root. Redhat has irons in the fire here (rpm ostree can infuturue unlock a user friendly immutable root). Of course you can do immutable root today (and immutable usr and even epehemeral var if you want), but I’m not going to argue those are user friendly. An experienced sysadmin will take a minute to flip over between immutable root file systems during an upgrade process. >> This is more a function of budget than anything else. Agreed, but the Apple chequebook looks plenty beefy.
    - acdha 2y ago
      > And they have solved the problem by using this tool. To the point that for years now, by default, RH boxes are installed in enforcing mode. They’ve shipped it, yes. It doesn’t count as solved until all of the apps are running with policies which actually block attacks like this, just as having a fire extinguisher on the shelf doesn’t mean your fire is guaranteed to be out. > Comparing Mac to RHEL, there’s only one place where Mac is ahead and that is a default Mac install at least on Apple silicon will have an immutable root. Also they have far more common use of sandboxing for applications (including the harder bits about selective permissions for apps), code signing, memory protection, pervasive use of HSM and robust layered storage encryption, etc. – all out of the box, whereas even in the much easier case of servers you’re looking at many hours of skilled labor to configure an equivalent. My point about budgets is that this is just a lot of work. Apple’s not perfect but a lot of people have a mental model from the 2000s which is no longer true.
- nyrikki 2y ago
  Complete different set of tradeoffs. This is one of those situations where there is no good option, just the least worse option. SE had mostly servers, depends on package vendors being altruistic, and people mostly just disabled it when it caused problems. That is a very different set of assumptions and challenges than what Apple faces.
  - CraigJPerry 2y ago
    Agreed, I’m not suggesting selinux itself is the solution for Apple. I’m just saying faced with the same problem, and accepting that they have different usability constraints on them (sysadmins vs potentially novice computer users), another group found a solution. Why can’t Apple - they have the money to buy the engineering resource to bottom this out.
- throw0101a 2y ago
  > SELinux managed it Not when you have SELINUX=disabled (rather than SELINUX=enforcing), which is what I've seen in most environments. Personally I've had better experiences with AppArmour.
  - CraigJPerry 2y ago
    >> Not when you have SELINUX=disabled Yeah of course, but by default Redhat will install in enforcing mode. This is taking a horse to water, the drinking is left to the horse.
microtonal 2y ago
I think this legacy is a burden in all mainstream operating systems? There are capability-based system, but none of them have any traction. I am not sure what the solution is. Trying to bolt on security still seems better than doing nothing at all, where an application vulnerability immediately means a compromise of the a full user account?
- deleted 2y ago
  [deleted]
mike_hearn 2y ago
The researcher who wrote this article seems to have been able to get a lot of holes patched with credits, albeit, some of these CVEs seem years old. I guess a company wanting as much time as possible to fix bugs is a part of the game though, are other companies really keen for you to announce found vulns ASAP? They don't control how fast people upgrade so announcing slower is always better for end users, and that must ultimately take priority over the need of researchers for publicity. Isn't this something that one has to accept when finding holes in a consumer OS as an external? The Apple sandbox architecture seems well designed to me, usually at least. There seems to have been some breakdown in architecture or communication in this case. To the extent there are bypasses it's because we demand a lot of functionality from desktop operating systems, arguably they are the most sophisticated and complex kind of operating system out there - far more so than server platforms. Web browsers also have a lot of CVEs and it's for the same reason. We want security, but also functionality, and inevitably there's going to be a tension point in the middle where the two rub up against each other.
- lapcat 2y ago
  > The researcher who wrote this article seems to have been able to get a lot of holes patched with credits, albeit, some of these CVEs seem years old. Yes, it requires a lot of time and patience. And I bet that the researcher has more reported vulnerabilities that he can't talk about and aren't fixed. He's been doing this for many years. > I guess a company wanting as much time as possible to fix bugs is a part of the game though, are other companies really keen for you to announce found vulns ASAP? Apple is notorious for poor communication with security researchers... and with developers, and with everyone else. Apple also tends to patch vulnerabilities more slowly than, say, Google, and Apple frequently stiffs people on the security bounty.
  - bzzzt 2y ago
    > Apple frequently stiffs people on the security bounty. Having seen the receiving end of a bounty program of a relatively small SaaS business it's shocking to see how many people are abusing such a program with irrelevant or plain false 'vulnerabilities' and keep begging for a bounty (even when it's clearly stated it's impossible to send money to their countries). I can't imagine how many filters Apple has to employ to just get rid of the noise and get something of value from such a program.
CharlesW 2y ago
> You can't just add them later, on top of the legacy Mac OS and NeXTSTEP technologies. Apple can (and has been) since it owns the whole stack, evidenced by the fact that they've been gradually hardening macOS software and hardware for two decades. It's been gradual enough that most end users haven't noticed, but macOS developers are painfully aware of the security-related issues they have to reckon with in both major and minor updates to macOS. Example: https://eclecticlight.co/2024/08/27/launching-apps-in-sonoma-14-6-1-full-security/ https://eclecticlight.co/2024/08/28/launching-apps-in-sonoma-14-6-1-reduced-security/ https://eclecticlight.co/2024/08/29/launching-apps-in-sonoma-14-6-1-known-malware/ https://eclecticlight.co/2024/09/03/launching-apps-in-sonoma-14-6-1-conclusions/
- lapcat 2y ago
  > Apple can (and has been) since it owns the whole stack, evidenced by the fact that they've been gradually hardening macOS software and hardware for two decades. This is kind of an empty reply. Of course Apple can try and has been trying. The question is whether they can do it successfully, and I would argue it hasn't been successful. > It's been gradual enough that most end users haven't noticed This is not true at all. Users have definitely noticed all of the permissions dialogs and other related settings.
  - CharlesW 2y ago
    > The question is whether they can do it successfully, and I would argue it hasn't been successful. Security has no finish line, unfortunately. But here are a few security-related things Sequoia has that Mac OS X 10.0 did not: A firewall. VPN support. FileVault and FileVault 2. Secure Empty Trash. Increasingly-secure sandboxing. Library randomization. Address Space Layout Randomization. XProtect. Increasingly-secure versions of Gatekeeper. Increasingly-secure memory management. SIP. Kernel exploit mitigations. New update mechanisms for security patches. APFS and its associated security improvements. Notarization. Read-only system volume. Separation of user data and system files. Activation Lock. Improved system logging and auditing. Signed System Volume. Private Relay. Lockdown Mode. Visual indicators of mic/camera/location use. DriverKit to replace the use of kexts. Secure Enclave for hardware-based root of trust and secrets management. I'm just someone who pays attention. I imagine actual security experts could list 20+ other improvements off the top of their head.
cyberax 2y ago
That's because the reason for these limitations is to make it harder for the third-party developers to compete with Apple's products.
rustcleaner 2y ago
Responsible disclosure is immediate public disclosure with no embargoes. Embargoes are how we as users are absorbing the costs of poor security practices. If the culture was a no-warning publish culture, I would expect feature iteration and API breaks to slow down to more conservative levels as bikeshedding that stuff dwindles. Punish fast software development iteration with public embarrassment and lost users who got hosed by the vulnerability. If Apple or whoever start dicking around and not paying bounties, release it... or better yet: sell it on the darknet; you have got to be paid for your good work, and NSA/NSO are going to need more 0-day vulnerabilities with WWIII underway!

by lapcat 2y ago

CraigJPerry 2y ago

>> You can't just add them later, on top of the legacy Mac OS SELinux managed it, what's fundamentally stopping MacOS?

result2vino 2y ago
Can your grandma use SELinux? Delusional.
- mu53 2y ago
  SELinux is for distro and package maintainers to use. Not end users.
  - lmz 2y ago
    And yet for a large number of years any RHEL/CentOS SELinux issues with third party software were answered with "disable SELinux".
    - homebrewer 2y ago
      Same for Windows' UAC in the Vista era, which doesn't make it bad technology or place the fault on Microsoft. The world is full of terrible development practices, the answer shouldn't be "just disable your security mechanisms".
      - lmz 2y ago
        So you agree that end users do use it and are often incapable of getting the things they want to work with it?
    - snakeyjake 2y ago
      A large number of years up to and including "this year, right now, like, yesterday".
- johnnyjeans 2y ago
  My Grandma doesn't have a need for backwards compatibility or the million other things that stop Apple from just making a new operating system. Normal people's use cases for their computer is light file management, light document and productivity workflows and everything else is done in the browser. Hell, most of the document processing and productivity crap is in the browser these days too.
  - lapcat 2y ago
    In other words, your grandma could use an iPad rather than a Mac.
    - bombcar 2y ago
      This is the real answer - 90% of people can use a phone or an iPad for their general computational needs - and the PC/Mac itself will trend toward that, with harder and harder gates to bypass to get a truly "general" computer.
    - smm11 2y ago
      Chromebooks, actually.
- homebrewer 2y ago
  > delusional That's rather self critical of you, even if deserved. My grandma also can't write software, or really do anything advanced, no should she be able to. SELinux, just like any other security and/or containerization technology, is supposed to be used by developers, sysadmins, distribution maintainers. Not by end users. Is the macos sandbox the odd one out? I'm not familiar with it, but find it very hard to believe that "my grandma" is its target audience.
- cyberax 2y ago
  If she has an Android phone, she's already using it.
lapcat 2y ago
There's a [dead] reply that you may not see, but frankly I kind of agree with it: "Can your grandma use SELinux? Delusional." https://news.ycombinator.com/item?id=42087188 https://news.ycombinator.com/item?id=42087188
- nolist_policy 2y ago
  Android uses SELinux.
  - lapcat 2y ago
    So? You can't compare Android to macOS. Compare Android to iOS, which had many more limitations built-in from the start than macOS. Incidentally, this is why iPad has never become the desktop replacement everyone claimed it would be. The hardware is plenty powerful, but it's always been very limited by the software. The greater freedom and capabilities of macOS is a huge advantage for desktop-class functionality.
    - hollerith 2y ago
      I think I disagree. If iOS or Android added robust support for external monitors, external keyboards and pointing devices, I'd probably switch to it to get the increased resistance against attacks. If I could continue to run Emacs, e.g., in a VM like WSL2 or Crostini, I'd probably switch right away. If not, it would take me a year or 2 to transition to a replacement before I switch (and, no, that replacement would not need to be able to run software written in Emacs Lisp: I'd be happy to replace, rewrite or walk away from any functionality I currently get from code written in Emacs Lisp).
      - nextos 2y ago
        I use Linux, I would not switch to Android, but I agree the Linux userland should take sandboxing much more seriously. Things like Firejail show it can be done without much friction for the user. The current model, where executables can access any user file or resource, needs to go. We haven't learned anything from e.g. compromised pip packages that stole ssh keys.
lmz 2y ago
Usability. And/or good taste.
- CraigJPerry 2y ago
  Usability is apple’s thing. My AirPods just work, every Bluetooth headset before just annoyed. Why can’t they achieve usability in this space? To be honest, redhat’s solution is pretty darned usable - in the context of an enterprise Linux box(1). it helps that they built that database of policy profiles but even creating my own policy is pretty straightforward (3 commands + whatever it takes to make my app exercise all its code paths) (1) apples context is obviously different
acdha 2y ago
SELinux can be part of the solution but it doesn’t solve the problem. The median Linux system is far behind the median Mac because while SELinux exists you still have to craft fine-grained policies and deal with all of the exceptions needed to have the system still be usable. This is more a function of budget than anything else.
- CraigJPerry 2y ago
  >> SELinux can be part of the solution but it doesn’t solve the problem Hold on that’s changing the goalposts a bit here. SELinux doesn’t solve this problem on RHEL boxes by virtue of just existing. It is the tool that Redhat uses to solve the problem. And they have solved the problem by using this tool. To the point that for years now, by default, RH boxes are installed in enforcing mode. >> The median Linux system is far behind the median Mac I’m not really interested in the median because for better or worse, Redhat is the most serious game in town for SELinux. Comparing Mac to RHEL, there’s only one place where Mac is ahead and that is a default Mac install at least on Apple silicon will have an immutable root. Redhat has irons in the fire here (rpm ostree can infuturue unlock a user friendly immutable root). Of course you can do immutable root today (and immutable usr and even epehemeral var if you want), but I’m not going to argue those are user friendly. An experienced sysadmin will take a minute to flip over between immutable root file systems during an upgrade process. >> This is more a function of budget than anything else. Agreed, but the Apple chequebook looks plenty beefy.
  - acdha 2y ago
    > And they have solved the problem by using this tool. To the point that for years now, by default, RH boxes are installed in enforcing mode. They’ve shipped it, yes. It doesn’t count as solved until all of the apps are running with policies which actually block attacks like this, just as having a fire extinguisher on the shelf doesn’t mean your fire is guaranteed to be out. > Comparing Mac to RHEL, there’s only one place where Mac is ahead and that is a default Mac install at least on Apple silicon will have an immutable root. Also they have far more common use of sandboxing for applications (including the harder bits about selective permissions for apps), code signing, memory protection, pervasive use of HSM and robust layered storage encryption, etc. – all out of the box, whereas even in the much easier case of servers you’re looking at many hours of skilled labor to configure an equivalent. My point about budgets is that this is just a lot of work. Apple’s not perfect but a lot of people have a mental model from the 2000s which is no longer true.
nyrikki 2y ago
Complete different set of tradeoffs. This is one of those situations where there is no good option, just the least worse option. SE had mostly servers, depends on package vendors being altruistic, and people mostly just disabled it when it caused problems. That is a very different set of assumptions and challenges than what Apple faces.
- CraigJPerry 2y ago
  Agreed, I’m not suggesting selinux itself is the solution for Apple. I’m just saying faced with the same problem, and accepting that they have different usability constraints on them (sysadmins vs potentially novice computer users), another group found a solution. Why can’t Apple - they have the money to buy the engineering resource to bottom this out.
throw0101a 2y ago
> SELinux managed it Not when you have SELINUX=disabled (rather than SELINUX=enforcing), which is what I've seen in most environments. Personally I've had better experiences with AppArmour.
- CraigJPerry 2y ago
  >> Not when you have SELINUX=disabled Yeah of course, but by default Redhat will install in enforcing mode. This is taking a horse to water, the drinking is left to the horse.

microtonal 2y ago

I think this legacy is a burden in all mainstream operating systems? There are capability-based system, but none of them have any traction. I am not sure what the solution is. Trying to bolt on security still seems better than doing nothing at all, where an application vulnerability immediately means a compromise of the a full user account?

deleted 2y ago
[deleted]

mike_hearn 2y ago

The researcher who wrote this article seems to have been able to get a lot of holes patched with credits, albeit, some of these CVEs seem years old. I guess a company wanting as much time as possible to fix bugs is a part of the game though, are other companies really keen for you to announce found vulns ASAP? They don't control how fast people upgrade so announcing slower is always better for end users, and that must ultimately take priority over the need of researchers for publicity. Isn't this something that one has to accept when finding holes in a consumer OS as an external? The Apple sandbox architecture seems well designed to me, usually at least. There seems to have been some breakdown in architecture or communication in this case. To the extent there are bypasses it's because we demand a lot of functionality from desktop operating systems, arguably they are the most sophisticated and complex kind of operating system out there - far more so than server platforms. Web browsers also have a lot of CVEs and it's for the same reason. We want security, but also functionality, and inevitably there's going to be a tension point in the middle where the two rub up against each other.

lapcat 2y ago
> The researcher who wrote this article seems to have been able to get a lot of holes patched with credits, albeit, some of these CVEs seem years old. Yes, it requires a lot of time and patience. And I bet that the researcher has more reported vulnerabilities that he can't talk about and aren't fixed. He's been doing this for many years. > I guess a company wanting as much time as possible to fix bugs is a part of the game though, are other companies really keen for you to announce found vulns ASAP? Apple is notorious for poor communication with security researchers... and with developers, and with everyone else. Apple also tends to patch vulnerabilities more slowly than, say, Google, and Apple frequently stiffs people on the security bounty.
- bzzzt 2y ago
  > Apple frequently stiffs people on the security bounty. Having seen the receiving end of a bounty program of a relatively small SaaS business it's shocking to see how many people are abusing such a program with irrelevant or plain false 'vulnerabilities' and keep begging for a bounty (even when it's clearly stated it's impossible to send money to their countries). I can't imagine how many filters Apple has to employ to just get rid of the noise and get something of value from such a program.

CharlesW 2y ago

> You can't just add them later, on top of the legacy Mac OS and NeXTSTEP technologies. Apple can (and has been) since it owns the whole stack, evidenced by the fact that they've been gradually hardening macOS software and hardware for two decades. It's been gradual enough that most end users haven't noticed, but macOS developers are painfully aware of the security-related issues they have to reckon with in both major and minor updates to macOS. Example: https://eclecticlight.co/2024/08/27/launching-apps-in-sonoma-14-6-1-full-security/ https://eclecticlight.co/2024/08/28/launching-apps-in-sonoma-14-6-1-reduced-security/ https://eclecticlight.co/2024/08/29/launching-apps-in-sonoma-14-6-1-known-malware/ https://eclecticlight.co/2024/09/03/launching-apps-in-sonoma-14-6-1-conclusions/

lapcat 2y ago
> Apple can (and has been) since it owns the whole stack, evidenced by the fact that they've been gradually hardening macOS software and hardware for two decades. This is kind of an empty reply. Of course Apple can try and has been trying. The question is whether they can do it successfully, and I would argue it hasn't been successful. > It's been gradual enough that most end users haven't noticed This is not true at all. Users have definitely noticed all of the permissions dialogs and other related settings.
- CharlesW 2y ago
  > The question is whether they can do it successfully, and I would argue it hasn't been successful. Security has no finish line, unfortunately. But here are a few security-related things Sequoia has that Mac OS X 10.0 did not: A firewall. VPN support. FileVault and FileVault 2. Secure Empty Trash. Increasingly-secure sandboxing. Library randomization. Address Space Layout Randomization. XProtect. Increasingly-secure versions of Gatekeeper. Increasingly-secure memory management. SIP. Kernel exploit mitigations. New update mechanisms for security patches. APFS and its associated security improvements. Notarization. Read-only system volume. Separation of user data and system files. Activation Lock. Improved system logging and auditing. Signed System Volume. Private Relay. Lockdown Mode. Visual indicators of mic/camera/location use. DriverKit to replace the use of kexts. Secure Enclave for hardware-based root of trust and secrets management. I'm just someone who pays attention. I imagine actual security experts could list 20+ other improvements off the top of their head.

cyberax 2y ago

That's because the reason for these limitations is to make it harder for the third-party developers to compete with Apple's products.

rustcleaner 2y ago

Responsible disclosure is immediate public disclosure with no embargoes. Embargoes are how we as users are absorbing the costs of poor security practices. If the culture was a no-warning publish culture, I would expect feature iteration and API breaks to slow down to more conservative levels as bikeshedding that stuff dwindles. Punish fast software development iteration with public embarrassment and lost users who got hosed by the vulnerability. If Apple or whoever start dicking around and not paying bounties, release it... or better yet: sell it on the darknet; you have got to be paid for your good work, and NSA/NSO are going to need more 0-day vulnerabilities with WWIII underway!