I've just been reading about a remote vulnerability in CVS, documented here:
http://security.e-matters.de/advisories/012003.html
That advisory also links to a HOW-TO on running a secure, chroot-ed CVS:
http://www.netsys.com/library/papers/chrooted-ssh-cvs-server.txt
This got me thinking about SVN in light of similar security concerns. In
particular, I know a few paranoid Unix sysadmins who always run things
in the most secure mode (like chroot-ed), and won't consider running
remotely-accessable services if the program appears liberal in its
file access.
Would such a paranoid sysadmin be happy with SVN, and would she have a
hard time or an easy time setting up SVN securely?
As an example, could SVN be chroot-ed (from thinking about it, I'd say
it probably can)? It gets more complicated when we consider the multiple
access layers SVN has; for example can SVN + apache + mod_dav be easily
secured?
When I am talking about security here, it is in the context of remote
entities getting access to a process running within a server. If
something went wrong (either a deliberate compromise, or just some
bug), what is the worse thing that could go wrong? And how can we
limit what this worse thing is?
I also realize that such security measures can come with complexity and
pain, for users and/or sysadmins; like using SSL certificates for ra_dav
over https... why do I now need a certificate to access this stupid
repository ;-) . But some sysadmins are sufficiently paranoid.
If we can come up with some techniques and recommendations for securing
SVN in this manner, it may be worth-while putting it into its own HOW-TO
in the SVN documentation.
Just food for thought,
=Matt Quail
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 14 02:05:29 2006