4 ms·

This basically tells about the state of computer security in general. There is no isolation of OS from applications, or between the applications. This is by d

This basically tells about the state of computer security in general. There is no isolation of OS from applications, or between the applications. This is by design, dated back to early unix times. We will continue to see these issues until there is a brand new OS which isolates subsystems by design. That is, each application/process gets not only own address space, but own file system, own settings store, with the OS carefully managing cross-boundary accesses.

mixedCase 7y ago
From TFA: > When SIP was enabled—as it is by default—SIP worked as designed and prevented the change. When the protection was disabled, however, the file system was modified in a way that prevented Macs from rebooting.
- java-man 7y ago
  what is the rationale for disabling SIP? not only there should be no way to disable this protection, it should be a deliberate design goal to prevent any process or application from accessing protected areas.
  - saagarjha 7y ago
    > what is the reationale for disabling SIP? Loading unsigned drivers for eGPUs. > not only there should be no way to disable this protection, it should be a deliberate design goal to prevent any process or application from accessing protected areas. I think you're looking for iOS.
    - java-man 7y ago
      iOS: https://www.cvedetails.com/product/15556/Apple-Iphone-Os.html?vendor_id=49 https://www.cvedetails.com/product/15556/Apple-Iphone-Os.htm... loading dev drivers should be done differently, and limited to dev, not production. the fact that one needs to disable security feature in production indicates a bad design. i.e. the user may explicitly allow loading of particular objects (using hashes).
      - saagarjha 7y ago
        I don't understand why you're linking to a CVE list.
  - httpsterio 7y ago
    Some gpus need SIP on off because the drivers won't run else. I generally also have to disable it because I run some apps and modify some underlying behaviours in macOS that I find undesirable. I don't think it should be any worse than running stuff as sudo on Unix, where you can easily break the whole OS if you, as the user, don't know what you're doing. Chrome had a bug and even if it wouldn't have broken the system had SIP been enabled, it's still a serious bug on chrome's side.
  - protomyth 7y ago
    Perhaps if Apple would let us self-sign drivers on our computers, we wouldn't need to disable SIP. Security that does not allow the actual use of the computer gets disabled.
    - EricE 7y ago
      Exactly. Apple still hasn't come to terms with balancing security with functionality.
    - dreamcompiler 7y ago
      Yes, 100% this. SIP is badly designed because it's a global hammer like root. As such, it prevents power users from doing quite legitimate things with their computers and so we have to turn it off. SIP should work like sudo, not like meta-root.
    - GeekyBear 7y ago
      You can whitelist a kext. https://eclecticlight.co/2019/06/01/how-to-bypass-mojave-10-14-5s-new-kext-security/amp/ https://eclecticlight.co/2019/06/01/how-to-bypass-mojave-10-...
      - saagarjha 7y ago
        I'm fairly sure this only applies to KEXTs that are signed but not notarized.
  - damnyou 7y ago
    Sometimes you want to do things that the OS maker does not want you to do, like run dtrace on system binaries. If you had no recourse to bypass the OS maker, the world would be a much worse place.
bjtitus 7y ago
So iOS?
- java-man 7y ago
  right. https://www.cvedetails.com/product/15556/Apple-Iphone-Os.html?vendor_id=49 https://www.cvedetails.com/product/15556/Apple-Iphone-Os.htm...
  - bjtitus 7y ago
    No one said isolation solves all security vulnerabilities. I'm not sure what else you'd expect from one of the most widely used software platforms ever made.
- curt15 7y ago
  Or Flatpak? Firefox is making progress on that front: https://bugzilla.mozilla.org/show_bug.cgi?id=1441922 https://bugzilla.mozilla.org/show_bug.cgi?id=1441922
overgard 7y ago
So.. containers.
- java-man 7y ago
  https://www.cvedetails.com/vulnerability-list/vendor_id-13534/Docker.html https://www.cvedetails.com/vulnerability-list/vendor_id-1353... Total number of vulnerabilities : 26
kps 7y ago
The problem with that — for users — is that it is likely to lead to the phone-style data roach motel, where applications control users' content and hold it hostage from them.
coryrc 7y ago
Programmers developed containers and kubernetes to cover this space, but we haven't created a consumer OS with programs each in their own container.
- wozer 7y ago
  Android ist a bit like this, isn't it?
  - techntoke 7y ago
    Not really. Containers run natively and use the built in kernel features to sandbox. Android uses the Java VM.
    - java-man 7y ago
      Android aside, the use of JVM might offer a better alternative (because of bytecode validation). One way to achieve security is to enforce what an application/process can do is via specialized interfaces. For example, java.io.File will only see a virtual application filesystem, and one would need to grant special permissions (via a different interface) for file access outside of the app sandbox. These permissions should be controlled (and audited) by the user. Possibly at more levels than currently (blocked/allowed always/while running).
      - monocasa 7y ago
        That was tried by the sun JVM, and worked until they tacked on reflection. Then there was just too many ways to break the sandbox when the sandbox is implemented just like your code is and you've got a mechanism for doing brain surgery on the process. Every time they'd fix a applet sandbox escape two more exploits would pop up.
        java-man 7y ago
        Security must be the primary design goal, at least right now. I don't think the way Sun implemented permissions in java offers enough protection.

mixedCase 7y ago

From TFA: > When SIP was enabled—as it is by default—SIP worked as designed and prevented the change. When the protection was disabled, however, the file system was modified in a way that prevented Macs from rebooting.

java-man 7y ago
what is the rationale for disabling SIP? not only there should be no way to disable this protection, it should be a deliberate design goal to prevent any process or application from accessing protected areas.
- saagarjha 7y ago
  > what is the reationale for disabling SIP? Loading unsigned drivers for eGPUs. > not only there should be no way to disable this protection, it should be a deliberate design goal to prevent any process or application from accessing protected areas. I think you're looking for iOS.
  - java-man 7y ago
    iOS: https://www.cvedetails.com/product/15556/Apple-Iphone-Os.html?vendor_id=49 https://www.cvedetails.com/product/15556/Apple-Iphone-Os.htm... loading dev drivers should be done differently, and limited to dev, not production. the fact that one needs to disable security feature in production indicates a bad design. i.e. the user may explicitly allow loading of particular objects (using hashes).
    - saagarjha 7y ago
      I don't understand why you're linking to a CVE list.
- httpsterio 7y ago
  Some gpus need SIP on off because the drivers won't run else. I generally also have to disable it because I run some apps and modify some underlying behaviours in macOS that I find undesirable. I don't think it should be any worse than running stuff as sudo on Unix, where you can easily break the whole OS if you, as the user, don't know what you're doing. Chrome had a bug and even if it wouldn't have broken the system had SIP been enabled, it's still a serious bug on chrome's side.
- protomyth 7y ago
  Perhaps if Apple would let us self-sign drivers on our computers, we wouldn't need to disable SIP. Security that does not allow the actual use of the computer gets disabled.
  - EricE 7y ago
    Exactly. Apple still hasn't come to terms with balancing security with functionality.
  - dreamcompiler 7y ago
    Yes, 100% this. SIP is badly designed because it's a global hammer like root. As such, it prevents power users from doing quite legitimate things with their computers and so we have to turn it off. SIP should work like sudo, not like meta-root.
  - GeekyBear 7y ago
    You can whitelist a kext. https://eclecticlight.co/2019/06/01/how-to-bypass-mojave-10-14-5s-new-kext-security/amp/ https://eclecticlight.co/2019/06/01/how-to-bypass-mojave-10-...
    - saagarjha 7y ago
      I'm fairly sure this only applies to KEXTs that are signed but not notarized.
- damnyou 7y ago
  Sometimes you want to do things that the OS maker does not want you to do, like run dtrace on system binaries. If you had no recourse to bypass the OS maker, the world would be a much worse place.

bjtitus 7y ago

So iOS?

java-man 7y ago
right. https://www.cvedetails.com/product/15556/Apple-Iphone-Os.html?vendor_id=49 https://www.cvedetails.com/product/15556/Apple-Iphone-Os.htm...
- bjtitus 7y ago
  No one said isolation solves all security vulnerabilities. I'm not sure what else you'd expect from one of the most widely used software platforms ever made.
curt15 7y ago
Or Flatpak? Firefox is making progress on that front: https://bugzilla.mozilla.org/show_bug.cgi?id=1441922 https://bugzilla.mozilla.org/show_bug.cgi?id=1441922

overgard 7y ago

So.. containers.

java-man 7y ago
https://www.cvedetails.com/vulnerability-list/vendor_id-13534/Docker.html https://www.cvedetails.com/vulnerability-list/vendor_id-1353... Total number of vulnerabilities : 26

kps 7y ago

The problem with that — for users — is that it is likely to lead to the phone-style data roach motel, where applications control users' content and hold it hostage from them.

coryrc 7y ago

Programmers developed containers and kubernetes to cover this space, but we haven't created a consumer OS with programs each in their own container.

wozer 7y ago
Android ist a bit like this, isn't it?
- techntoke 7y ago
  Not really. Containers run natively and use the built in kernel features to sandbox. Android uses the Java VM.
  - java-man 7y ago
    Android aside, the use of JVM might offer a better alternative (because of bytecode validation). One way to achieve security is to enforce what an application/process can do is via specialized interfaces. For example, java.io.File will only see a virtual application filesystem, and one would need to grant special permissions (via a different interface) for file access outside of the app sandbox. These permissions should be controlled (and audited) by the user. Possibly at more levels than currently (blocked/allowed always/while running).
    - monocasa 7y ago
      That was tried by the sun JVM, and worked until they tacked on reflection. Then there was just too many ways to break the sandbox when the sandbox is implemented just like your code is and you've got a mechanism for doing brain surgery on the process. Every time they'd fix a applet sandbox escape two more exploits would pop up.
      - java-man 7y ago
        Security must be the primary design goal, at least right now. I don't think the way Sun implemented permissions in java offers enough protection.