Re: Shared repositories no longer securable against privilege escalation

From: Joe Rayhawk <jrayhawk@freedesktop.org>
Date: Mar 17, 2017, 17:12 UTC
Message-ID: <148977072642.2144.7040206366650087348@richardiv.omgwallhack.org>
In-Reply-To: <195b30d7-9ea2-7a9b-79ca-41b7bb890a30@alum.mit.edu>

Quoting Michael Haggerty (2017-03-17 05:07:36)

Show 11 quoted lines

> On 03/17/2017 01:23 AM, Joe Rayhawk wrote:
> > Git has started requiring write access to the root of bare repositories
> > in order to create /HEAD.lock. This is a major security problem in
> > shared environments as it also entails control over the /config link
> > i.e. core.hooksPath. Permission to write objects and update refs should
> > be entirely separate from permission to edit hook execution logic.
> 
> Thanks for the report. This is indeed a problem for people who want to
> set restrictive privileges on $GIT_DIR. I'd never thought of that use
> case, but it makes sense. Is this practice recommended somewhere or
> required by any Git hosting tools? (I'm curious how prevalent it is.)

I had to work out the practice for my own management engine; I have since deployed it to around eight different mixed-use multi-user operations, the most significant of which is Freedesktop.org.

Without this practice, core.sharedRepository is an enormous liability of a feature. I can't speak to whether anyone but me ever noticed, what with mixed-use multi-user POSIX environments becoming increasingly rare.

Show 5 quoted lines

> The locking was added intentionally, to ensure that the reflog for
> `HEAD` is written safely. But the code didn't do that prior to the
> commit that you referenced, so (as a special case) ignoring failures to
> lock `HEAD` due to insufficient permission is probably a reasonable
> compromise.

Hooray!

> (I can't resist pointing out that the *real* bug is storing special
> references like `HEAD` in the top level of $GIT_DIR, but that can't be
> changed now.)

Yeah, putting refs outside of refs/ is conceptually pretty nutty.