3 ms·

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.

by 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).
tristanj 11y ago
I think it's great you've shared this. With the recent SIP changes, thousands of Stack Overflow guides that involve "running a few commands with sudo" are now potentially broken. If devs/users are unfamiliar with this change, they might follow an out-of-date guide and become stuck for hours. It almost happened to me last week when I tried following a stack overflow post to fix some symlink issues with /usr/bin/. Fortunately I read about SIP previously on HN and was able to work around it. But I'm worried for the thousands of other devs that haven't heard of or encountered SIP. There needs to be more awareness of this change because it affects much more than people expect. Takeaway: if you're following a OS X guide that involves sudo written before 10.11, keep SIP in mind or you might get burned.
- ryannielsen 11y ago
  I'm idly curious: what were your "symlink issues with /usr/bin/"? As with other unices, /usr is system-owned and anything not under the /usr/local hierarchy may be modified or destroyed during OS upgrades. Very few people should ever need to disable SIP – and that includes almost all developers! Are you building/running unsigned kexts? No? Then you almost certainly don't need to disable SIP. Most instructions that no longer work with SIP enabled should be modified so they don't conflict with SIP. As a bonus: changes resulting from those instructions are far more likely to be preserved across OS X upgrades.
  - vitd 11y ago
    One completely normal developer thing I need to do that involved turning off SIP is setting library and framework paths to debug an executable outside of Xcode. We archive our daily builds so we can regress problems to a specific check-in. Now I could just roll back my source and build from that, but that takes significantly longer than just copying the regression build from the server. (Not to mention that if the revision is old enough, I need to install an older OS and Xcode just to build it.) But our archives are straight out of an Xcode development build - they contain separate libraries and frameworks that we build and that aren't moved into the executable like during an install. So to run them from a disk image you need to set DYLD_LIBRARY_PATH and DYLD_FRAMEWORK_PATH to get the OS to know where to look for them. But this doesn't work with SIP. This is not some low-level kext-related issue. This is pretty basic development stuff with Xcode.
coldtea 11y ago
>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. Wanting to do "system profiling" for your "apps" already makes you an expert compared to the regular user. And there's nothing much complicated to disabling SIP, you can do it in 2 minutes with one reboot and a command line command. If you know how to use iotop and iosnoop, you know how to do that.

by Cieplak 11y ago

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).

tristanj 11y ago

I think it's great you've shared this. With the recent SIP changes, thousands of Stack Overflow guides that involve "running a few commands with sudo" are now potentially broken. If devs/users are unfamiliar with this change, they might follow an out-of-date guide and become stuck for hours. It almost happened to me last week when I tried following a stack overflow post to fix some symlink issues with /usr/bin/. Fortunately I read about SIP previously on HN and was able to work around it. But I'm worried for the thousands of other devs that haven't heard of or encountered SIP. There needs to be more awareness of this change because it affects much more than people expect. Takeaway: if you're following a OS X guide that involves sudo written before 10.11, keep SIP in mind or you might get burned.

ryannielsen 11y ago
I'm idly curious: what were your "symlink issues with /usr/bin/"? As with other unices, /usr is system-owned and anything not under the /usr/local hierarchy may be modified or destroyed during OS upgrades. Very few people should ever need to disable SIP – and that includes almost all developers! Are you building/running unsigned kexts? No? Then you almost certainly don't need to disable SIP. Most instructions that no longer work with SIP enabled should be modified so they don't conflict with SIP. As a bonus: changes resulting from those instructions are far more likely to be preserved across OS X upgrades.
- vitd 11y ago
  One completely normal developer thing I need to do that involved turning off SIP is setting library and framework paths to debug an executable outside of Xcode. We archive our daily builds so we can regress problems to a specific check-in. Now I could just roll back my source and build from that, but that takes significantly longer than just copying the regression build from the server. (Not to mention that if the revision is old enough, I need to install an older OS and Xcode just to build it.) But our archives are straight out of an Xcode development build - they contain separate libraries and frameworks that we build and that aren't moved into the executable like during an install. So to run them from a disk image you need to set DYLD_LIBRARY_PATH and DYLD_FRAMEWORK_PATH to get the OS to know where to look for them. But this doesn't work with SIP. This is not some low-level kext-related issue. This is pretty basic development stuff with Xcode.

coldtea 11y ago

>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. Wanting to do "system profiling" for your "apps" already makes you an expert compared to the regular user. And there's nothing much complicated to disabling SIP, you can do it in 2 minutes with one reboot and a command line command. If you know how to use iotop and iosnoop, you know how to do that.