If you can create a .git directory above a victim's home directory, then you're root.
Or else, if you're not root, you're in messed up system. Whoever is root should go read some 40-year-old book on Unix about how it's supposed to be laid out.
This is not a genuine security vulnerability; though of course, it's good to fix it.
Here is how I would fix it. Forget about permissions and ownership entirely. There is a weaker, more powerful condition we can check. Ready?
Git should terminate if it is executed from a subdirectory of a git repo that contains no tracked files according to the first .git/ directory that it finds while ascending the file system.
If you're in a directory that contains no files that are tracked by the closest .git/
that can be found by walking up the stairs, then that directory has no relationship to that
repo. Git should diagnose that and bail out. (It could allow files in that directory to be added
to the index, but only with -f option to force it.)
If git finds a .git/ dir, and that repo's index shows that at least one item in, or below, your working directory is in that repo's index, it should go ahead and work with it, regardless of ownership.
Right, so someone could create a malicious /tmp/.git. You then go to /tmp/experiment to do something and run some git commands.
Easy fix: on boot, have the "rc" script create a root-owned /tmp/.git dummy file with r-------- permissions.
Someone can also create a /tmp/foo/.git; but to be susceptible to that, you have to be under /tmp/foo.
That's another user's directory. What are you doing in there? Serves you right.
If /tmp/foo is your own, and someone planted a .git into it, that's your problem too: you're creating material in /tmp that is accessible to others, which is a security no-no.
Probably, this should be fixed in the kernel: the kernel should not allow a regular user to create a hidden directory (i.e. name starting with ".") in /tmp. Or probably any hidden object.
Such a fix is more general: it fixes the issue for any git-like program that walks up the tree looking for a special dot directory or file, including all such programs not yet written.
The rule could be general, such that creating a hidden object in a directory is only allowed to the directory's owner, not just to anyone who has write permissions to the directory.
In other words, if multiple users have write access to a directory, such as /tmp, but any other kind
of directory, then they are not allowed to perpetrate hidden objects on each other (both because
those things don't show up under "ls" without "-a" and because programs find those and react to them).
In fact, I would go one step further and enforce the kernel rule that writing to an existing dot file is denied to
anyone other than the owner that file, regardless of its write permissions.
Or else, if you're not root, you're in messed up system. Whoever is root should go read some 40-year-old book on Unix about how it's supposed to be laid out.
This is not a genuine security vulnerability; though of course, it's good to fix it.
Here is how I would fix it. Forget about permissions and ownership entirely. There is a weaker, more powerful condition we can check. Ready?
Git should terminate if it is executed from a subdirectory of a git repo that contains no tracked files according to the first .git/ directory that it finds while ascending the file system.
If you're in a directory that contains no files that are tracked by the closest .git/ that can be found by walking up the stairs, then that directory has no relationship to that repo. Git should diagnose that and bail out. (It could allow files in that directory to be added to the index, but only with -f option to force it.)
If git finds a .git/ dir, and that repo's index shows that at least one item in, or below, your working directory is in that repo's index, it should go ahead and work with it, regardless of ownership.