They're not going to change anything, and it doesn't even make sense to suggest that they should. /usr/bin/git isn't a Git binary. It's a tool that is equivalent to running `xcrun git "$@"` (which runs git from inside your default Xcode / Command Line Tools installation). So even if you could replace /usr/bin/git, you'd still have a vulnerable Git binary on your system, since you won't have replaced the tool that /usr/bin/git was actually executing.
So basically, you can update the executable yourself?
See, this makes very little sense. SIP has been designed to prevent malware authors updating executables in system directories. But they use a tool that locates and executes an executable in a directory that can be updated. So what, pray tell, was the point of SIP when their own people poke huge holes like this in their supposedly immutable discretionary access control system?
If I'm a malware author who somehow gains access to root, I just locate where git is actually located and I install my own compromised version. Sure, other executables haven't been compromised which is a good thing... but it seems pointless installing executables like git that aren't directly essential to the running of OS X in this system folder in the first place!
I recognise that I may be missing something, but for the life of me I'm struggling to see what this might be. If someone knows, please inform me rather than voting me down, I'm interested in understanding the logic behind all of this!
`git` is not a system-critical component. Nothing on the system relies on it working (after all, it doesn't even work at all until you install Xcode). It's really only protected because all of /usr/bin is protected.
Another way to look at it is there's not much difference between replacing the binary that /usr/bin/git executes and adding a compromised `git` binary somewhere in the user's PATH, since the user will invoke your malicious tool either way the next time they run `git`. The former only serves to affect scripts that hard-code /usr/bin/git (except that's not very common since it's not at that path on all systems, and hard-coding that means the user can't provide their own version of git if they want to).
Edit: All that said, Xcode and all of its embedded components are code-signed, and it's entirely possible that /usr/bin/git requires the actual git binary to be codesigned by Apple. The only way to test that is for me to intentionally break my Xcode install and I'm not going to do that since I actually need it to work.
Edit 2: Also, why the heck would you try to compromise /usr/bin/git anyway? If you're in a position to do that, you're already in a position to execute whatever code it is you want, so waiting until the user executes `git` to do it isn't very useful.
So what's the point of stopping root from updating git in /usr/bin/git in the first place? Wouldn't it be better for Apple to have put non-system critical executables in a different directory which is writable by root and added this to $PATH?
• This means Apple inventing a brand new system-level nobody-but-Apple-should-really-be-touching-this folder for storing the handful of developer tools shims, for which there is no -nix precedent and so they'd have to make up something new.
• This alters the default PATH, which will probably break a lot of stuff because it's not all that uncommon to reset PATH back to the default of "/usr/bin:/bin" or to the fairly common "/usr/local/bin:/usr/bin:/bin".
• There's no benefit at all to doing this. Why would you even bother separating out these tools? The user shouldn't be modifying them anyway, so why should Apple go out of its way and potentially break a lot of software simply so the user can in fact replace the shim that executes the Xcode-bundled version of git? Not only is there no benefit, but there is a lot of potential harm in doing this, because once the user replaces that shim there's no way to get it back. It is part of the system, even though it's not system-critical, and if you replace it there's no way to fix it short of reinstalling the entire OS.
• Ummm.... You mean like a system where they install shim scripts to a bunch of developer tools in which only a special Apple service can gain access to it? Because that's what they've actually done: SIP locks up that directory and to get around it they have a shim to a writable executable!
• Who switches the PATH to /usr/bin:/bin or /usr/local/bin:/usr/bin:/bin? Most people if they need to do this set PATH in their bashrc or shell config to $PATH:/opt/bin; and if they need to set it and then switch it back (though I can't work out who would need to do this) then they copy the variable to something like $ORIGPATH, set their PATH and then copy it back again.
• why would you bother to seperate out non-system tools from a directory that Apple make immutable via discetionary access controls except to a particular privileged system process?
Perhaps because of the same reason why on the average server it's suggested that to keep your attack surface as low as possible you only install the minimum set of utilities and services necessary for the server to be operational?
And you claim its system critical, yet it isn't and if a non-system binary is replaced and that binary is installed in a location away from system binaries you can put it back?
Not to mention that only under the current situation only Apple can supply security updates to a third party took they don't actually maintain? And they can't be as quick as a system administrator who wants to remove it entirely? Because right now if you delete that "system" git the shell died t give an error that the executable can't be found but the shim gives an error? That hardly makes sense.