4 ms·
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 secur
by 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 agoHe 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 agoIf 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 agoI don't get that point. "Normal" users won't (and shouldn't) disable SIP. Those who do need to for security research won't really care that Apple knows they're poking into the system (when you disclose a vulnerability, they'll know who you are) and for the very paranoid, you can disable network or block connections to Apple or etc. It's a strawman argument because for security researchers, there is never a problem of "we can't let them know we're looking". There's also no evidence that Apple phones home the status either. And re:"barrier of entry". Who should we be protecting? Amateur security researchers or mass users? As an amateur security researcher I'd happily allow my job to be 10x harder if it makes users even 2x safer.
- Buge 11y agoWe might want to hide our activity from malware. The malware might delete itself as soon as SIP is disabled.
- ryannielsen 11y agoIf you're looking to hide your activity from malware, you should be incredibly excited by SIP. With SIP enabled, you have more protection from malware introspecting other processes or monitoring activity on the system. Hell, if you're a researcher building tools to detect and analyze OS X malware, you'd likely benefit from SIP by opting-in your tools to SIP's restrictions. (Tangential example: Chrome is taking this step; Canary is currently SIP restricted.) Malware can only introspect SIP-protected activity by employing kernel exploits. If malware can compromise the kernel, it's game over. You're not going to hide anything, ever. If anything, it sounds like you want SIP's purview expanded to encompass more of OS X.
- userbinator 11y agoI'd happily allow my job to be 10x harder if it makes users even 2x safer. How did you become a security researcher? If it was 10x harder to get started, perhaps you might've never started, or given up long ago. A future with fewer security researchers is not a good thing, wouldn't you agree? And by your argument the safest user is one who cannot do anything even remotely unsafe, which is a deeply disturbing dystopian thought. SIP is just another step toward an environment in which users are not longer users - they're the ones being used.