39 ms·

I find this comment amazing: https://github.com/shadowsocks/shadowsocks-iOS/issues/124#issuecomment-119921778 https://github.com/shadowsocks/shadowsocks-iOS/is

I find this comment amazing: https://github.com/shadowsocks/shadowsocks-iOS/issues/124#issuecomment-119921778 https://github.com/shadowsocks/shadowsocks-iOS/issues/124#is... Even with root account, you are not in full control of your Mac - you are sandboxed by Apple.

conradev 11y ago
This is the result of a recent change in OS X 10.11, called System Integrity Protection. It's a big step in the wrong direction [opinion], especially because it does nothing to verify "integrity". It prevents changes to the System directory by conventional means (and injection into system processes). If malware were to figure out a way to disable SIP from userland, it could install itself in such a way that nothing short of disabling SIP could uninstall it.
- userbinator 11y ago
  Does booting an alternate OS still work to get around it, or have Apple thought of that route and somehow blocked it too? (I have limited experience with OS X - only briefly played around with driver development and bootloaders in the 10.4 era with osx86 - and I did have to boot from the DVD a few times when I made the system unbootable.) This raises the question, what good is root if it's not really root anymore?
  - comex 11y ago
    There is a supported option to disable SIP from recovery mode, so there's no need to get around it per se. (Recovery mode because it would be hard to impossible to verify the user's intent when malware that already has root privileges is running...)
  - __david__ 11y ago
    > Does booting an alternate OS still work to get around it, or have Apple thought of that route and somehow blocked it too? It's easier than that. It's just a kernel argument to disable it. Simply add "rootless=0" to your boot-args and you have control of your machine back. I'm running the 10.11 beta and I've already had to disable rootless because I like to have /usr/local as a symlink to somewhere else and by default the rootless configuration prevents writes to /usr. :-/
    - brobinson 11y ago
      Does this break homebrew? Or does it only block writes to entries in /usr and not subdirectories like /usr/local ?
      - __david__ 11y ago
        You are allowed to write to /usr/local. But making /usr/local itself into a symlink requires writing to /usr which is prohibited. So I was screwed but for the normal case it should work fine.
    - bdash 11y ago
      Apple has stated that the "rootless=0" boot argument to disable System Integrity Protection is temporary and will be gone in the GM version of El Capitan. Allowing this route to disable the feature would defeat the entire purpose of it.
      - mrpippy 11y ago
        Source? They said in the WWDC session (http://asciiwwdc.com/2015/sessions/706 http://asciiwwdc.com/2015/sessions/706) that the process to disable rootless may change during the beta, but didn't say that it won't be possible in the GM. They know that rootless will break some applications/drivers, plus some types of development may need it disabled.
        bdash 11y ago
        The supported mechanism for disabling System Integrity Protection is via the recovery partition.
      - arthurfm 11y ago
        Apple have recently made a few changes to how you enable/disable System Integrity Protection... https://www.reddit.com/r/osx/comments/3hv3kk/update_on_rootless_the_configuration_mechanism/ https://www.reddit.com/r/osx/comments/3hv3kk/update_on_rootl...
  - pdkl95 11y ago
    This has been the plan for several years. I remember seeing block diagrams for GlobalPlatform's Trusted Execution Environment[1] that were based on the idea of the "Rich OS" (OSX, Linux, etc) being able to run more or less normally, with something that isn't really a hypervisor providing the "secure"/"trusted" environment. The idea is that a combination of a SecureBoot-style trusted boot sequence and technologies like Intel's SGX instructions to create an area that is protected from everything else, root included. Ever since (heavily controlled) iOS was accepted by the tech crowd as a replacement for a proper General Purpose Computer, we've been slowly loosing more and more control. At least there seems to be workarounds for this particular OSX "feature". It is incredibly important to stop this trend now; it will be a lot harder to work around these restrictions when it gets hardware support. [1] http://i.imgur.com/rjbzWyB.jpg http://i.imgur.com/rjbzWyB.jpg
- comex 11y ago
  If you have some malware that actually needs to modify system files, that still significantly ups the ante. Sure, if you have a kernel exploit, you can do it, but currently malware does not need any exploits to take over a system if it can convince a user to download and type in their password to install - Gatekeeper is one mechanism to prevent this, but I've personally been served multiple ads offering malware with a valid Developer ID signature, so it's tricky... (though I don't know how aggressively Apple is working to revoke their certificates). The difference in skill required between just writing an installer disguised as legitimate software on one hand, and continuously coming up with working exploits on the other, is pretty huge. And in any case, the easiest-to-exploit OS X privilege escalation vulnerabilities are things like rootpipe that don't compromise the kernel. However, this argument falls down a little if malware doesn't actually need to modify system files, which it doesn't for most typical evil stuff I can think of.
  - x0 11y ago
    what if some os x malware finds a way past the limitations on editing system files? the malware would become undeletable
    - gilgoomesh 11y ago
      It wouldn't be undeletable, it would just involve booting into a recovery volume (either the automatic Apple recovery partition or a user supplied volume). Since all System locations will now be signed (as part of the move to SIP), it means that the basic Apple recovery partition will be able to purge any such malware by a simple signature verification.
      - comex 11y ago
        Does it actually do that? I haven't heard of it... But just reinstalling the OS accomplishes the same, slightly less quickly. Of course, if the malware is nasty enough, it might modify user settings to make a program run automatically, e.g., by adding it as a startup item, which, unless that OS reinstall included a patch, could then exploit the bug again and reinstall itself to the system locations. Not much Apple can do about that.
- nailer 11y ago
  How do SIP and dtrace interact?
  - gilgoomesh 11y ago
    From https://developer.apple.com/videos/wwdc/2015/?id=706 https://developer.apple.com/videos/wwdc/2015/?id=706 "all dtrace probes that target a system restricted process will not be matched" (i.e. will fail unless SIP is disabled).
- beedogs 11y ago
  Not really surprising, though: Apple has been making OS X a little worse with every iteration.
  - speeder 11y ago
    I am doing my best to NOT update my OSX, every time I update it, the thing get slower, it is really annoying.
    - Synaesthesia 11y ago
      El-Cap is the fastest version yet in my experience and seems to be getting important security fixes too.
  - krylon 11y ago
    Tell me about it. I recently bit the bullet and upgraded to 10.10 after waiting for quite a while. Man... Firefox has been crashing regularly since then, the Mail.app will also crash every now and then, and to top it off, the system itself has crashed twice on me over the past... two weeks. Sigh
    - suprfnk 11y ago
      Try installing a fresh copy, or do some HDD/RAM checks. I have been running 10.10 since it came out (+Firefox) without any problems.
- eridius 11y ago
  But that's the thing, you can't disable SIP from userland. It can only be disabled when booted into recovery mode. So yes, it absolutely does verify integrity, because it makes it so malware cannot embed itself into the system. Your last sentence there is 100% pure grade A FUD. You may as well just say "every security measure is bullshit, because if malware were to figure a way around it, then it wouldn't work". It's a meaningless statement.
  - conradev 11y ago
    It's a boot argument to the kernel, stored in NVRAM. These arguments are normally mutable. Apple had to write code to prevent modifying said arguments. Said code can have flaws. But lets say you don't find a vulnerability in SIP userland detection, and instead find a kernel exploit to get around the protection: If malware were to figure a way around it, then even antivirus software can't uninstall it. Only Apple can. It's not FUD.
    - gilgoomesh 11y ago
      It is FUD since it is not impossible to make these changes, it's just (intentionally) more difficult than casually supplying a sudo password. Anyone can detect signature changes in a system directory and anyone can boot to a recovery volume (either the default Apple one or one provided by an anti-virus company, if desired) to make whatever corrective change they want.
    - eridius 11y ago
      This is absolutely FUD. Even if you're correct and malware finds a way around it, then it obviously doesn't work, which means antivirus software could use the same mechanism to kick out the malware.
      - Qwertious 11y ago
        Unless the malware uses the backdoor/exploit then patches it out once it's inside. It has complete system control, after all.
    - 11y ago
- superuser2 11y ago
  >nothing short of disabling SIP could uninstall it At the very least, the OS needs to be reinstalled from an off-disk source, and that's assuming you haven't been hit by something sophisticated enough to put itself in firmware. We're fast approaching an era where you need to trash the hardware. You should never trust an OS install that was ever compromised, and making it more difficult to do so is a good thing in my book.
- elcct 11y ago
  Windows 10, now OS X... and meanwhile I have installed Linux on all my workstations. Looks like big corporations are shooting themselves in the foot.
rsync 11y ago
Wow. OSX ... it was nice knowing you.
eridius 11y ago
This is an iOS app, not a Mac app.
- geofft 11y ago
  Yes, but from the same commenter earlier: "I want to try this api on MAC OS 10.11. I understand the reason why I need to ask apple for some permission to publish the app with this api to app store, but I can't believe that I have to ask them for permission to run this api on my development machine."
  - eridius 11y ago
    It's possible that commenter is misguided. The documentation on NETunnelProviderManager[1] says it needs the extension and that you should send an email to get it, but there's no indication as to whether there's anything stopping you from granting yourself this entitlement on a development machine (obviously Apple needs to approve it for an app on the MAS; I don't know what limitations there are for non-MAS apps in this regard). [1] https://developer.apple.com/library/prerelease/mac/documentation/NetworkExtension/Reference/NETunnelProviderManagerClassRef/index.html https://developer.apple.com/library/prerelease/mac/documenta...
    - eridius 11y ago
      Where by "extension" I of course meant to say "entitlement".
MagerValp 11y ago
I think you have that backwards. You, as the person with physical access, is in full control as SIP can be controlled from recovery mode. Processes running as root are no longer trusted to have full access to the system. This is definitely a step in the right direction.

conradev 11y ago

This is the result of a recent change in OS X 10.11, called System Integrity Protection. It's a big step in the wrong direction [opinion], especially because it does nothing to verify "integrity". It prevents changes to the System directory by conventional means (and injection into system processes). If malware were to figure out a way to disable SIP from userland, it could install itself in such a way that nothing short of disabling SIP could uninstall it.

userbinator 11y ago
Does booting an alternate OS still work to get around it, or have Apple thought of that route and somehow blocked it too? (I have limited experience with OS X - only briefly played around with driver development and bootloaders in the 10.4 era with osx86 - and I did have to boot from the DVD a few times when I made the system unbootable.) This raises the question, what good is root if it's not really root anymore?
- comex 11y ago
  There is a supported option to disable SIP from recovery mode, so there's no need to get around it per se. (Recovery mode because it would be hard to impossible to verify the user's intent when malware that already has root privileges is running...)
- __david__ 11y ago
  > Does booting an alternate OS still work to get around it, or have Apple thought of that route and somehow blocked it too? It's easier than that. It's just a kernel argument to disable it. Simply add "rootless=0" to your boot-args and you have control of your machine back. I'm running the 10.11 beta and I've already had to disable rootless because I like to have /usr/local as a symlink to somewhere else and by default the rootless configuration prevents writes to /usr. :-/
  - brobinson 11y ago
    Does this break homebrew? Or does it only block writes to entries in /usr and not subdirectories like /usr/local ?
    - __david__ 11y ago
      You are allowed to write to /usr/local. But making /usr/local itself into a symlink requires writing to /usr which is prohibited. So I was screwed but for the normal case it should work fine.
  - bdash 11y ago
    Apple has stated that the "rootless=0" boot argument to disable System Integrity Protection is temporary and will be gone in the GM version of El Capitan. Allowing this route to disable the feature would defeat the entire purpose of it.
    - mrpippy 11y ago
      Source? They said in the WWDC session (http://asciiwwdc.com/2015/sessions/706 http://asciiwwdc.com/2015/sessions/706) that the process to disable rootless may change during the beta, but didn't say that it won't be possible in the GM. They know that rootless will break some applications/drivers, plus some types of development may need it disabled.
      - bdash 11y ago
        The supported mechanism for disabling System Integrity Protection is via the recovery partition.
    - arthurfm 11y ago
      Apple have recently made a few changes to how you enable/disable System Integrity Protection... https://www.reddit.com/r/osx/comments/3hv3kk/update_on_rootless_the_configuration_mechanism/ https://www.reddit.com/r/osx/comments/3hv3kk/update_on_rootl...
- pdkl95 11y ago
  This has been the plan for several years. I remember seeing block diagrams for GlobalPlatform's Trusted Execution Environment[1] that were based on the idea of the "Rich OS" (OSX, Linux, etc) being able to run more or less normally, with something that isn't really a hypervisor providing the "secure"/"trusted" environment. The idea is that a combination of a SecureBoot-style trusted boot sequence and technologies like Intel's SGX instructions to create an area that is protected from everything else, root included. Ever since (heavily controlled) iOS was accepted by the tech crowd as a replacement for a proper General Purpose Computer, we've been slowly loosing more and more control. At least there seems to be workarounds for this particular OSX "feature". It is incredibly important to stop this trend now; it will be a lot harder to work around these restrictions when it gets hardware support. [1] http://i.imgur.com/rjbzWyB.jpg http://i.imgur.com/rjbzWyB.jpg
comex 11y ago
If you have some malware that actually needs to modify system files, that still significantly ups the ante. Sure, if you have a kernel exploit, you can do it, but currently malware does not need any exploits to take over a system if it can convince a user to download and type in their password to install - Gatekeeper is one mechanism to prevent this, but I've personally been served multiple ads offering malware with a valid Developer ID signature, so it's tricky... (though I don't know how aggressively Apple is working to revoke their certificates). The difference in skill required between just writing an installer disguised as legitimate software on one hand, and continuously coming up with working exploits on the other, is pretty huge. And in any case, the easiest-to-exploit OS X privilege escalation vulnerabilities are things like rootpipe that don't compromise the kernel. However, this argument falls down a little if malware doesn't actually need to modify system files, which it doesn't for most typical evil stuff I can think of.
- x0 11y ago
  what if some os x malware finds a way past the limitations on editing system files? the malware would become undeletable
  - gilgoomesh 11y ago
    It wouldn't be undeletable, it would just involve booting into a recovery volume (either the automatic Apple recovery partition or a user supplied volume). Since all System locations will now be signed (as part of the move to SIP), it means that the basic Apple recovery partition will be able to purge any such malware by a simple signature verification.
    - comex 11y ago
      Does it actually do that? I haven't heard of it... But just reinstalling the OS accomplishes the same, slightly less quickly. Of course, if the malware is nasty enough, it might modify user settings to make a program run automatically, e.g., by adding it as a startup item, which, unless that OS reinstall included a patch, could then exploit the bug again and reinstall itself to the system locations. Not much Apple can do about that.
nailer 11y ago
How do SIP and dtrace interact?
- gilgoomesh 11y ago
  From https://developer.apple.com/videos/wwdc/2015/?id=706 https://developer.apple.com/videos/wwdc/2015/?id=706 "all dtrace probes that target a system restricted process will not be matched" (i.e. will fail unless SIP is disabled).
beedogs 11y ago
Not really surprising, though: Apple has been making OS X a little worse with every iteration.
- speeder 11y ago
  I am doing my best to NOT update my OSX, every time I update it, the thing get slower, it is really annoying.
  - Synaesthesia 11y ago
    El-Cap is the fastest version yet in my experience and seems to be getting important security fixes too.
- krylon 11y ago
  Tell me about it. I recently bit the bullet and upgraded to 10.10 after waiting for quite a while. Man... Firefox has been crashing regularly since then, the Mail.app will also crash every now and then, and to top it off, the system itself has crashed twice on me over the past... two weeks. Sigh
  - suprfnk 11y ago
    Try installing a fresh copy, or do some HDD/RAM checks. I have been running 10.10 since it came out (+Firefox) without any problems.
eridius 11y ago
But that's the thing, you can't disable SIP from userland. It can only be disabled when booted into recovery mode. So yes, it absolutely does verify integrity, because it makes it so malware cannot embed itself into the system. Your last sentence there is 100% pure grade A FUD. You may as well just say "every security measure is bullshit, because if malware were to figure a way around it, then it wouldn't work". It's a meaningless statement.
- conradev 11y ago
  It's a boot argument to the kernel, stored in NVRAM. These arguments are normally mutable. Apple had to write code to prevent modifying said arguments. Said code can have flaws. But lets say you don't find a vulnerability in SIP userland detection, and instead find a kernel exploit to get around the protection: If malware were to figure a way around it, then even antivirus software can't uninstall it. Only Apple can. It's not FUD.
  - gilgoomesh 11y ago
    It is FUD since it is not impossible to make these changes, it's just (intentionally) more difficult than casually supplying a sudo password. Anyone can detect signature changes in a system directory and anyone can boot to a recovery volume (either the default Apple one or one provided by an anti-virus company, if desired) to make whatever corrective change they want.
  - eridius 11y ago
    This is absolutely FUD. Even if you're correct and malware finds a way around it, then it obviously doesn't work, which means antivirus software could use the same mechanism to kick out the malware.
    - Qwertious 11y ago
      Unless the malware uses the backdoor/exploit then patches it out once it's inside. It has complete system control, after all.
  - 11y ago
superuser2 11y ago
>nothing short of disabling SIP could uninstall it At the very least, the OS needs to be reinstalled from an off-disk source, and that's assuming you haven't been hit by something sophisticated enough to put itself in firmware. We're fast approaching an era where you need to trash the hardware. You should never trust an OS install that was ever compromised, and making it more difficult to do so is a good thing in my book.
elcct 11y ago
Windows 10, now OS X... and meanwhile I have installed Linux on all my workstations. Looks like big corporations are shooting themselves in the foot.

rsync 11y ago

Wow. OSX ... it was nice knowing you.

eridius 11y ago

This is an iOS app, not a Mac app.

geofft 11y ago
Yes, but from the same commenter earlier: "I want to try this api on MAC OS 10.11. I understand the reason why I need to ask apple for some permission to publish the app with this api to app store, but I can't believe that I have to ask them for permission to run this api on my development machine."
- eridius 11y ago
  It's possible that commenter is misguided. The documentation on NETunnelProviderManager[1] says it needs the extension and that you should send an email to get it, but there's no indication as to whether there's anything stopping you from granting yourself this entitlement on a development machine (obviously Apple needs to approve it for an app on the MAS; I don't know what limitations there are for non-MAS apps in this regard). [1] https://developer.apple.com/library/prerelease/mac/documentation/NetworkExtension/Reference/NETunnelProviderManagerClassRef/index.html https://developer.apple.com/library/prerelease/mac/documenta...
  - eridius 11y ago
    Where by "extension" I of course meant to say "entitlement".

MagerValp 11y ago

I think you have that backwards. You, as the person with physical access, is in full control as SIP can be controlled from recovery mode. Processes running as root are no longer trusted to have full access to the system. This is definitely a step in the right direction.