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.
Okay, there's many problems with this post.<p>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<p>> System Integrity Protection status: enabled.<p>You can see here <a href="http://internals.exposed/blog/dtrace-vs-sip.html" rel="nofollow">http://internals.exposed/blog/dtrace-vs-sip.html</a> 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".<p>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.<p>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.
[Really easy to enable.](<a href="http://internals.exposed/blog/dtrace-vs-sip.html" rel="nofollow">http://internals.exposed/blog/dtrace-vs-sip.html</a>)<p>But, hey, sure. Don't let that stop you from getting angry. Merry Christmas.<p>There should be a bingo card for this thread. "#doomed" "taking away freedoms". Free space is "What Steve would've done".
"<i>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.</i>"<p>-– sas08<p><a href="http://apple.stackexchange.com/questions/193368/what-is-the-rootless-feature-in-el-capitan-really/208185#comment251806_208185" rel="nofollow">http://apple.stackexchange.com/questions/193368/what-is-the-...</a>
I think SIP in general is a good idea, but gives Apple the opportunity to abuse their market position, which historically they have.<p>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?
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.<p>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.
This and other developments around computer security and usability "for the everyman" worry me for two reasons.<p>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.<p>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.<p>The famous Apple 1984 ad feels more ironic every year.
> <i>DTrace is similar to ptrace/strace in Linux</i><p>No. It's 10000× more. <a href="http://www.dtracebook.com/" rel="nofollow">http://www.dtracebook.com/</a>
For everyone complaining about Apple taking away something or other that was important to you: please consider what SIP/"rootless" actually is.<p>What Apple have done here is not anything like the "dev mode" switch on Android, or the Gatekeeper "signed code only" setting. This change <i>isn't</i> another of the litany of changes that expand the gap between developers and regular users. This change is, instead, about creating a different <i>model</i> for how OS modifications happen.<p>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.<p>With SIP/rootless, Apple has effectively made it so that instead of the actively-running copy of the OS ever modifying <i>itself</i>, the OS will only ever modify <i>the other copy of the OS</i> 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 <i>recovery update</i> (i.e. an update to the recovery OS.)<p>The procedures for <i>getting around</i> SIP by disabling it and then running things, are as arcane as they are because they're quite divorced from the <i>reason</i> 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.<p>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.<p>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.<p>---<p>† 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.<p>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.<p>If there <i>is</i> 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.
I don't really see the big deal here, you ~just have to disable SIP to make dtrace works again fully, right?<p>I guess it can be an issue if in the future Apple decides to no longer allow us to officially disable SIP.
Glad I dropped MacOS. Looks like today, I can't even build a hackintosh without first disabling SIP.<p>Lion pissed me off when they removed Spaces/Expose with that Mission Control rubbish. It's only gone downhill with each new release.
The author of that post should have included references.<p>1. If it does not work (dr race), then why is it still present?<p>2. He states root is gone, but not gone; LOL please explain or give us a link with more details.<p>3. Even if this is true, it's not going to slow us down much. We will continue with business, as usual.