[eridius]

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.

[chris_wot]

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!

[eridius]

`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.

[chris_wot]

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?

[eridius]

A few reasons come to mind:

• 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.

[chris_wot]

• 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.

[eridius]

Apple needs the shims anyway, even if the directory was writable. Note that the shims existed before SIP was a thing. The reason Apple needs the shims are twofold:

1. Xcode is distributed as a single application bundle. All of the developer tools are somewhere within /Applications/Xcode.app. Xcode used to be installed with a package installer, so it would dump its tools into the system directories, but a number of years ago they switched to the application distribution for a few reasons, the biggest being so it can be distributed via the Mac App Store.

2. If you don't have the developer tools installed, the shims prompt you to install the standalone Command Line Tools bundle (which goes into /Library/Developer IIRC, still as a single self-contained bundle like Xcode). Without the shims, there wouldn't be any way to trigger an installation of the standalone Command Line Tools.

> Who switches the PATH to /usr/bin:/bin or /usr/local/bin:/usr/bin:/bin?

Someone who's writing a script and wants to be insulated from potentially-malicious entries in PATH. Or shells or shell-like programs executed without any PATH provided at all, which can happen if you invoke them with `env -i`.

> 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?

Huh? What does any of this have to do with attack surface? These tools are on the system regardless, moving them into a different directory has no bearing on attack surface.

> And you claim its system critical, yet it isn't

I don't know if you're deliberately misrepresenting what I said, or if you simply haven't bothered to actually read what I'm saying. These binaries are not critical to the operation of the system. In fact, the system doesn't ever even try to invoke them during normal operation. But they're still part of the system, and if you get rid of them there's no way to get them back without reinstalling the OS.

> 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?

..what? I genuinely can't figure out what you're trying to say with this sentence.

> 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?

Congratulations, you've just described how every third-party component bundled with the system works.

> And they can't be as quick as a system administrator who wants to remove it entirely?

That's completely nonsense. Any "system administrator" that believes these tools should be removed from OS X should be fired for incompetence. These are shims, and their entire point is to provide a predictable location within the default PATH for a bunch of tools that are actually bundled inside Xcode or the standalone Command Line Tools download. If you don't want to have git/clang/etc on your system, don't install Xcode or the standalone Command Line Tools. It's that simple.

> 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.

Huh? You can't delete that "system" git. And as I said above, it doesn't make any sense to even try, because it's just a shim. If you really don't want to have git installed on your system, don't install Xcode.

So really this pretty much boils down to "if you don't want developer tools on your system, don't install the developer tools". All that you'll have are a set of shims that offer to install the developer tools if you try and run them (which I hope you can see is a pretty sensible suggestion, and is akin to how linux distros often suggest packages you can install when you try and execute commands that don't exist).