So what Apple have designed is a "system integrity protection" system that actively prevents you from mitigating security issues. Only a very large company could come up with such an amazingly awful idea. I can just imagine the meeting where this was decided that it would "protect" users where someone said "Freeze all the system binaries even from the end users, that will make them more secure!".
It can be disabled. For regular users without git on their systems, it still makes plenty of sense.
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 whi…
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.
Best part: > So, what's the big deal? Crappy C code gets exploited every day, and we upgrade it, and then we're "safe" until the next huge hole that's been there forever is reported. (In the meantime, people party with their private stash of vulnerabilities.)
I looked at the offending function, and it would be trivial to rewrite it in C++ in an easy to understand and safer way. It probably wouldn't be as safe as Rust, but still a lot better.
A lot of Linux C utilities would benefit from such a treatment.
So what Apple have designed is a "system integrity protection" system that actively prevents you from mitigating security issues. Only a very large company could come up with such an amazingly awful idea. I can just imagine the meeting where this was decided that it would "protect" users where someone said "Freeze all the system binaries even from the end users, that will make them more secure!".
It can be disabled. For regular users without git on their systems, it still makes plenty of sense.
It looks like I need to reboot my machine just to disable it. That's the only info I can see to turn it off - unless I'm missing something?
Isn't this why projects such as Homebrew thrive? For me personally, I just `brew install git`, and I keep it updated that way (`brew update && brew upgrade`)... Sure, Apple should ship a fix, but there are ways around it for now.
Sure, but your /usr/bin/git is still vulnerable. You're one config mistake (or maybe running a "malicious" script) away from executing.
To be fair, if you're pulling from a compromised repo, you're already in a bad spot. There's a good chance you're going to be making and running the code you cloned, at which point you'll execute whatever arbitrary code anyways. If it's executed from a random script, there's a good chance you're not checking the result either before building.
Same problem is valid for Python. The subprocess module on El Capitan has a bug that has caused me a lot of trouble recently: http://bugs.python.org/issue26083#msg258011 You'll need to put an updated subprocess.py in your Python path, editing the one provided by OS X is prevented by the System Integrity Protection... ¯\_(ツ)_/¯
Are you not using virtualenv? I always use virtual environments as much as possible to avoid being locked in on an older version (for example Python in this case).
Of course you can also use virtualenv, but if Apple kept software that ships with OS X up-to-date I wouldn't have to deal with this at all.
If you don't have Xcode installed then you don't have git. IIRC, you might have a /usr/bin/git executable but that's not actually git, all it does is shows a GUI that prompts you to install XCode
Thanks. Yea, /usr/bin/git is still there: $ git --version $ git version 2.6.4 (Apple Git-63) But glad to know it won't do anything.
If you don't have Xcode installed then you don't have git. IIRC, you might have a /usr/bin/git executable but that's not actually git, all it does is shows a GUI that prompts you to install XCode
Thanks. Yea, /usr/bin/git is still there: $ git --version $ git version 2.6.4 (Apple Git-63) But glad to know it won't do anything.
Isn't this why projects such as Homebrew thrive? For me personally, I just `brew install git`, and I keep it updated that way (`brew update && brew upgrade`)... Sure, Apple should ship a fix, but there are ways around it for now.
Sure, but your /usr/bin/git is still vulnerable. You're one config mistake (or maybe running a "malicious" script) away from executing.
It's times like this that prove I made the right choice sticking to Linux.
There's nothing I hate more than the inability to fix things that are broken on my system or the fact that I would have to jump trough a lot of unnecessary hoops to do it.
The few small advantages are just not worth it in the end for me.