$Revision: 1.23 $
$Date: 2006/09/02 09:34:22 $
This document is not supported, approved or endorsed by the Subversion project in any way. Opinions and views stated in this document may or may not be shared by the Subversion project. We don't know.
Subversion is a new software configuration management tool intended to replace CVS.
This document aims to be a guide for Subversion developers on improving many security aspects of the Subversion tools - as well as being a guide to Subversion users on how to protect the content of their repository from unauthorized access or modification.
As the Subversion project improves, this document will reflect that progress.
As the user-oriented documentation in this document becomes useful over the coming days, it will be offered back to the Subversion project for inclusion in the outrageously well-written book, Version Control with Subversion.
Where CVS had pserver, rshd and sshd as remote access methods, Subversion has Apache httpd, svnserve and sshd. Subversion supports Apache httpd, standalone svnserve and svnserve wrapped in a SSH connection as methods of remotely accessing a repository.
In the security world, any boundary exposed to an untrusted party (such as the internet) is called an attack surface - it is what an attacker has to work with. He can pretend to be a Subversion client but supply hostile data rather than well-formed WebDAV requests. This is not to say that the number of access methods supported by Subversion is a security risk. Of course, a particular access method is only a risk if it is active and available to an untrusted party.
An attack surface is usually measured in lines of code or sometimes number of function calls. The smaller surface, the less exposed target. The fewer lines of code that are executed with user input, the less risk of a security bug. The more simple a piece of code is, the easier it is to avoid or spot security bugs during development.
The Subversion team engages in peer review of commits and patches, but does not routinely make a habit of actively revisiting exposed areas of the source code, looking for issues.
The Subversion team is very serious about repository integrity. They work hard to avoid bugs that could lead to corrupt repositories. That same effort should be applied to avoiding bugs that could lead to security compromises.
Subversion can get to the point where:
It is hoped that the Subversion team will work toward improving their software design and development procedures:
Administrators have several options for protecting the confidentiality, integrity and/or availability of their repository. Just having the understanding that attackers need vulnerable code to do harm is a good start. The less code an attacker can access, the better.
By that token, administrators are urged to restrict anonymous access to their repository. This may be done in several ways, depending on the resources available and the acceptable risks in the given situation:
If I may be so frank: That is vague and insignificant question. If we said either 'yes' or 'no', what difference would it make? We are willing to bet large amounts of money that you would rather have an answer to "Does Subversion comply with my security policy?" or even "Can Subversion be made compliant with my security policy?"
As we have no idea what requirements your security policy dictate, we can only answer the latter question: "Yes, most likely." -- the wide range of access methods, access control and authentication makes Subversion quite flexible.
That is not a question, but yes, it does. To encrypt something, you need a key. If the key is on-disk alongside an encrypted password, what is the point? Windows and MacOS X have a mechanism for keeping passwords encrypted, but most other systems do not.
If you want to avoid storing passwords in plain text, use svn+ssh with keys, or https with client certificates.
svnserve may be used both as a stand-alone network daemon or invoked by each user via ssh as described below.
A lot of fear seems to exist around the notion of creating system accounts and giving people associated with a project access to these accounts. Such fear is unfounded these days.
Most modern systems are perfectly capable of restricting which commands a given user can run once they have authenticated. Forcing a user to run the 'svnserve' binary after performing two-factor authentication is by far a smaller security risk than running something as big and new like a default Apache 2 exposed to the entire internet.
If you have multiple repositories, the svn+ssh method makes your operating system make the decision on which user is allowed to access a particular repository. With the http method, these access decisions are made by a component of Subversion. Access control inside a repository is handled by the Subversion component regardless of the method of access.
These days, the OpenSSH server runs with privilege seperation and chroot support. A default install of OpenSSH has only a few thousand lines of code running as root. All the complex stuff is handled by a non-privileged process. A flaw in this code keeps the intruder inside a chroot with no tools. While this is not perfect and by no means should be taken as an indication your servers never need upgrading again, it means the attacker has to work all that much harder, giving you more time to patch your system and catch any attempts to break in.
You can further reduce the attack surface of sshd by:
When creating accounts, set the shell to point to the svnserve wrapper script instead of a command interpreter. This forces the user to invoke a svnserve process in the manner intended. To cause harm to your system, an authorized user would have to find a flaw in svnserve. One would hope your monitoring would identify such attempts. (If you don't have monitoring set up that would detect these things, you don't really care about security.)
If an unauthorized user can impersonate an authorized user, the svnserve binary is the last obstacle to a regular system account. This is the reason your system, if at all possible, should allow only two-factor authentication.
Exposing your repository to authorized users via svn+ssh is probably the method involving the lowest risk to your system and data.