If you execute csrutil disable && reboot, you will be able to disable System Integrity protection and do what you want including fixing /usr/bin/git. What is the problem?
The problem is that System Integrity protection was put in place for my benefit and marketed to me as a feature that had been "designed to help prevent potentially malicious software from modifying protected files and folders on [my] Mac", and now that I have it and paid money for it (or the Apple hardware it runs on), I find out that it is making me less secure by preventing me from removing a software component which has a remote code execution vulnerability, and that the only way around that is to disable the feature is by using Recovery to update my computer's NVRAM.
Yes. (a) You are not a typical user; (b) disabling SIP takes five minutes plus whatever productivity loss is caused by rebooting; (c) it isn't actually necessary to disable SIP to make git inaccessible, as described later in the post; (d) even if it were, you would get most of the protection by just installing your own git in a different location and changing PATH; and (e) the vulnerability in question is incredibly minor anyway, considering the percentage of the time that most people follow checking out a repository by intentionally running arbitrary code from it, which (f) would at least partially justify Apple not backporting the patch, but then again, nobody in this thread has even verified that they haven't.
It is not necessary to run anything except "git clone". An attacker can construct a repository such that merely attempting to clone it would execute arbitrary code. This is why the vulnerability was given a CVSS base severity score of 9.8 (out of a possible 10).
I know, but Git is mostly used for software development, and people mostly clone unfamiliar Git repositories with the intent to build and/or run the included software, mostly without performing a full manual inspection of the code beforehand; even if they only build, most build systems allow specifying arbitrary commands to run. Thus, in the common case, exploiting the vulnerability gives the author of a malicious repository only the power they would have gotten shortly afterward anyway. Of course, there are exceptions to all of those "most"s (especially the first one, I think), but my conclusion is still that the overall danger of that particular vulnerability is pretty minor.
Sometimes I think that Apple are increasingly trying to lock down OS X to prevent anything from being installed outside of its own walled garden.
The poster's point, as you haven't understood it, is that by preventing updates of utilities like the system git, vulnerabilities remain available on the system. This makes the system less secure, and the only way to fix the security issue is to disable the security feature that is preventing the security vulnerability from being fixed.
In other words - by making system files immutable even to root, it's not exactly making the system any more secure.
The poster's point, as you haven't understood it, is that by preventing updates of utilities like the system git, vulnerabilities remain available on the system. This makes the system less secure, and the only way to fix the security issue is to disable the security feature that is preventing the security vulnerability from being fixed.
I understood the point perfectly well, and that's why I think it's a bit overblown. This security feature is precisely designed to prevent you from modifying your system and encourage you to defer that to Apple. It should be obvious that such a feature will also prevent you from fixing things yourself, which Apple either hasn't gotten around to fixing or refuses to. But since they give you some way of disabling it, you just do that and fix it yourself (and presumably SIP will then protect your fixed version of git?)
I believe that toggling a boot-arg only disabled SIP on early developer betas of OS X 10.11. For shipping releases of El Capitan you need to use csrutil from the recovery partition as a parent comment mentioned.
