On Sun, Oct 30, 2011 at 12:26 PM, Les Mikesell <lesmikes...@gmail.com> wrote: > On Sat, Oct 29, 2011 at 11:27 PM, Nico Kadel-Garcia <nka...@gmail.com> wrote: >>> >>> Yes, but the packaged linux versions pretty much just come up working >>> under http(s) with a appropriate line or two added to the packaged >>> configuration to point to the repository location, and once a network >>> server works, svnsync 'just works' to back it up from elsewhere. >> >> Les, I'm afraid that's handwaving. Like implementing Wikis and FTP >> sites, it leaves out the boobytraps. Let's look specifically at the >> HTTP setup. The one in Fedora 15's subversion-1.6.17 is pretty good, >> and I'm using it myself in the SRPM for 1.7.1 Unfortunately, it has >> the profound flaw that it explicitly recommends creating the >> repositories owned by the "apache" user. But this leaves not merely >> the Subversion database, but the *configuration* and hook scripts for >> the Subversion repository owned by the "apache" user, so any other PHP >> script or poorly secured services running on that HTTP server can edit >> *anything* in the Subversion repository, unmanaged by and unknown to >> the repository maintainer. > > So if it hurts, don't do that. It is hardly subversion's fault that > running other services under the same uid exposes all of those > services to more code that can be subverted - but you don't have to > run other services on the same machine and more specifically you don't > have to give people you don't trust administrative access to install > that code.
This is turning into a security rant, a merry-go-round I've been on before for Subversion. In many setups, the "apache" user has only read access to the filesystem, including to /var/www/html and similar software repositories. In others, where additional access is needed, the ""suexec" utilities are workable. Unfortunately, for Subversion, suexec is not workable. (It relies on well-defined CGI utilities, and is incompatible with mod_dav.) It's possible to run a separate HTTP daemon on another port or a virtual IP address, but it's not well defined or supported. An ordinary newbie Subversion administrator *will not be aware* of these security issues. Precisely as you've shown, it's considered "not our problem" by the Subversion source developers. >> Worse, there are setups where both HTTP and >> SSH are used to access the same repository. And suddenly pre-commit >> and post-commit scripts can be manipulated by another HTTP "apache" >> owned process, and later get run if *root* comes in via SSH. > > If it hurts... Which we can successfully translate as "Not our problem". You then go on to give basically the same answer to the other three issues I raised. Unfortunately, security *IS* a big problem for source control systems, especially publicly exposed ones, and worse yet for ones where passwords may be stored in configuration data or passwords may be based on normal user login credentials. After all the hardwork and policy decisions to prevent any modification or deletion of old revisions, because source control is considered sancrosanct and once it's in source control, it should naver be modified, it violates the basic idea of provenance of that source control to leave it writable by others. But that's "not our problem", right? You have to "trust your system", because "if they're on the system, you have bigger problems". I've been hearing that one a lot, for decades. It was and remains a common though fundamentally broken approach to security for many open source utilities. In particular, web-based services tend to put each other at risk by paying no attention to shared access to what should be distinct resources. These sorts of issues are precisely why I only allow SSH key based access to a designated "svn" user account: that "svn" account is designated to repository ownership. It's also why Sourceforge does much the same thing, with different "users" for different repositories. We could explore how that's manageable, but it's a different subject. If Pietro or others are intersted, we could review it.
