Re: Audit logging - where to hook?

379 views
Skip to first unread message

Magnus Bäck

unread,
Jun 26, 2012, 9:37:57 AM6/26/12
to repo-d...@googlegroups.com
On Tuesday, June 26, 2012 at 09:08 EDT,
Gavin Hamill <g...@acentral.co.uk> wrote:

> I'm fairly green to DVCS, having come from an SVN sysadmin background.
> Our organisation would like to implement Git as its VCS but has the
> typical enterprise concerns regarding access control and audit trail.
>
> We started with gitolite, but I believe Gerrit is better suited to our
> needs, GUI ACL and SSH key management being the main reasons - we
> don't yet have a requirement for code review.
>
> However, on the topic of audit trail the waters are rather more
> murky..
>
> Since one can set user.email and user.name to anything, I'm thinking
> of a hook (pre-receive ?) to verify the user.email used in the
> Author/Committer field against our company directory. The SSH key
> used for the push should map to a username I can look up in the LDAP
> directory and match that the LDAP 'mail' attribute matches the
> user.email from Git, right?

Gerrit already does this for you. Via ACLs you can select which users
should be allowed to forge their author email or their committer email.
For practical reasons you'll probably want the author email to be
forgeable (and it's the default), but regular users typically don't
need the ability to forge the committer email.

http://gerrit-documentation.googlecode.com/svn/Documentation/2.4/access-control.html#category_forge_author

> This is OK as far as the simple centralised workflow goes; it will
> break when Author != Committer for Integration-Manager workflow,
> cherry-picking, etc. but that's OK - team projects enjoy their own
> level of policing at the social + business level.

Right.

> So, new code going into the repo can be watched but I'm curious if a
> sane logging format can be enforced for read operations like cloning?
>
> Much of this is within Git itself rather than Gerrit, but if Gerrit is
> providing the ssh daemon then there might be an opportunity to dive a
> bit deeper...

The sshd_log logfile logs the following information for clone/fetch
operations:

[2012-06-26 09:32:18,807 -0400] 6cea5c08 baeck a/1000000 LOGIN FROM <client IP address>
[2012-06-26 09:32:19,718 -0400] 6cea5c08 baeck a/1000000 'git-upload-pack '\''/test'\''' 237ms 647ms 0
[2012-06-26 09:32:19,756 -0400] 6cea5c08 baeck a/1000000 LOGOUT

So, you get the SSH username, client IP address, which repository, and
some timing information whose exact interpretation has escaped me.

--
Magnus Bäck
ba...@google.com

Luca Milanesio

unread,
Jun 26, 2012, 10:00:47 AM6/26/12
to Gavin Hamill, repo-d...@googlegroups.com
Hi Gavin,
there is as well a proposal for an "audit-trail" hook in order to generate an audit-trail that could be use for Enterprise Compliance reasons.
(i.e. CMMI or SOX)

See: 

As sample plug-in to log events to an SL4J logger:

Hope this helps.

Luca.

On 26 Jun 2012, at 14:08, Gavin Hamill wrote:

Hullo,

I'm fairly green to DVCS, having come from an SVN sysadmin background. Our organisation would like to implement Git as its VCS but has the typical enterprise concerns regarding access control and audit trail.

We started with gitolite, but I believe Gerrit is better suited to our needs, GUI ACL and SSH key management being the main reasons - we don't yet have a requirement for code review.

However, on the topic of audit trail the waters are rather more murky..

Since one can set user.email and user.name to anything, I'm thinking of a hook (pre-receive ?) to verify the user.email used in the Author/Committer field against our company directory.  The SSH key used for the push should map to a username I can look up in the LDAP directory and match that the LDAP 'mail' attribute matches the user.email from Git, right?

This is OK as far as the simple centralised workflow goes; it will break when Author != Committer for Integration-Manager workflow, cherry-picking, etc. but that's OK - team projects enjoy their own level of policing at the social + business level.

So, new code going into the repo can be watched but I'm curious if a sane logging format can be enforced for read operations like cloning?

Much of this is within Git itself rather than Gerrit, but if Gerrit is providing the ssh daemon then there might be an opportunity to dive a bit deeper...

Cheers,
Gavin.



--
To unsubscribe, email repo-discuss...@googlegroups.com
More info at http://groups.google.com/group/repo-discuss?hl=en

Shawn Pearce

unread,
Jun 26, 2012, 11:36:18 AM6/26/12
to Gavin Hamill, repo-d...@googlegroups.com
On Tue, Jun 26, 2012 at 7:34 AM, Gavin Hamill <g...@acentral.co.uk> wrote:
> It seems that after several iterations this plugin system must be getting
> close to being accepted into the master branch - do you think it's something
> we can expect to see in a released version of Gerrit in the next weeks, or
> would it be a longer term major-version feature?

I expect this to merge soon. I am just really backlogged on code
reviews. The last patch set I read was pretty promising for inclusion.

Luca Milanesio

unread,
Jun 26, 2012, 12:38:03 PM6/26/12
to Shawn Pearce, Gavin Hamill, repo-d...@googlegroups.com
Thanks Shawn,
I am rebasing the change anyway on the current master and keeping it up-to-date as much as possible.

Focusing now on the hooks plugins (good progress there).

Luca.

Shawn Pearce

unread,
Jun 26, 2012, 1:10:07 PM6/26/12
to Gavin Hamill, repo-d...@googlegroups.com
On Tue, Jun 26, 2012 at 8:39 AM, Gavin Hamill <g...@acentral.co.uk> wrote:
> So, if I edit, add, commit and push a one-line comment to hello.pl:
>
> gerserv@gdh-sanmonitor:~/t/Twirly$ git push
> Counting objects: 5, done.
> Compressing objects: 100% (2/2), done.
> Writing objects: 100% (3/3), 279 bytes, done.
> Total 3 (delta 1), reused 0 (delta 0)
> remote: Resolving deltas: 100% (1/1)
> remote: Processing changes: refs: 2, done
> remote:
> remote: ERROR: In commit 5565833d45754db576c2786504e4c65d97049747
> remote: ERROR: author email address ger...@gc-tacacs.lab.admin.my.net.uk
> remote: ERROR: does not match your user account.
> remote: ERROR:
> remote: ERROR: You have not registered any email addresses.
> remote: ERROR:
> remote:
> remote:
> To ssh://gerrit/Twirly.git
> 4e474bb..5565833 master -> master
>
> Despite those expected and very welcome ERROR lines, the commit still made
> it to the master branch:

What version of Gerrit is this? If I remember we had a breakage where
this wasn't aborting, but was fixed.

Luca Milanesio

unread,
Jun 27, 2012, 5:08:07 AM6/27/12
to Shawn Pearce, Gavin Hamill, Repo and Gerrit Discussion
Hi Shawn,
because of a messy rebase (apologies, my fault with patch-set#15) the Log4J problem was still there.

I've resumed now the correct fix (including the changes requested on patch-set#11) plus the additional ones you mentioned on patch-set#15.

The valid patch-set is:
https://gerrit-review.googlesource.com/#/c/35184/17

Luca.

On 26 Jun 2012, at 16:36, Shawn Pearce wrote:

Gavin Hamill

unread,
Jun 27, 2012, 5:08:35 AM6/27/12
to repo-d...@googlegroups.com, Gavin Hamill
Morning, 

Hm, there must have been a regression in 2.4, because 2.4.2 is doing the Right Thing:

gerserv@gdh-sanmonitor:~/t/Twirly$ git pull
Already up-to-date.
gerserv@gdh-sanmonitor:~/t/Twirly$ nano hello.pl
gerserv@gdh-sanmonitor:~/t/Twirly$ git add hello.pl
gerserv@gdh-sanmonitor:~/t/Twirly$ git commit
[master 24d2462] Very damp indeed
Your name and email address were configured automatically based
on your username and hostname. Please check that they are accurate.
You can suppress this message by setting them explicitly:

    git config --global user.name "Your Name"
    git config --global user.email y...@example.com

If the identity used for this commit is wrong, you can fix it with:

    git commit --amend --author='Your Name <y...@example.com>'

 1 files changed, 1 insertions(+), 0 deletions(-)
gerserv@gdh-sanmonitor:~/t/Twirly$ git push
Counting objects: 5, done.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 295 bytes, done.
Total 3 (delta 1), reused 0 (delta 0)
remote: Resolving deltas: 100% (1/1)
remote: Processing changes: refs: 1, done
remote:
remote: ERROR:  In commit 24d2462bdec71b1ec56f7d1149e41e357af439b9
remote: ERROR:  author email address ger...@gc-tacacs.lab.admin.my.net.uk
remote: ERROR:  does not match your user account.
remote: ERROR:
remote: ERROR:  The following addresses are currently registered:
remote: ERROR:    g...@spamoff.acentral.co.uk
remote: ERROR:
remote: ERROR:  To register an email address, please visit:
remote:
remote:
To ssh://gerrit/Twirly.git
 ! [remote rejected] master -> master (invalid author)
error: failed to push some refs to 'ssh://gerrit/Twirly.git'

So let's try again with the correct address:

gerserv@gdh-sanmonitor:~/t/Twirly$ git config --global user.email g...@spamoff.acentral.co.uk
gerserv@gdh-sanmonitor:~/t/Twirly$ git commit --amend --author='Gavin Hamill <g...@spamoff.acentral.co.uk>'
[master 8b773a1] Very damp indeed
 Author: Gavin Hamill <g...@spamoff.acentral.co.uk>
 1 files changed, 1 insertions(+), 0 deletions(-)
gerserv@gdh-sanmonitor:~/t/Twirly$ git push
Counting objects: 5, done.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 298 bytes, done.
Total 3 (delta 1), reused 0 (delta 0)
remote: Resolving deltas: 100% (1/1)
remote: Processing changes: refs: 1, done
To ssh://gerrit/Twirly.git
   5565833..8b773a1  master -> master

Cheers,
Gavin.

Saša Živkov

unread,
Jun 29, 2012, 3:23:51 AM6/29/12
to Gavin Hamill, repo-d...@googlegroups.com
On Wed, Jun 27, 2012 at 11:08 AM, Gavin Hamill <g...@acentral.co.uk> wrote:
> Morning,
>
> Hm, there must have been a regression in 2.4, because 2.4.2 is doing the
Yes, there was a regression and was fixed in 2.4.1. See the release notes [1]
and search for "regression".

Saša

[1] http://gerrit-documentation.googlecode.com/svn/ReleaseNotes/ReleaseNotes-2.4.1.html
Reply all
Reply to author
Forward
0 new messages