Yes. This is by design, since the whole point is to defend against malware that has gotten root privileges; requiring recovery mode ensures that the physical user of the computer consents to the change.
They didn't change the user experience in any way - most updates do not require a reboot, the ones which do are fast - so I'm guessing that the kernel checks the code signature on the process doing the write when deciding what to block and possibly even requires a valid Apple signature on the new file.
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!
I think the idea is that they protect everything which they ship, so you can add other things but not replace Apple-provided components.
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.
That's the issue I have - not so much an immutable part of the filesystem (though I find that bizarre and flawed), but that Apple don't do enough updates fast enough.
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.
:-) all good - I'm more curious to know how Apple updates their operating system. Evidently it's possible to modify these protected files, I'm now curious how they do it.
We use a mac server as a build machine. It's pretty annoying; given that you need to graphically log in to accept a license every now and then to use lldb (a non-graphical debugger) among other things.
In our case I think rebooting the server works, but you can't be aware of all usecases.
You are missing the wider point I fear. You seem to be so focused on git that you miss the point that there are other system utilities that are installed in /usr that you might need to patch.
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.
No, I'm just bored of faux-outrage and agenda pushing.
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?
You read into what is not there. I know about SIP already, but I've always been surprised about it as it seems pretty flawed to me - it turns out if you can get root access you can easily bypass the "protection" mechanism with a small utility that loads up a kernel extension and bypasses the mechanism anyway.
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...
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.
Ah, bummer. Thanks for this info, good to know :-)
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.
> 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.
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).
In that case, then git is a vector through which SIP can be bypassed. But it's not used to apply updates as it's part of XCode command line utilities and not the core system.
I'm more amused than upset. You seem rather steamed up there though... Now how about answering my actual question. What if I don't want to turn off SIP but I want to use dtruss to troubleshoot my system?
If Apple truly doesn't want me to use dtruss, then why do they bundle it?
You can use dtruss, you just can't use it on certain binaries. A friend said that you can disable certain parts of SIP to enable functionality like this but I haven't tried myself.
