Providing customized source code control with CVS

Security is always a balance between keeping things safe and getting the work done, and so it is necessary to know the vulnerable parts of a system to properly secure it. CVS usually contains some very valuable contents, and it is more worth while securing than much of the rest of your network.

Many organizations have some sort of security in their connection to the Internet, and a very relaxed attitude inside. This is often appropriate, but the CVS repository should have some sort of internal security also. This protects the repository from a disgruntled employee or a random bad guy who breaks through the firewall.

There are three attacks in particular that I would be concerned with.

• An attacker who can get access to the repository can trash it any way he or she likes. For this reason, I recommend having a separate server with limited login access.
• An attacker who can execute "cvs admin" commands can effectively destroy the files in the repository. For this reason, I recommend limiting the ability to use "cvs admin" to administrators, which is accomplished by creating the Unix group "cvsadmin" on the server and restricting it to the administrators.
• An attacker who can manipulate files in CVSROOT can cause other people to execute arbitrary programs without realizing it, potentially trashing the repository. For this reason, I recommend restricting access to CVSROOT to administrators. This can be done by assigning CVSROOT to the "cvsadmin" group and removing all permissions other than owner and group.

Other attacks have less serious consequences. It is possible for an attacker with normal CVS access to make a mess of the repository, but nothing that cannot be fixed, except reconstructing tags if they have not been recorded earlier. As long as there is some accountability, this will generally be an acceptable risk.

All contents of these pages Copyright 2002 by David H. Thornley.
Permission granted for verbatim copying and use within an organization.