7 ms·

“Rootless” feature in El Capitan means DTrace no longer works

88 points by Cieplak 11y ago

Cieplak 11y ago
"I think the answer speaks plainly and precisely to a good part of the question, which is how the experience of using a shell as root will change. Sudo is now pseudo sudo." -– sas08 http://apple.stackexchange.com/questions/193368/what-is-the-rootless-feature-in-el-capitan-really/208185#comment251806_208185 http://apple.stackexchange.com/questions/193368/what-is-the-...
djsumdog 11y ago
Glad I dropped MacOS. Looks like today, I can't even build a hackintosh without first disabling SIP. Lion pissed me off when they removed Spaces/Expose with that Mission Control rubbish. It's only gone downhill with each new release.
meesterdude 11y ago
Yet another move by apple to take away your control over your own machine. Some parts of the filesystem become off limits, even as root. But installers have access! That's kinda nuts. Obviously: most users wont care or notice. But when you combine this with other changes apple has made; it's clear where they're taking OS X: just as unfriendly to tinkering and exploration as their hardware.
- ryannielsen 11y ago
  > Some parts of the filesystem become off limits, even as root. But installers have access! Point of clarification: only Apple-signed installers can modify system paths. (c.f. https://support.apple.com/en-us/HT204899 https://support.apple.com/en-us/HT204899) All other installers are subject to SIP restrictions. And Apple only added a few simple steps for people eager to tinker: reboot and disable SIP. Or reboot into the installer for the other OS with which you prefer to tinker. Or create a VM with an experimental OS. Frankly, most of those steps existed before SIP. Most users shouldn't care or notice, and will benefit from increased protection. People who want to tinker will (and can and should!) tinker.
zw 11y ago
[Really easy to enable.](http://internals.exposed/blog/dtrace-vs-sip.html http://internals.exposed/blog/dtrace-vs-sip.html) But, hey, sure. Don't let that stop you from getting angry. Merry Christmas. There should be a bingo card for this thread. "#doomed" "taking away freedoms". Free space is "What Steve would've done".
- michael_h 11y ago
  TFA addressed that. For the regular folk, this will be fine. For security researchers, it's a big flag that will let malware change its behavior. He also posted a handy screenshot that shows Dtrace not working on some binaries even with SIP completely off.
  - HappyTypist 11y ago
    SIP is turned on in the screenshot. > System Integrity Protection status: enabled.
    - deleted 11y ago
      [deleted]
    - michael_h 11y ago
      Ack, you're correct. SIP is on, but everything is disabled.
TechnoJoe 11y ago
The author of that post should have included references. 1. If it does not work (dr race), then why is it still present? 2. He states root is gone, but not gone; LOL please explain or give us a link with more details. 3. Even if this is true, it's not going to slow us down much. We will continue with business, as usual.
yifanlu 11y ago
Okay, there's many problems with this post. First, most people do not need to use dtrace. Especially on system processes. They claim that this is bad for security researchers because they can't monitor the system anymore and they showed a screenshot of dtrace not working even with SIP "disabled". However, from the screenshot, we see that SIP is, in fact not disabled because of this line > System Integrity Protection status: enabled. You can see here http://internals.exposed/blog/dtrace-vs-sip.html http://internals.exposed/blog/dtrace-vs-sip.html that with SIP properly disabled, you can run dtrace on system processes. Yes, it's confusing that it says "DTrace restrictions: disabled", when it should say "some dtrace restrictions". Also, no security researcher worth their salt would be stopped by this (and no "bad guy" would be stopped from debugging either). In fact, dtrace is only a convenience and one tool in a toolbox; you have VMs with kernel level debuggers. You have object code analysis. You have wireshark and so on. If Apple can't stop people from jailbreaking their iphones (where hardware enforces the lockdown), they won't stop people from debugging their PC's kernel. Basically, SIP is good for users (the "Ultimately this means that Apple has replaced the 'be all and end all' security barrier of the root password, with the 'be all and end all' SIP protection mechanism." argument is the same as "we shouldn't outlaw guns because people will find other ways of killing each other") since it makes compromising a system all that harder. If it hinders ANY security research, I question the skills of that researcher.
- aftbit 11y ago
  He did make one point that you've failed to address: > Disabling SIP tells all software, from both the bad guys and Apple, that this system is being watched. No more watching the watchers. You're right, there are other tools. However, this definitely increases the barrier to entry for performing analysis of software.
  - tptacek 11y ago
    If you disable SIP and take over the kernel, you can probably trick software --- from both the bad guys and Apple --- into believing whatever you'd like.
  - yifanlu 11y ago
Cieplak 11y ago
I didn't mean to be alarmist by posting this. I actually think SIP is probably a good thing. I just wanted to raise awareness so folks don't get bitten by it. I ran into this issue earlier trying to benchmark IO performance of my software on bare metal rather than in vagrant. Unfortunately, it seems iotop and iosnoop are broken unless I press this big red button that only experts can press to disable SIP, when all I want to do is a little system profiling. Maybe Activity Monitor has a scripting API I don't know about. I'm just kind of annoyed by this, I would rather dual boot into Linux than having to restart into Recovery Mode to get basic IO profiling. I can understand that DTrace could be a privilege escalation risk, but maybe Apple has an official recommendation for how to properly use DTrace or an analogous API. `iostat` doesn't cut it because I'm looking at a specific process which is run under my user. I'm not using dtrace to reverse engineer system libraries. (I think) Apple already compiles dtrace with hooks so that it won't trace specific processes to mitigate reverse engineering, which I can deal with. But hell, even `htop` is totally wrong now as I compare it to what Activity Monitor is showing.
- kogir 11y ago
  You only need to boot into recovery mode once to change the setting, not every time. Turning it off isn't a big deal, and you have a valid reason to do so. Most users never need any of the functionality restricted by SIP, and will benefit from the greater security it provides. Every step forward in exploit mitigation is usually a tradeoff - NX broke some programs. ASLR broke others. SIP is no different.
  - Cieplak 11y ago
    Personally I think I like having SIP. It means a webkit zero-day can't as easily load a kernel extension or edit firmware. I guess DTrace works by putting probes into other processes, so even though it is only "reading" system information, it's only able to instrument the data it reads in the first place by mutating other running processes.
  - gdavisson 11y ago
    You can also selectively disable the dtrace restrictions, while leaving the other SIP restrictions intact, with "csrutil enable --without dtrace" (in Recovery mode).
aftbit 11y ago
This and other developments around computer security and usability "for the everyman" worry me for two reasons. First, they're taking away the "hard edges" from the system and helping create a generation of computer users who don't know how to tinker, how the inner bits work, or how to take responsibility for their own actions. If they download a virus, that's somehow Apple's fault for not developing a secure enough system. If they use an emoticon in their only root account password with FileVault enabled, it's Apple's fault that they are now locked out of their machine. Second, and more worryingly, this works towards the "appification" of computers. The user's freedom to run whatever software they want on the desktop is a powerful check against the walled garden "app store" model where a central group (i.e. Apple) is responsible for determining what you're allowed to do. That's bad for innovation and freedom. The famous Apple 1984 ad feels more ironic every year.
- pdkl95 11y ago
  Exactly. Apple is responsible for a huge loss of freedom in the War On General Purpose Computing. This "appification" is exactly what Cory Doctorow was talking about in his famous essay[1]. We are already beginning to see some of the nastier effects that we warned about[2] with, for example, John Deere's attempt to retain ownership[3]. Apologists will complain that you can turn of SIP (or jailbreak your phone) to regain control over your computer, but that isn't possible for most people. Installing certain types of software went from "run the installer" to "follow these complicated technical instructions" (or worse). What I find more worrying is how easily technical people are fooled into supporting this loss of freedom. Scream "security" and suddenly it's ok for Apple to have root but not the supposed "owner" of the device? Of course, they know how to disable the restrictions or install a jailbreak, so these problems don't apply to the technological priesthood - it's normal people that have to live with the restrictions. Well, this hubris will not last - once Apple can starts using the new Trusted Computing[4] features on new CPUs (such as SGX[5]), good luck regaining control. It would be nice if more people actually bothered thinking about long-term consequences. [1] http://boingboing.net/2012/01/10/lockdown.html http://boingboing.net/2012/01/10/lockdown.html [2] https://www.youtube.com/watch?v=nypRYpVKc5Y https://www.youtube.com/watch?v=nypRYpVKc5Y [3] http://www.wired.com/2015/04/dmca-ownership-john-deere/ http://www.wired.com/2015/04/dmca-ownership-john-deere/ [4] one example: http://i.imgur.com/rjbzWyB.jpg http://i.imgur.com/rjbzWyB.jpg [5] https://news.ycombinator.com/item?id=10754170 https://news.ycombinator.com/item?id=10754170
exabrial 11y ago
I think SIP in general is a good idea, but gives Apple the opportunity to abuse their market position, which historically they have. On a side note, I've been developing on a Mac for years. Is there any Linux distributions with a UI and directory utilities as polished as OSX?
- on_and_off 11y ago
  http://elementary.io/ http://elementary.io/ & http://www.linuxmint.com/ http://www.linuxmint.com/ are the two distros I often hear about. I have not tested them myself though, I might someday if OsX becomes too closed-up to be useful for my needs. Even with all the random problems I had with the first version of El Capitan, I doubt that a linux distro can rival the polish of OsX though. Of course, I would love to be wrong.
Daishiman 11y ago
Once again, Stallman was right: in the name of security, manufacturers proceed in the war against general computing.
- beedogs 11y ago
  Which is cold comfort to those of us who knew all along he was right.
- pas 11y ago
  He is right, but the market is still king. If you can't give efficiency to users by your more general computing platform than the walled-restricted one, then you'll be left resourceless, hence powerless, thus unable to defend your ideas any more. Stallman is right, but he doesn't seem to be the solution.
derefr 11y ago
For everyone complaining about Apple taking away something or other that was important to you: please consider what SIP/"rootless" actually is. What Apple have done here is not anything like the "dev mode" switch on Android, or the Gatekeeper "signed code only" setting. This change isn't another of the litany of changes that expand the gap between developers and regular users. This change is, instead, about creating a different model for how OS modifications happen. For a while now, there have been two copies of OSX on a Mac: the "regular use" one, and the "recovery" partition. Both are full OSX, and can run arbitrary OSX software; it's basically like having a copy of the Linux Live CD you installed Linux from copied to your disk alongside the actual Linux install. With SIP/rootless, Apple has effectively made it so that instead of the actively-running copy of the OS ever modifying itself, the OS will only ever modify the other copy of the OS on-disk. So you need to have the recovery OS running to modify the files of the "regular use" OS†; and you need to be running in the "regular use" OS to apply a recovery update (i.e. an update to the recovery OS.) The procedures for getting around SIP by disabling it and then running things, are as arcane as they are because they're quite divorced from the reason for SIP. SIP isn't supposed to be a system for blocking and whitelisting kernel-hooking apps; it's a mechanism for making the OS into something more like CoreOS or the Wii's IOS: a system with two separate on-disc OS images, where at least one is always a Last-Known-Good configuration, and where you reboot into the "spare" one when you want to replace the previously-"active" one. You never fiddle with the "in-use" OS image; you consider it locked. You still have root on the computer. You just have to be in OS-A to do root-level things to OS-B, and vice-versa. An analogy: remember how it was impossible (and still is, on some OSes) to resize the boot partition you're running from, requiring you to instead boot from a USB to do that? That's basically what is happening here, except without the need for the USB. You can't do stupid things to the active OS; it's locked. You modify the OS by mounting it as a slave from another copy of the OS. --- † I'm not actually sure how system updates from the "regular use" side work with SIP enabled. They could have a special exception in the SIP infrastructure, but I doubt it. I would guess they work like iOS updates do: the update package gets downloaded by the running OS, and then a UEFI flag is written to tell the OS to reboot into the recovery OS in "update" mode. The recovery OS then unpacks and shoves the update, and reboots back. If there is an exception in SIP for the Installer, it was likely considered more as an optimization over the above process—something to avoid making OSX feel like Windows XP, rebooting five times to get anything done.
lelf 11y ago
> DTrace is similar to ptrace/strace in Linux No. It's 10000× more. http://www.dtracebook.com/ http://www.dtracebook.com/
hartator 11y ago
I don't really see the big deal here, you ~just have to disable SIP to make dtrace works again fully, right? I guess it can be an issue if in the future Apple decides to no longer allow us to officially disable SIP.
coldtea 11y ago
>If SIP was about security they could have educated users about root - instead they removed it. Yeah, because this would work....

88 points by Cieplak 11y ago

"I think the answer speaks plainly and precisely to a good part of the question, which is how the experience of using a shell as root will change. Sudo is now pseudo sudo." -– sas08 http://apple.stackexchange.com/questions/193368/what-is-the-rootless-feature-in-el-capitan-really/208185#comment251806_208185 http://apple.stackexchange.com/questions/193368/what-is-the-...

djsumdog 11y ago

Glad I dropped MacOS. Looks like today, I can't even build a hackintosh without first disabling SIP. Lion pissed me off when they removed Spaces/Expose with that Mission Control rubbish. It's only gone downhill with each new release.

meesterdude 11y ago

Yet another move by apple to take away your control over your own machine. Some parts of the filesystem become off limits, even as root. But installers have access! That's kinda nuts. Obviously: most users wont care or notice. But when you combine this with other changes apple has made; it's clear where they're taking OS X: just as unfriendly to tinkering and exploration as their hardware.

ryannielsen 11y ago
> Some parts of the filesystem become off limits, even as root. But installers have access! Point of clarification: only Apple-signed installers can modify system paths. (c.f. https://support.apple.com/en-us/HT204899 https://support.apple.com/en-us/HT204899) All other installers are subject to SIP restrictions. And Apple only added a few simple steps for people eager to tinker: reboot and disable SIP. Or reboot into the installer for the other OS with which you prefer to tinker. Or create a VM with an experimental OS. Frankly, most of those steps existed before SIP. Most users shouldn't care or notice, and will benefit from increased protection. People who want to tinker will (and can and should!) tinker.

zw 11y ago

[Really easy to enable.](http://internals.exposed/blog/dtrace-vs-sip.html http://internals.exposed/blog/dtrace-vs-sip.html) But, hey, sure. Don't let that stop you from getting angry. Merry Christmas. There should be a bingo card for this thread. "#doomed" "taking away freedoms". Free space is "What Steve would've done".

michael_h 11y ago
TFA addressed that. For the regular folk, this will be fine. For security researchers, it's a big flag that will let malware change its behavior. He also posted a handy screenshot that shows Dtrace not working on some binaries even with SIP completely off.
- HappyTypist 11y ago
  SIP is turned on in the screenshot. > System Integrity Protection status: enabled.
  - deleted 11y ago
    [deleted]
  - michael_h 11y ago
    Ack, you're correct. SIP is on, but everything is disabled.

TechnoJoe 11y ago

The author of that post should have included references. 1. If it does not work (dr race), then why is it still present? 2. He states root is gone, but not gone; LOL please explain or give us a link with more details. 3. Even if this is true, it's not going to slow us down much. We will continue with business, as usual.

yifanlu 11y ago

Okay, there's many problems with this post. First, most people do not need to use dtrace. Especially on system processes. They claim that this is bad for security researchers because they can't monitor the system anymore and they showed a screenshot of dtrace not working even with SIP "disabled". However, from the screenshot, we see that SIP is, in fact not disabled because of this line > System Integrity Protection status: enabled. You can see here http://internals.exposed/blog/dtrace-vs-sip.html http://internals.exposed/blog/dtrace-vs-sip.html that with SIP properly disabled, you can run dtrace on system processes. Yes, it's confusing that it says "DTrace restrictions: disabled", when it should say "some dtrace restrictions". Also, no security researcher worth their salt would be stopped by this (and no "bad guy" would be stopped from debugging either). In fact, dtrace is only a convenience and one tool in a toolbox; you have VMs with kernel level debuggers. You have object code analysis. You have wireshark and so on. If Apple can't stop people from jailbreaking their iphones (where hardware enforces the lockdown), they won't stop people from debugging their PC's kernel. Basically, SIP is good for users (the "Ultimately this means that Apple has replaced the 'be all and end all' security barrier of the root password, with the 'be all and end all' SIP protection mechanism." argument is the same as "we shouldn't outlaw guns because people will find other ways of killing each other") since it makes compromising a system all that harder. If it hinders ANY security research, I question the skills of that researcher.

aftbit 11y ago
He did make one point that you've failed to address: > Disabling SIP tells all software, from both the bad guys and Apple, that this system is being watched. No more watching the watchers. You're right, there are other tools. However, this definitely increases the barrier to entry for performing analysis of software.
- tptacek 11y ago
  If you disable SIP and take over the kernel, you can probably trick software --- from both the bad guys and Apple --- into believing whatever you'd like.
- yifanlu 11y ago

Cieplak 11y ago

I didn't mean to be alarmist by posting this. I actually think SIP is probably a good thing. I just wanted to raise awareness so folks don't get bitten by it. I ran into this issue earlier trying to benchmark IO performance of my software on bare metal rather than in vagrant. Unfortunately, it seems iotop and iosnoop are broken unless I press this big red button that only experts can press to disable SIP, when all I want to do is a little system profiling. Maybe Activity Monitor has a scripting API I don't know about. I'm just kind of annoyed by this, I would rather dual boot into Linux than having to restart into Recovery Mode to get basic IO profiling. I can understand that DTrace could be a privilege escalation risk, but maybe Apple has an official recommendation for how to properly use DTrace or an analogous API. `iostat` doesn't cut it because I'm looking at a specific process which is run under my user. I'm not using dtrace to reverse engineer system libraries. (I think) Apple already compiles dtrace with hooks so that it won't trace specific processes to mitigate reverse engineering, which I can deal with. But hell, even `htop` is totally wrong now as I compare it to what Activity Monitor is showing.

kogir 11y ago
You only need to boot into recovery mode once to change the setting, not every time. Turning it off isn't a big deal, and you have a valid reason to do so. Most users never need any of the functionality restricted by SIP, and will benefit from the greater security it provides. Every step forward in exploit mitigation is usually a tradeoff - NX broke some programs. ASLR broke others. SIP is no different.
- Cieplak 11y ago
  Personally I think I like having SIP. It means a webkit zero-day can't as easily load a kernel extension or edit firmware. I guess DTrace works by putting probes into other processes, so even though it is only "reading" system information, it's only able to instrument the data it reads in the first place by mutating other running processes.
- gdavisson 11y ago
  You can also selectively disable the dtrace restrictions, while leaving the other SIP restrictions intact, with "csrutil enable --without dtrace" (in Recovery mode).

aftbit 11y ago

This and other developments around computer security and usability "for the everyman" worry me for two reasons. First, they're taking away the "hard edges" from the system and helping create a generation of computer users who don't know how to tinker, how the inner bits work, or how to take responsibility for their own actions. If they download a virus, that's somehow Apple's fault for not developing a secure enough system. If they use an emoticon in their only root account password with FileVault enabled, it's Apple's fault that they are now locked out of their machine. Second, and more worryingly, this works towards the "appification" of computers. The user's freedom to run whatever software they want on the desktop is a powerful check against the walled garden "app store" model where a central group (i.e. Apple) is responsible for determining what you're allowed to do. That's bad for innovation and freedom. The famous Apple 1984 ad feels more ironic every year.

pdkl95 11y ago
Exactly. Apple is responsible for a huge loss of freedom in the War On General Purpose Computing. This "appification" is exactly what Cory Doctorow was talking about in his famous essay[1]. We are already beginning to see some of the nastier effects that we warned about[2] with, for example, John Deere's attempt to retain ownership[3]. Apologists will complain that you can turn of SIP (or jailbreak your phone) to regain control over your computer, but that isn't possible for most people. Installing certain types of software went from "run the installer" to "follow these complicated technical instructions" (or worse). What I find more worrying is how easily technical people are fooled into supporting this loss of freedom. Scream "security" and suddenly it's ok for Apple to have root but not the supposed "owner" of the device? Of course, they know how to disable the restrictions or install a jailbreak, so these problems don't apply to the technological priesthood - it's normal people that have to live with the restrictions. Well, this hubris will not last - once Apple can starts using the new Trusted Computing[4] features on new CPUs (such as SGX[5]), good luck regaining control. It would be nice if more people actually bothered thinking about long-term consequences. [1] http://boingboing.net/2012/01/10/lockdown.html http://boingboing.net/2012/01/10/lockdown.html [2] https://www.youtube.com/watch?v=nypRYpVKc5Y https://www.youtube.com/watch?v=nypRYpVKc5Y [3] http://www.wired.com/2015/04/dmca-ownership-john-deere/ http://www.wired.com/2015/04/dmca-ownership-john-deere/ [4] one example: http://i.imgur.com/rjbzWyB.jpg http://i.imgur.com/rjbzWyB.jpg [5] https://news.ycombinator.com/item?id=10754170 https://news.ycombinator.com/item?id=10754170

exabrial 11y ago

I think SIP in general is a good idea, but gives Apple the opportunity to abuse their market position, which historically they have. On a side note, I've been developing on a Mac for years. Is there any Linux distributions with a UI and directory utilities as polished as OSX?

on_and_off 11y ago
http://elementary.io/ http://elementary.io/ & http://www.linuxmint.com/ http://www.linuxmint.com/ are the two distros I often hear about. I have not tested them myself though, I might someday if OsX becomes too closed-up to be useful for my needs. Even with all the random problems I had with the first version of El Capitan, I doubt that a linux distro can rival the polish of OsX though. Of course, I would love to be wrong.

Daishiman 11y ago

Once again, Stallman was right: in the name of security, manufacturers proceed in the war against general computing.

beedogs 11y ago
Which is cold comfort to those of us who knew all along he was right.
pas 11y ago
He is right, but the market is still king. If you can't give efficiency to users by your more general computing platform than the walled-restricted one, then you'll be left resourceless, hence powerless, thus unable to defend your ideas any more. Stallman is right, but he doesn't seem to be the solution.

derefr 11y ago

For everyone complaining about Apple taking away something or other that was important to you: please consider what SIP/"rootless" actually is. What Apple have done here is not anything like the "dev mode" switch on Android, or the Gatekeeper "signed code only" setting. This change isn't another of the litany of changes that expand the gap between developers and regular users. This change is, instead, about creating a different model for how OS modifications happen. For a while now, there have been two copies of OSX on a Mac: the "regular use" one, and the "recovery" partition. Both are full OSX, and can run arbitrary OSX software; it's basically like having a copy of the Linux Live CD you installed Linux from copied to your disk alongside the actual Linux install. With SIP/rootless, Apple has effectively made it so that instead of the actively-running copy of the OS ever modifying itself, the OS will only ever modify the other copy of the OS on-disk. So you need to have the recovery OS running to modify the files of the "regular use" OS†; and you need to be running in the "regular use" OS to apply a recovery update (i.e. an update to the recovery OS.) The procedures for getting around SIP by disabling it and then running things, are as arcane as they are because they're quite divorced from the reason for SIP. SIP isn't supposed to be a system for blocking and whitelisting kernel-hooking apps; it's a mechanism for making the OS into something more like CoreOS or the Wii's IOS: a system with two separate on-disc OS images, where at least one is always a Last-Known-Good configuration, and where you reboot into the "spare" one when you want to replace the previously-"active" one. You never fiddle with the "in-use" OS image; you consider it locked. You still have root on the computer. You just have to be in OS-A to do root-level things to OS-B, and vice-versa. An analogy: remember how it was impossible (and still is, on some OSes) to resize the boot partition you're running from, requiring you to instead boot from a USB to do that? That's basically what is happening here, except without the need for the USB. You can't do stupid things to the active OS; it's locked. You modify the OS by mounting it as a slave from another copy of the OS. --- † I'm not actually sure how system updates from the "regular use" side work with SIP enabled. They could have a special exception in the SIP infrastructure, but I doubt it. I would guess they work like iOS updates do: the update package gets downloaded by the running OS, and then a UEFI flag is written to tell the OS to reboot into the recovery OS in "update" mode. The recovery OS then unpacks and shoves the update, and reboots back. If there is an exception in SIP for the Installer, it was likely considered more as an optimization over the above process—something to avoid making OSX feel like Windows XP, rebooting five times to get anything done.

lelf 11y ago

> DTrace is similar to ptrace/strace in Linux No. It's 10000× more. http://www.dtracebook.com/ http://www.dtracebook.com/

hartator 11y ago

I don't really see the big deal here, you ~just have to disable SIP to make dtrace works again fully, right? I guess it can be an issue if in the future Apple decides to no longer allow us to officially disable SIP.

coldtea 11y ago

>If SIP was about security they could have educated users about root - instead they removed it. Yeah, because this would work....