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
- application/pgp-signature attachment: stored
Received on Tue Apr 5 17:22:34 2005