Remember when I said El Capitan?
Apple is doing something new which basically keeps you from twiddling certain system-level programs without going to fantastic lengths.
Not even root is enough to do it.
Can someone explain it to me?
Apple is doing something new which basically keeps you from twiddling certain system-level programs without going to fantastic lengths.
Not even root is enough to do it.
Can someone explain it to me?
The big market isn't developers but end users who have no idea how to protect themselves from real threats and who don't use git. And for them sandboxing, signed executables, verified boots and other measures make life far better.
If you are a developer using a Mac you most likely use brew or some sort of vm/container system anyway.
Only a very large company could come up with such an amazingly awful idea. I can just imagine the meeting where this was decided that it would "protect" users where someone said "Freeze all the system binaries even from the end users, that will make them more secure!".
Anyway, so only system updates can update the OS X system? Which involves a system reboot? How does the "system protected" software get updated?
But not making it easy to update flawed software sounds like a great vector for malware.
Best I can find is the following article:
https://reverse.put.as/2015/10/12/rootfool-a-small-tool-to-d...
I'd still love to know their thinking behind put git into a directory that SIP makes deliberately hard to update! I mean, git is additional software and not even part of their base operating system, my understanding about SIP was that it was meant to prevent people from tampering with the underlying system software and installing rootkits.
git (and ssh for that matter) aren't going cause rootkits by themselves - and all they are doing is forcing people to use homebrew to install versions that's aren't protected by SIP!
From a sysadmin's perspective this makes a lot of sense: beyond malware, I've seen security and stability problems caused by installers from large companies, developers cowboying up with “sudo make install", etc. but it definitely puts the onus on Apple to ship updates promptly.
I basically think that if Apple want to lock down their ecosystem and prevent folks from updating their own software, then they have a duty to provide timely updates that address security bugs. Currently they don't seem to be doing that.
Why would you install Xcode on such a important box?
And if I want to troubleshoot something odd, it would be nice to be able to hook in dtrace - without rebooting the server, flipping a switch to disable the "feature", and then troubleshoot my server's issue.
If this is such a critical issue, then reboot your Mac and disable SIP. 5 minutes and done. In the time it's taken you to post all your comments here, you could have fixed it.
[edited to add]
It's not like SIP was a secret - it was one of the major features of El Capitan. Didn't you do any research before upgrading your mission critical server to El Capitan?
https://github.com/gdbinit/rootfool
Incidentally, calm down a bit - you sound pretty outraged yourself!
You might want to address the dtrace issue though - let's say you didn't want to disable the protection that SIP provides in making the /usr filesystem immutable. How do you then run dtrace on system utilities when troubleshooting?
Genuinely curious how you answer that.
Edit to ask another question: another question for you, as you seem to have the answers here: why does Apple install git in a directory that is under the control of System Integrity Protection? Why not under /usr/local? It's not exactly a "system utility" - it's a DVCS and not in any way critical to the running of the system. Hell, I'd not even consider it system software.
And how does Apple do this? The last time I installed the XCode command line tools, I don't recall that I had to reboot my system, so it looks like Apple do indeed have an update mechanism to overwrite the files. In which case it is one exploit away from disabling the file immutability protections afforded by SIP...
I can imagine git might be necessary for applying some updates (on FreeBSD svn is a critical part of the base system, because one way to update is by svn updating the source and rebuilding).
From their readme: "P.S.: 10.11.4 update removed csr_set_allow_all() function used to enable/disable SIP. It means this code does not work on El Capitan 10.11.4 or newer versions when released."
Also even when it did work it needed you to get a Kernel Extension signing certificate from Apple - which they could (probably) revoke pretty easily when they saw it being misused.
Of course, there is a utility that sets the flag in recovery mode, unless there is a specially built kernel that only exists in that mode (I'm no OS X expert, there could be) then there must be some way of bypassing the protections. If you can still load a kernel extension then it occurs to me that you can still bypass it.
This seems to be your pattern when you get upset. You've told someone else they were being defensive, now you're saying I need to calm down.
I guess that's easier than rebooting a server and turning off SIP.
If Apple truly doesn't want me to use dtruss, then why do they bundle it?
Looks like this is the command:
csrutil enable --without dtraceIn our case I think rebooting the server works, but you can't be aware of all usecases.
sudo xcodebuild -license sudo xcode-select --install