Re: Adding hooks.directory config option; wiring into run_hook

At 10:06 -0800 16 Dec 2011, Junio C Hamano [off-list ref] wrote:

Christopher Dale [off-list ref] writes:

quoted

...
trusted path execution policies. These systems require that any file
that can be executed exhibit at least the following characteristics:

  * The executable, it's directory, and each directory above it are
    not writable.

Since the hooks directory is within a directory that by it's very nature
requires write permissions,...

Sorry, but I am not interested at all. If you can write into $GIT_DIR/config
then you can point at any directory with hooks.directory and that would mean
it would defeat your "trusted path execution policies".

How does that defeat the policy?  It would certainly allow somebody who 
can write to $GIT_DIR to disable hooks, use hooks that were meant for a 
different repository, or perhaps even use executables that weren't 
intended to be hooks.  If the proposed configuration option were 
modified by an attacker to point to some directory that doesn't meet the 
requirements, then the underlying system would still prevent execution; 
the same result that would happen if they'd try to install hooks in the 
traditional location.

I see other problems with that policy, at least with the short 
description that was provided.  Unless there are also restrictions on 
the allowed owners of the executable and its containing directories, an 
attacker would still be able to install new executables and then remove 
write permissions before trying to use them.  But, that flaw (if it 
exists) wouldn't be affected by the proposed change to git.

Requiring that all executables on a secured system be installed by an 
admin doesn't seem to be a completely unreasonable requirement.  The 
supplied patch looks to be fairly small and easy to understand, so I 
wouldn't think that including it would present much of a problem for 
maintaining git.

The option might also be useful to allow the same hooks directory to be 
used for multiple repositories, although symlinks would likely be a 
better way to do that.