Repository Security

Repository Security

[Andre Masella]

I've been using git for a while and really like it, but I have a concern about 
security.

As I understand it, none of the repository backends allow any per-user 
per-branch access control. SSH and HTTP come the closest with the right 
hooks, but since the repository is writeable by those users, there is little 
to stop them from changing the repository directly.

If this is truly the case, I was thinking of creating something similar to 
SVN's Apache plugin to provide more sophisticated access control. I'm leaning 
toward the HTTP remote (transport? backend? What's the right term?) because 
Apache can do many kinds of authentication. I could also make the HTTP less 
dumb, if I had a better idea what that might involve. This could also be a 
way to solve the requests for remote repository creation I see in the survey.

So, before I start, I would like to get ideas from others...or be told this is 
a waste of time. Thanks.
-- 
--Andre Masella (andre at masella.no-ip.org)

Re: Repository Security

[Shawn O. Pearce]

[-- Attachment #1: Type: text/plain, Size: 3288 bytes --]

Andre Masella <andre@masella.no-ip.org> wrote:
> I've been using git for a while and really like it, but I have a concern about 
> security.

Me too, until I fixed it locally.  ;-)
 
> As I understand it, none of the repository backends allow any per-user 
> per-branch access control. SSH and HTTP come the closest with the right 
> hooks, but since the repository is writeable by those users, there is little 
> to stop them from changing the repository directly.

Yes.  But hooks cannot be run in the HTTP case, can they?  However in
the HTTP case we use WebDAV to update the remote server, which means
security controls in the WebDAV server are probably sufficient to
prevent unauthorized object upload or ref updates.

In the SSH case I fixed it by installing git-receive-pack setuid
to the repository owner.  I locally patched receive-pack.c so it
disables hook execution if that particular hook isn't owned by the
repository user (to prevent rogue users from running arbitrary things
as the repository owner).  This way nobody can change anything in
a repository except through git-receive-pack.

I have the attached script as hooks/update in each repository.
It checks not only that a user can create/update/rewind(aka force
update)/delete a given ref, but that refs/tags are annotated,
refs/heads aren't, and that the committer strings on all commits
(or tagger strings on all tags) match the UNIX user's identity.

Rather draconian.  But in a corporate world with some strict legal
requirements placed upon you by your contracts with your customers
sometimes you do have to verify that Bob really is Bob, or at least
knows Bob's password.

> If this is truly the case, I was thinking of creating something similar to 
> SVN's Apache plugin to provide more sophisticated access control. I'm leaning 
> toward the HTTP remote (transport? backend? What's the right term?) because 
> Apache can do many kinds of authentication. I could also make the HTTP less 
> dumb, if I had a better idea what that might involve. This could also be a 
> way to solve the requests for remote repository creation I see in the survey.

The HTTP push client is dumb because it needs to send loose objects
to the remote repository.  (Though actually that's probably not a
good idea for pushes over 100 objects.)  But its also dumb because
it cannot send all ref updates in one shot, like the Git native
protocol is doing over SSH, or locally over a pipe.

A "smart" plugin to Apache is unnecessary I think.  A CGI which
splits the main() method of git-receive-pack into two halves (one
to write_head_info, the other to do the rest of the work) is all
that is required here to make HTTP push smart.  Then have the HTTP
client make one GET request to obtain the head info, then a POST
request to upload the pack to git-receive-pack.

Actually, looking at git-receive-pack's code, it might just be a
15 line patch to make it do these two tasks with the code it has now.

Since the hooks are then running as the web server user, and inherit
the entire HTTP environment, you can do authentication in the web
server but do authorization from within the hook, where you have
much finer control to inspect what is occurring.  And only the web
server needs to have write access to the repository.

-- 
Shawn.

[-- Attachment #2: update-acl --]
[-- Type: text/plain, Size: 5426 bytes --]

#!/opt2/perl/bin/perl

##
## Invoked as: update refname old-sha1 new-sha1
##

##
## Reads 'info/allowed-users' to determine access.
## Each line in allowed-users is two regex patterns
## to be applied to the refname and the username.
##
##    Example:
##         AURD:refs/heads/sp/     spearce
##         U:refs/heads/env-dev$   spearce|bob|smith
##
## The first line gives UNIX user 'spearce' access to create (A),
## update (U), rewind (R) and delete (D) branches under the path
## 'refs/heads/sp/.  The second line gives UNIX users 'spearce',
## 'bob', and 'smith' access to update (U) *only* refs/heads/env-dev.
##

##
## Reads 'info/allowed-committers' to verify committer
## names within all incoming commits.   Each line in
## allowed-committers is the UNIX username and the Git
## committer string (from git-var GIT_COMMITTER_IDENT).
## A user may only push a tag or commit in which they
## were the committer or the tagger.
##
##    Example:
##         spearce  Shawn O. Pearce <spearce@spearce.org>
##         spearce  Shawn Pearce <spearce@spearce.org>
##         bob      Bobby Brown <bb@example.com>
##
## The first two lines says that UNIX user 'spearce' may use the
## either committer name and email shown.
##

use strict;
local $ENV{PATH} = '/sw/git/bin';
my $debug = 0;
my $git_dir = $ENV{GIT_DIR};
my $committers = "$git_dir/info/allowed-committers";
my $acl = "$git_dir/info/allowed-users";
my $new_commit_check = "$git_dir/info/new-commit-check";

my $ref = $ARGV[0];
my $old = $ARGV[1];
my $new = $ARGV[2];
my $new_type;
my ($this_user) = getpwuid $<; # REAL_USER_ID

sub deny ($)
{
	print STDERR "-Deny-    $_[0]\n" if $debug;
	print STDERR "\ndenied: $_[0]\n\n";
	exit 1;
}

sub grant ($)
{
	print STDERR "-Grant-   $_[0]\n" if $debug;
	exit 0;
}

sub info ($)
{
	print STDERR "-Info-    $_[0]\n" if $debug;
}

sub all_new_committers ()
{
	local $ENV{GIT_DIR} = $git_dir;
	$ENV{GIT_DIR} = $new_commit_check if -d $new_commit_check;

	info "Getting committers of new commits.";
	my %used;
	open(T, '-|', 'git-rev-list','--pretty=raw',$new,'--not','--all');
	while (<T>)
	{
		next unless s/^committer //;
		chop;
		s/>.*$/>/;
		info "Found $_." unless $used{$_}++;
	}
	close T;
	info "No new commits." unless %used;
	%used;
}

sub all_new_taggers ()
{
	my %exists;
	open(T, '-|', 'git-for-each-ref',
		'--format=%(objectname)','refs/tags');
	while (<T>)
	{
		chop;
		$exists{$_} = 1;
	}
	close T;

	info "Getting taggers of new tags.";
	my %used;
	my $obj = $new;
	my $obj_type = $new_type;
	while ($obj_type eq 'tag')
	{
		last if $exists{$obj};
		$obj_type = '';
		open(T, '-|', 'git-cat-file', 'tag', $obj);
		while (<T>)
		{
			chop;
			if (/^object ([a-z0-9]{40})$/)
			{
				$obj = $1;
			}
			elsif (/^type (.+)$/)
			{
				$obj_type = $1;
			}
			elsif (s/^tagger //)
			{
				s/>.*$/>/;
				info "Found $_." unless $used{$_}++;
				last;
			}
		}
		close T;
	}
	info "No new tags." unless %used;
	%used;
}

sub check_committers (%)
{
	my %used = @_;
	return unless %used;

	info "Checking committer strings for $this_user";
	open(A, $committers) or deny "Cannot read $committers";
	info "Scanning $committers";
	while (<A>)
	{
		chomp;
		next if /^#/ || /^\s*$/;
		my ($unix_user, $cstr) = split /\s+/, $_, 2;
		next unless $this_user eq $unix_user;

		if ($used{$cstr})
		{
			info "$cstr allowed by line $.";
			delete $used{$cstr};
		}
	}
	close A;

	if (%used)
	{
		print STDERR "\n";
		print STDERR "You are not $_.\n" foreach (sort keys %used);
		deny "You cannot push changes not committed by you.";
	}
}

deny "Need a ref name" unless $ref;
deny "Bad old value $old" unless $old =~ /^[a-z0-9]{40}$/;
deny "Bad new value $new" unless $new =~ /^[a-z0-9]{40}$/;
deny "Cannot determine who you are." unless $this_user;

my $op = '';
my %op_desc = (
	'A' => 'create',
	'D' => 'delete',
	'R' => 'rewind',
	'U' => 'update',
	);

if ($old =~ /^0{40}$/)
{
	$op = 'A';
}
elsif ($new =~ /^0{40}$/)
{
	$op = 'D';
}
else
{
	$op = 'R';
}

if ($op eq 'R' && $ref =~ m,^refs/heads/,)
{
	open(T, '-|', 'git-merge-base', $old, $new);
	my $base = <T>;
	close T;
	chop $base;
	$op = 'U' if $base eq $old;
}

deny "Operation '$op' not permitted." unless $op_desc{$op};

if ($op ne 'D')
{
	open(T, '-|', 'git-cat-file', '-t', $new);
	$new_type = <T>;
	close T;
	chop $new_type;

	if ($ref =~ m,^refs/heads/env-([^/]+)$,)
	{
		open(T, '-|', 'git-repo-config', "buildenv.$1.name");
		my $env_name = <T>;
		close T;
		if ($env_name)
		{
			deny "$ref must be an annotated tag."
				unless $new_type eq 'tag';
		}
		else
		{
			deny "$ref must be a commit." unless $new_type eq 'commit';
		}
	}
	elsif ($ref =~ m,^refs/heads/,)
	{
		deny "$ref must be a commit." unless $new_type eq 'commit';
	}
	elsif ($ref =~ m,^refs/tags/,)
	{
		deny "$ref must be an annotated tag." unless $new_type eq 'tag';
	}

	check_committers (all_new_committers);
	check_committers (all_new_taggers) if $new_type eq 'tag';
}

info "Requesting $op_desc{$op} of $ref";
info "Checking access for $this_user to $ref";
open(A, $acl) or deny "No such file: $acl";
info "Scanning $acl";
while (<A>)
{
	chomp;
	next if /^#/ || /^\s*$/;
	my ($ref_pat, $user_pat) = split /\s+/, $_, 2;
	my $op_pat = 'AU';
	$op_pat = $1 if $ref_pat =~ s/^([ADRU]+)://;

	if ($ref =~ m:^$ref_pat:
		&& $this_user =~ /^(?:$user_pat)$/
		&& $op =~ /^[$op_pat]$/)
	{
		grant "Allowed by line $.";
	}
}
close A;

deny "You are not permitted to $op_desc{$op} $ref.";

Re: Repository Security

[Martin Langhoff]

On 1/23/07, Andre Masella <andre@masella.no-ip.org> wrote:
> As I understand it, none of the repository backends allow any per-user
> per-branch access control. SSH and HTTP come the closest with the right
> hooks, but since the repository is writeable by those users, there is little
> to stop them from changing the repository directly.

For this kind of scenario, use one repo per developer with GIT+SSH. It
changes your usage pattern slightly (pull from all repos before push)
but this is easy to setup. And you can even enforce the "won't let you
push unless you are up-to-date with the other repositories" via a
fancy pre-update hook script on the repo.

Or you may chose to have an integration repo _as well_ as public per-dev repos.

> So, before I start, I would like to get ideas from others...or be told this is
> a waste of time. Thanks.

Not entirely a waste of time, but there is a very git-style way of
addressing this that will probably save you time...


martin

Re: Repository Security

[Johannes Schindelin]

Hi,

On Mon, 22 Jan 2007, Andre Masella wrote:

> I've been using git for a while and really like it, but I have a concern 
> about security.
> 
> As I understand it, none of the repository backends allow any per-user 
> per-branch access control.

The idea in git (unless you really want to get the same setup as in CVS, 
which would be rather sad) is that every developer has at least one 
repository. Write-access: only one developer.

Now, to integrate you _pull_. No need for write-access for anybody else.

Of course, this means that all developers should have read-access to all 
repositories.

I already hear the complaint: "But you need a central repository!". If you 
_have_ to have a central repository, designate the integrator's repository 
central.

Ciao,
Dscho

Re: Repository Security

[Jakub Narebski]

Andre Masella wrote:

> I've been using git for a while and really like it, but I have a concern about 
> security.
> 
> As I understand it, none of the repository backends allow any per-user 
> per-branch access control. SSH and HTTP come the closest with the right 
> hooks, but since the repository is writeable by those users, there is little 
> to stop them from changing the repository directly.

I wonder if it would be enought for SSH (and perhaps HTTP/WebDAV access)
just to rely on filesystem write access to refs/heads files (different
files having different access rights), and filesystem ACLs.

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: Repository Security

[Andre Masella]

> > As I understand it, none of the repository backends allow any per-user
> > per-branch access control. SSH and HTTP come the closest with the right
> > hooks, but since the repository is writeable by those users, there is
> > little to stop them from changing the repository directly.
>
> Yes.  But hooks cannot be run in the HTTP case, can they?

Err...yes. I don't know what I was thinking when I wrote that.

> However in the HTTP case we use WebDAV to update the remote 
> server, which means security controls in the WebDAV server are
> probably sufficient to prevent unauthorized object upload or ref updates.

Apache has fairly limited authorization when it comes to WebDAV. I can 
authenticate users, but then there is no easy way to determine if they should 
be allowed to modify a particular file and the underlying file system can't 
help because all the users are mapped to a single one. Controlling access to 
directories would require creating .htaccess files everywhere with a list of 
allowed users.

> In the SSH case I fixed it by installing git-receive-pack setuid
> to the repository owner.  I locally patched receive-pack.c so it
> disables hook execution if that particular hook isn't owned by the
> repository user (to prevent rogue users from running arbitrary things
> as the repository owner).  This way nobody can change anything in
> a repository except through git-receive-pack.

That is very clever.

> Rather draconian.  But in a corporate world with some strict legal
> requirements placed upon you by your contracts with your customers
> sometimes you do have to verify that Bob really is Bob, or at least
> knows Bob's password.

Even without the legal requirements, management may resist a system where a 
developer from one project can view, let alone modify, another project.

> > I could also make the HTTP less dumb, if I had a better idea what that
> > might involve. 
> The HTTP push client is dumb because it needs to send loose objects
> to the remote repository.

Okay. And HTTP is the only dumb protocol right now?

> A "smart" plugin to Apache is unnecessary I think.  A CGI which
> splits the main() method of git-receive-pack into two halves (one
> to write_head_info, the other to do the rest of the work) is all
> that is required here to make HTTP push smart.

I see. I wonder about building this into gitweb. Adding a little check of the 
User-Agent can make it decide if it is going to display pretty things or 
allow repository access.

> Then have the HTTP client make one GET request to obtain the head info,
> then a POST request to upload the pack to git-receive-pack.

This would break exisiting HTTP repositories though. Perhaps it should get a 
different name.

In recieve-pack, are the commands read in read_head_info (which would be the 
POST request) all unidirectional?

> Since the hooks are then running as the web server user, and inherit
> the entire HTTP environment, you can do authentication in the web
> server but do authorization from within the hook, where you have
> much finer control to inspect what is occurring.  And only the web
> server needs to have write access to the repository.

All of which is fairly easy to do.
-- 
--Andre Masella (andre at masella.no-ip.org)

Re: Repository Security

[Andre Masella]

> > As I understand it, none of the repository backends allow any per-user
> > per-branch access control.
> The idea in git (unless you really want to get the same setup as in CVS,
> which would be rather sad) is that every developer has at least one
> repository. Write-access: only one developer.

Believe me: I was ready to throw a party when I got to shutdown CVS last week.

Say I have two utterly separate repositories with two integrators. I want to 
put them on a web server (and so same DAV share). There is little to stop the 
integrator of one project (by intention or accident) from modifying the other 
repository. It can be done, but doing it requires one section of the 
httpd.conf per repository.

Using SSH requires many real user accounts on the system and then if there are 
more than one integrator, groups to administrate.

> I already hear the complaint: "But you need a central repository!". If you
> _have_ to have a central repository, designate the integrator's repository
> central.

Okay, say one regular developer wants share his changes with another 
developer. He either has to mail patches, create an SSH account, or set up 
one of git-daemon or WebDAV. And most of those require knowing the 
workstation name which is inconvienient. I would rather have each user able 
to push to a branch with their name on it on a central server.
-- 
--Andre Masella (andre at masella.no-ip.org)

Re: Repository Security

[Andre Masella]

> > As I understand it, none of the repository backends allow any per-user
> > per-branch access control. SSH and HTTP come the closest with the right
> > hooks, but since the repository is writeable by those users, there is
> > little to stop them from changing the repository directly.
> I wonder if it would be enought for SSH (and perhaps HTTP/WebDAV access)
> just to rely on filesystem write access to refs/heads files (different
> files having different access rights), and filesystem ACLs.

It could probably be done, but it would be very complicated. For instance, if 
a user is allowed to run prune, then they must have permissions to delete 
files which would include any of the objects.

For DAV, this breaks down completely because all access to the repository will 
happen as the Apache user.
-- 
--Andre Masella (andre at masella.no-ip.org)

Re: Repository Security

[Johannes Schindelin]

Hi,

On Tue, 23 Jan 2007, Andre Masella wrote:

> > > As I understand it, none of the repository backends allow any per-user
> > > per-branch access control.
> > The idea in git (unless you really want to get the same setup as in CVS,
> > which would be rather sad) is that every developer has at least one
> > repository. Write-access: only one developer.
> 
> Believe me: I was ready to throw a party when I got to shutdown CVS last 
> week.

Congratulations!

> Say I have two utterly separate repositories with two integrators. I 
> want to put them on a web server (and so same DAV share). There is 
> little to stop the integrator of one project (by intention or accident) 
> from modifying the other repository. It can be done, but doing it 
> requires one section of the httpd.conf per repository.

I thought you can do all the fancy WebDAV stuff with .htaccess?

> > I already hear the complaint: "But you need a central repository!". If 
> > you _have_ to have a central repository, designate the integrator's 
> > repository central.
> 
> Okay, say one regular developer wants share his changes with another 
> developer. He either has to mail patches, create an SSH account, or set 
> up one of git-daemon or WebDAV.

Most likely just start git-daemon. It's read-only (in the future, you 
might be able to enable anonymous push, but not right now), so you don't 
have to worry.

> And most of those require knowing the workstation name which is 
> inconvienient.

Umm. Oh. Okay. Didn't expect _that_ to be inconvenient.

> I would rather have each user able to push to a branch with their name 
> on it on a central server.

Really, the easiest is to setup a central server with SSH, where every 
user has an individual account. Administrating, say, a Linux box with 
literally thousands of users is a charm.

Ciao,
Dscho

Re: Repository Security

[Andy Parkins]

On Tuesday 2007 January 23 13:23, Andre Masella wrote:

> Okay, say one regular developer wants share his changes with another
> developer. He either has to mail patches, create an SSH account, or set up
> one of git-daemon or WebDAV. And most of those require knowing the
> workstation name which is inconvienient. I would rather have each user able
> to push to a branch with their name on it on a central server.

So: developer1 is allowed to make changes to central's branch br/developer1, 
say.  How is the central server going to be sure that it is developer1 
connecting?  Probably a username and password.  In which case you have a user 
account - which is what you would have with ssh.  The difference would be 
that with ssh you would have full access to all the authentication and 
authorisation mechanisms of a standard UNIX system; LDAP, NIS, timed-logins, 
etc.  If git were to implement authorisation itself then it would need all 
these modules writing again.

I don't know if this would work with git, but once you had real users, you 
could simply do
 $ mkdir refs/heads/dev1
 $ chown dev1.developers refs/heads/dev1
 $ chmod 755 refs/heads/dev1
 $ chmod u+s refs/heads/dev1
And then only dev1 would be able to write references in refs/heads/dev1.

(The above is untested in git; but with a bit more work I'm sure it could be 
made to operate)

git has a marvellous property that it won't change objects in the object 
database - it will only add new objects.  That makes it more difficult to do 
actual harm over the git-protocol.  For my few users, who already had 
accounts, and are part of a group, I simply made a group-writeable SGID 
directory for git repositories, created the repositories, set the config and 
left them to it.  With reflogs turned on, there is no damage they can do that 
can't be undone.


Andy

-- 
Dr Andy Parkins, M Eng (hons), MIEE
andyparkins@gmail.com

Re: Repository Security

[Linus Torvalds]

On Tue, 23 Jan 2007, Jakub Narebski wrote:
> 
> I wonder if it would be enought for SSH (and perhaps HTTP/WebDAV access)
> just to rely on filesystem write access to refs/heads files (different
> files having different access rights), and filesystem ACLs.

I think the solution is simple: mark the refs/ directory as being sticky.

This is really no different from the /var/spool/mail/ situation: people 
want to change their own files (and create new files), but you can't allow 
people to overwrite other peoples files and filenames.

		Linus

Re: Repository Security

[Johannes Schindelin]

Hi,

On Tue, 23 Jan 2007, Andre Masella wrote:

> > > As I understand it, none of the repository backends allow any 
> > > per-user per-branch access control. SSH and HTTP come the closest 
> > > with the right hooks, but since the repository is writeable by those 
> > > users, there is little to stop them from changing the repository 
> > > directly.
> >
> > I wonder if it would be enought for SSH (and perhaps HTTP/WebDAV 
> > access) just to rely on filesystem write access to refs/heads files 
> > (different files having different access rights), and filesystem ACLs.
> 
> It could probably be done, but it would be very complicated. For 
> instance, if a user is allowed to run prune, then they must have 
> permissions to delete files which would include any of the objects.
> 
> For DAV, this breaks down completely because all access to the 
> repository will happen as the Apache user.

I read this, and I can't help myself thinking: This would be such a 
non-issue if you had one _repository_ per-user. If they take too much 
space, set them up with "git clone --reference=<official-central>", so you 
automatically use alternates.

You would not hit the problem where two developers want to push onto the 
same branchname, too.

Ciao,
Dscho

Re: Repository Security

[Andreas Ericsson]

Andre Masella wrote:
>>> As I understand it, none of the repository backends allow any per-user
>>> per-branch access control. SSH and HTTP come the closest with the right
>>> hooks, but since the repository is writeable by those users, there is
>>> little to stop them from changing the repository directly.
>> I wonder if it would be enought for SSH (and perhaps HTTP/WebDAV access)
>> just to rely on filesystem write access to refs/heads files (different
>> files having different access rights), and filesystem ACLs.
> 
> It could probably be done, but it would be very complicated. For instance, if 
> a user is allowed to run prune, then they must have permissions to delete 
> files which would include any of the objects.
> 

Pruning is considered a "repository admin task". Since each git developer has
a full copy of the entire project locally, they can prune their local repo
as much as they like without it affecting the mothership repo.

Pruning of the mothership repo should be done by whoever administers the host
where it is hosted, and probably not even by him/her unless diskspace becomes
an issue.

We have 42 mothership repos at our workplace. Combined in those repos we've got
2962 dangling objects. Pruning them would save me 8.5MiB of diskspace. It's
hardly worth even thinking about.

> For DAV, this breaks down completely because all access to the repository will 
> happen as the Apache user.

Indeed. We use real system accounts for pushing/pulling. It's convenient for
those of us who use ssh-agent, and functional for those who don't. It also
allows "fine-grained-enough" access control to the repos.

Normally we have all repos owned by <project-leader>:devel and created with
umask 002. All developers are in the "devel" group and can thus by default
push and fetch from all repositories. Some repos require stricter access
rights. For those we create a group specially.

The "everyone can read" thingie isn't necessary, but it's nice because it
lets our head of development take a look at whatever he wants without us
running any risk of him damaging it (he's a suit after all).

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231