The reason they designed SIP was partially to prevent anyone from replacing a binary with one of their own.<p>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.<p>(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&#x27;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...)<p>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...)<p>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 &#x2F;usr&#x2F;bin directory (and a few other locations). So basically they don&#x27;t want git, or any other program, to work in a way they didn&#x27;t intend - i.e. They don&#x27;t want malware authors installing a riot kit by replacing binaries.<p>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.<p>I&#x27;m sure you can see that is problematic?