Locked down (but still shared) repositories

Locked down (but still shared) repositories

[Shawn Pearce]

I have a number of repositories that I want to share across a number
of users on the same UNIX system.

For various auditing reasons the repositories need to be tightly
controlled.  That is the following cannot be permitted:

  * delete or overwrite a loose object;
  * delete or overwrite a pack file;
  * delete or overwrite a ref, except see below;
  * change the config;
  * change the description;
  * change HEAD;

The only changes that are permissible can be made through
git-receive-pack, which limits the user to only the following:

 * upload (possibly new) objects;
 * create/update/force-update a ref;
 * delete a ref;

And the latter two are controlled by a very strict update hook.
The update hook checks the ref name and real user id against
an ACL file (info/allowed-users) and checks to see if the user
can perform the requested operation against that ref, with four
operations being recognized:

  * A == the ref is being created;
  * U == the ref is being fast-forwarded;
  * R == the ref is being rewound/reset;
  * D == the ref is being deleted;

The update hook also requires that all lines returned by:

  git-rev-list --pretty=raw $3 --not --all | egrep ^committer

correspond to a name/email address combination registered in another
table for the real user id (info/allowed-committers).  Which means
we can actually trust the committer field of all commits which
are referenced by refs, as the UNIX system authenticated them.
The tagger field is also checked for every tag, but its slightly
more involved than the simple line above as it peels back the tag
layers as needed.  :)

So the update hook is update-hook-example.txt, but suffering from
extreme paranoia and has been put on steriods.  I'm considering
sending it in for Documentation/howto, or contrib.


Which brings me to the following problem:

I can't create the repository with --shared, as the UNIX users
all have normal shell access to the system.  (/bin/rm would work
wonders to let a user violate a number of the items above.)

I also cannot create secondary git-only UNIX accounts for each user,
using git-shell in the git-only account.  (For example "spearce"
and "spearce-git", with the latter using git-shell and being in a
group which does have repository access, while the former doesn't.)

The workaround that I have come up with is the following:

The repositories are all owned by a single user, and were created
without --shared, so only the owner can modify the repository.
The repositories are however readable by a specific group, and
all permitted users of that repository are members of that group.
So they can read the repository files directory, which works very
well with objects/info/alternates.  :-)

git-receive-pack on this system is owned by the same repository
owner, and is also marked setuid.  Consequently when a user pushes
into a repository the effective uid is that of the repository owner,
objects can be written, refs can be changed, the update hook runs
setuid, and it enforces everything.


The problem now is what happens when users try to use Git
as a distributed tool and push changes between their own two
repositories?  Even if the two specific users can agree on using
--shared (because maybe they actually read the Git manual and want
to use that feature), git-receive-pack runs setuid as the blessed
repository user.  Any update hook installed within one of these
'user private' repositories is untrusted, but will be running with
enough permissions to run /bin/rm and destroy data.  See above
about how I can't have that...

So I've patched git-receive-pack to refuse to run if its running
setuid and the hook's owner isn't the effective uid, or the hook
is group/world writable.  This seems to close the last hole, but
it also makes hooks/update and hooks/post-update useless in user
private repositories on this system.


I'm sending this to try and solicit better ideas from the mailing
list.  We have a lot of UNIX guru types, and a lot of Git guru types,
and they are all smarter than I...  ;-)

-- 

Re: Locked down (but still shared) repositories

[Martin Waitz]

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

hoi :)

On Thu, Dec 07, 2006 at 06:35:39AM -0500, Shawn Pearce wrote:
> So I've patched git-receive-pack to refuse to run if its running
> setuid and the hook's owner isn't the effective uid, or the hook
> is group/world writable.  This seems to close the last hole, but
> it also makes hooks/update and hooks/post-update useless in user
> private repositories on this system.

perhaps don't refuse to run, but simply change back to the safed uid?
Or use one special machine which hosts the repository and which has
the modified version of git installed.

-- 
Martin Waitz

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Locked down (but still shared) repositories

[Johannes Schindelin]

Hi,

On Thu, 7 Dec 2006, Shawn Pearce wrote:

> For various auditing reasons the repositories need to be tightly
> controlled.  That is the following cannot be permitted:
> 
>   * delete or overwrite a loose object;
>   * delete or overwrite a pack file;
>   * delete or overwrite a ref, except see below;
>   * change the config;
>   * change the description;
>   * change HEAD;
> 
> [...]
>
> I also cannot create secondary git-only UNIX accounts for each user,
> using git-shell in the git-only account.

How about just one such user? After all, you already have this user: the 
repo owner. Of course, people have to push via ssh, even on the same 
machine.

Ciao,
Dscho

Re: Locked down (but still shared) repositories

[Shawn Pearce]

Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Thu, 7 Dec 2006, Shawn Pearce wrote:
> 
> > For various auditing reasons the repositories need to be tightly
> > controlled.  That is the following cannot be permitted:
> > 
> > [...]
> 
> How about just one such user? After all, you already have this user: the 
> repo owner. Of course, people have to push via ssh, even on the same 
> machine.

How do I know which SSH key the client used to connect?  Remember I'm
looking at the real uid to determine who is performing the operation.
In the situation you describe everyone looks the same to the
update hook...

For (probably stupid) reasons the server is the commerial F-Secure
SSH server, btw.  So OpenSSH based things wouldn't apply.  And best
that I can tell, F-Secure SSH won't tell me which key was used
to authenticate.

-- 

Re: Locked down (but still shared) repositories

[Rogan Dawes]

Shawn Pearce wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>> On Thu, 7 Dec 2006, Shawn Pearce wrote:
>>
>>> For various auditing reasons the repositories need to be tightly
>>> controlled.  That is the following cannot be permitted:
>>>
>>> [...]
>> How about just one such user? After all, you already have this user: the 
>> repo owner. Of course, people have to push via ssh, even on the same 
>> machine.
> 
> How do I know which SSH key the client used to connect?  Remember I'm
> looking at the real uid to determine who is performing the operation.
> In the situation you describe everyone looks the same to the
> update hook...
> 
> For (probably stupid) reasons the server is the commerial F-Secure
> SSH server, btw.  So OpenSSH based things wouldn't apply.  And best
> that I can tell, F-Secure SSH won't tell me which key was used
> to authenticate.
> 

See Section 8.2.6.1

http://www.unix.org.ua/orelly/networking_2ndEd/ssh/ch08_02.htm

You should be able to do something similar for git as they do for SSH.

Rogan

Re: Locked down (but still shared) repositories

[Shawn Pearce]

Rogan Dawes <discard@dawes.za.net> wrote:
> Shawn Pearce wrote:
> >In the situation you describe everyone looks the same to the
> >update hook...
> 
> See Section 8.2.6.1
> 
> http://www.unix.org.ua/orelly/networking_2ndEd/ssh/ch08_02.htm
> 
> You should be able to do something similar for git as they do for SSH.

Ok, I just learned something new.  Thank you!

Forced commands on a per-key basis would certainly work.  I'm not
settled on the idea as the end solution, but it does seem to be
perhaps slightly better than the setuid approach.

-- 

Re: Locked down (but still shared) repositories

[Randal L. Schwartz]

>>>>> "Rogan" == Rogan Dawes <discard@dawes.za.net> writes:

Rogan> See Section 8.2.6.1

Rogan> http://[deleted]/orelly/networking_2ndEd/ssh/ch08_02.htm

Please don't point to pirated copies of O'Reilly (or other) books
on the web, especially when there are authors (like me) present.

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.

Re: Locked down (but still shared) repositories

[Rogan Dawes]

Randal L. Schwartz wrote:
>>>>>> "Rogan" == Rogan Dawes <discard@dawes.za.net> writes:
> 
> Rogan> See Section 8.2.6.1
> 
> Rogan> http://[deleted]/orelly/networking_2ndEd/ssh/ch08_02.htm
> 
> Please don't point to pirated copies of O'Reilly (or other) books
> on the web, especially when there are authors (like me) present.
> 

Oops. I didn't realise/think. I just googled for the keywords I needed . . .

Not a very good excuse, I admit.

Sorry.

Rogan