git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Jeff King <peff@peff.net>
To: Julian Brost <julian@0x4a42.net>
Cc: git@vger.kernel.org
Subject: Re: Trust issues with hooks and config files
Date: Fri, 7 Mar 2014 16:04:04 -0500	[thread overview]
Message-ID: <20140307210403.GA6790@sigill.intra.peff.net> (raw)
In-Reply-To: <5318ECFF.40908@0x4a42.net>

On Thu, Mar 06, 2014 at 10:47:43PM +0100, Julian Brost wrote:

> I've noticed some behavior of git that might lead to some security
> issues if the user is not aware of this.
> 
> Assume we have an evil user on a system, let's call him eve. He
> prepares a repository where he allows other user to push changes to.
> If he now adds a post-receive hook, git will happly execute it as
> whatever user pushes to this repository:

Yes, this is a well-known issue. The only safe operation on a repository
for which somebody else controls hooks and config is to fetch from it
(upload-pack on the remote repository does not respect any dangerous
config or hooks).

> Something similiar might happen if eve adds some alias to the config
> file in the repository and grants any other user read access to the
> repository. These aliases will be executed when some other user is
> running any git command in this repository. Even though git does not
> allow defining aliases for existing commands, you might mistype
> something, so adding an alias for "lg" instead of "log" might succeed:

Much easier is to define an external diff or textconv tool; then the
victim does not even have to typo.

> I'd suggest taking a similar approach as Mercurial [1], i.e. ignoring
> configuration files and hooks owned by another user unless the owner
> is explicitly trusted

It has been discussed, but nobody has produced patches. I think that
nobody is really interested in doing so because:

  1. It introduces complications into previously-working setups (e.g., a
     daemon running as "nobody" serving repos owned by a "git" user
     needs to mark "git" as trusted).

  2. In most cases, cross-server boundaries provide sufficient
     insulation (e.g., I might not push to an evil person's repo, but rather
     to a shared repo whose hooks and config are controlled by root on
     the remote server).

If you want to work on it, I think it's an interesting area. But any
development would need to think about the transition plan for existing
sites that will be broken.

At the very least, the current trust model could stand to be documented
much better (I do not think the rule of "fetching is safe, everything
else is not" is mentioned anywhere explicitly).

-Peff

  reply	other threads:[~2014-03-07 21:04 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-06 21:47 Trust issues with hooks and config files Julian Brost
2014-03-07 21:04 ` Jeff King [this message]
2014-03-09 17:27   ` Julian Brost
2014-03-10 15:18     ` Junio C Hamano
2014-03-16 13:45     ` Sitaram Chamarty

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140307210403.GA6790@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=git@vger.kernel.org \
    --cc=julian@0x4a42.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).