4

I'm a Systems Admin supporting a team of developers, and our subversion repository is protected by HTTP basic authentication tied to a single-signon solution. We also share our infrastructure with some other teams and subs. The developers want an account they can use to automatically write to the SVN (e.g. automatically checkin some generated scripts, or automatically publish entire releases to a directory), either by storing the account password within the script or using SSH for passwordless login.

A colleague of mine over in IT thinks that this would be a very bad idea, and I'm inclined to agree, there seems to be a very high security risk both from malicious intent or just a badly written script gone haywire and wreaking havoc on the repository. However, more people and other teams and subs keep asking for it, and when I've tried to do some of my own research I haven't been able to find any supporting material to help me convince them, which makes me wonder if I'm wrong and it's not as bad as I think it is.

Am I right about the potential security threat these automated scripts pose to our repository? Are there any alternatives or protective measures that I'm missing? If not, can anyone point me in the direction of any supporting material out there that might help me get the point across?

[Edit] I forgot to mention we also use Jenkins for continuous integration: http://en.wikipedia.org/wiki/Jenkins_%28software%29

JPautsch
  • 43
  • 4
  • 1
    Have you considered using a distributed version control system instead or in addition to SVN? If the users had something like git-svn available, they could make checkins to their local repo, and possibly push to a repo on a dev box. – Zoredache Mar 27 '12 at 20:18

1 Answers1

3

Well, the security risk in allowing these kinds of commits is completely dependent on the sensitivity level of your repository.

Since you're doing continuous integration, bad commits can certainly burn you.. though there's obviously mechanisms in place to roll back bad changes, as quickly as the bad commit can be manually rolled back. Accepting that risk is a business decision, in the end.

It depends what the scripts are doing, but there's definitely some risk mitigation that you can do;

  • Make sure all automated commits are not being done with developers' normal accounts. You don't want those passwords saved.
  • If possible, can you restrict the automated-committing users to committing to only specific files or directory trees?
  • Again, if possible, consider a pre-commit hook that does some sanity checking on the commits coming in from the automated tasks (block the commit if any delete actions occurred, or if more than 50 lines of code changed?) - this can potentially catch and prevent letting in the kind of destructive commits that you're concerned with.

On the other hand, if your devs are just trying to do this so they don't need to type svn commit and actually enter a decent commit message, then absolutely shoot them down.

Shane Madden
  • 114,520
  • 13
  • 181
  • 251