Running and disguising programs through XCode shims on OS X
randomtechnicalstuff.blogspot.com
randomtechnicalstuff.blogspot.com
No it doesn't. Why are you claiming it does? /usr/bin/git and the other shims are behaving precisely as expected. There is absolutely no violation of SIP. Someone who is able to muck with DEVELOPER_DIR or install a fake xcrun does not gain any privileges by doing so, and they're already in a position to do whatever malicious act you're thinking they'd trigger by invoking /usr/bin/git.
Because of the way that they have put in those shims, you can - without being root - install a binary (or a shell script) in a user directory that acts as if it was another program - the example I used is git.
(Interestingly, they chose to use a purpose built library to do this. Their git shim literally just checks an environment variable and calls on a library function to execute xcrun. I do wonder why they chose to write a program in a compiled language instead of using a shell script. A passing thought was that they didn't really want to publicise what they had done because they knew most BSD fans would probably throw them brickbats... but then again, Apple seem to be fans of binaries so it was probably not done to obfuscate anything...)
When you say that someone who is able to change DEVELOPER_DIR or install a fake xcrun is already in a position to do whatever malicious act they feel like, then this is precisely the reason why Apple implemented SIP. (I am curious why you think they prevent access to those directories even by root though...)
A big part of SIP is preventing the end user from typing in their password to give a malicious program access to replace certain binaries installed in the /usr/bin directory (and a few other locations). So basically they don't want git, or any other program, to work in a way they didn't intend - i.e. They don't want malware authors installing a riot kit by replacing binaries.
In essence, this is what this is doing. The main difference here is that instead of them needing to be root, they just create a directory, create a small script update an environment variable and optionally tweak .bashrc as the user and they have effectively added a wrapper to the XCode utility. With no need to elevate privileges.
I'm sure you can see that is problematic?
> A big part of SIP is preventing the end user from typing in their password to give a malicious program access to replace certain binaries installed in the /usr/bin directory (and a few other locations)
And that hasn't changed. The binaries are not being replaced.
> So basically they don't want git, or any other program, to work in a way they didn't intend - i.e. They don't want malware authors installing a riot kit by replacing binaries.
No, they don't want malware authors to modify the operating system. Doing a non-privileged action (i.e. setting the env variable) in order to change the behavior seen when invoking /usr/bin/git really has no relation to SIP at all, that's jut working as intended. Besides, nothing of the behavior you describe has anything to do with root kits either. Someone who can point DEVELOPER_DIR at a malicious directory hasn't gained any privileges by doing so, and has not compromised the operating system in any way.
> In essence, this is what this is doing. The main difference here is that instead of them needing to be root, they just create a directory, create a small script update an environment variable and optionally tweak .bashrc as the user and they have effectively added a wrapper to the XCode utility. With no need to elevate privileges.
And without gaining any privileges. I've already said this multiple times before. The end result of all of this is they have no more privileges than they already needed to set this up in the first place. They've gained literally nothing from doing this.
> I do wonder why they chose to write a program in a compiled language instead of using a shell script.
Probably so they can codesign the binary, since you can't codesign shell scripts.