RE: Integrity checking for FSFS repositories.. tripwire, etc.?

If there are reservations against having it publicly viewable, then
simply do not make it publicly accessible.

Simply set-up the Server instance within your firewalled network, then
set-up a VPN server. Distribute VPN clients to whomever is authorized
(of course, that allows even greater freedoms of additional security).
Then, for contributors to actually even see and/or the server, they'd
simply VPN into the network first, then no worries; network-wise, it's
as though the users are physically inside your firewall.

Once anything is meant for the outside world, simply set-up a second
server with read-only permissions; if users wish to contribute, then
they should ask you guys and you can have any/every security measures
desired before sharing VPN software.

This is what my set-up is, and even though anybody can obtain VPN
software, nobody has user auth access except whom we choose; and we can
disable access on-the-fly.

- nasser

Nasser Dassi
Sr. Technical Programmer
=========================================
E: ndassi@141xm.com
=========================================

-----Original Message-----
From: Jonathan Abbey [mailto:jonabbey@arlut.utexas.edu]
Sent: Tuesday, April 05, 2005 11:15 AM
To: users@subversion.tigris.org
Subject: Integrity checking for FSFS repositories.. tripwire, etc.?

Hi, folks. My boss is having some discomfort with us putting some of
our internal (though open source and intended for public consumption)
software out on a publicly accessible repository. I'm using the
latest versions of Apache, OpenSSL and Subversion with FSFS, and I've
got AuthzSVNAccessFile controls in place, a post-commit hook sending
email whenever any commits are made.. all that. We've got backups
made every night as well.

I'm pretty confident that we're not going to lose anything, but my
boss is concerned that someone could penetrate the server and modify
our source code without our noticing, and I don't know how hard or
easy that would be to do.

One thought would be to use Tripwire or AIDE somehow to do
verification on committed transctions in the FSFS repository. I can
imagine running Tripwire every hour or so to 'lock in' the state of
previously committed transactions. It seems that it might be possible
to get to the point that any corruption would have then to be done by
adding a new transaction to the repository, which would presumably
show up when I do an 'svn status -u' or an update or the like.

Alternatively I could imagine maintaining two repositories, one on the
outside and one on the inside, and having changes propagate one from
the other through a post-commit hook that sent email as part of the
commit process. If the two repositories ever got out of sync, that
might be a clue that someone had made a change in such a way as to
bypass the post-commit hook (and thus the email).

Anyone come up with any good practices for guarding against this sort
of attack?

Thanks,

 Jon

-- 
------------------------------------------------------------------------
-------
Jonathan Abbey
jonabbey@arlut.utexas.edu
Applied Research Laboratories                 The University of Texas at
Austin
GPG Key: 71767586 at keyserver pgp.mit.edu,
http://www.ganymeta.org/workkey.gpg
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org