On Tue, Dec 28, 2010 at 11:58 AM, Philip Prindeville <philipp_s...@redfish-solutions.com> wrote: > On 12/28/10 3:44 AM, Stefan Sperling wrote: >> >> On Mon, Dec 27, 2010 at 01:28:34PM -0800, Philip Prindeville wrote: >>> >>> On 12/27/10 11:34 AM, Ryan Schmidt wrote: >>>> >>>> On Dec 24, 2010, at 23:34, Philip Prindeville wrote: >>>> >>>>> Unfortunately, the documentation and utilities in a few places are less >>>>> clear than they could be when discussing repository setup for svnserve >>>>> versus svnserve+ssh versus apache. >>>>> >>>>> For instance, "svnadmin create" deposits various files there: >>>>> >>>>> conf/svnserve.conf >>>>> conf/passwd >>>>> >>>>> which are useful for svnserve... but not for Apache access. >>>> >>>> So if you're not using svnserve, just ignore those files. >>> >>> We'd rather not have files laying around not serving a purpose... >>> especially if in some future version they start being meaningful again >>> and their contents implicitly grant some sort of access. >> >> The configuration files won't suddently change their purpose in a >> future version of Subversion (maybe in 2.0, but not before). >> >>> When securing a machine, you start by closing everything up, and then >>> opening up just what you need to accomplish the mission. "Closing >>> everything up" in this context would include removing unused >>> configuration files. >> >> I don't understand why unused configuration files would be a security >> risk. >> >> The important bit about security is that admins understand how to >> configure >> the application they're setting up. They can then configure it securely. >> I suppose your real concern is that you or others would get distracted >> by those files. Which implies a lack of understanding about how the >> system is or has been configured. I'd say the real problem here is >> documenting your setup properly and making sure everyone involved knows >> what this documentation says. > > If I know that they're used only by svnserve and I'm never going to use > svnserve, maybe I don't want they lying around just to svnserve will never > be run (by a hacker for an exploit). > > That seems pretty straigthtforward.
Disabled entirely would be better, and safer, than empty. Subversion's security models have historically been very lax. This is inherited from its origins in CVS, and the attitude that "if you don't trust your machine, you shouldn't be using it!!!". It's also played out in the historically clear-text storage of user passwords for HTTP and HTTPS access in $HOME/.subversion/. That feature needs not merely to issue a client warning, and it remains a compelling reason to use svn+ssh, despite the lack of a graceful key management tool for Subversion. (Yes, I've sung this song before.) It's an underlying security model problem. Subversion security remains an after-thought to its design, with the result of admin's having to create their own security models on the fly rather than it being integral to the software. >>> In short, ignoring the files isn't an option. >> >> Many UNIX-like operating systems come with configuration files in /etc >> for applications that aren't being run unless the user enables them. >> People ignore those files all the time. > > Rarely are they for network services. Well, this is not exactly true. For RHEL and the like, /etc/httpd is often populated by verious services that require manual activation, as is /etc/xinetd.d/. MRTG, Bugzilla, ViewVC, and Nagios all come with configurations that are inactive by default. Dont' get me *started* on Trac.... (Trac and ViewVC are particularly relevant to Subversion managers.) >> In any case, you're free to simply remove configuration files that >> "svnadmin create" creates. But I don't see a point in adding an >> option for this because it doesn't seem to be a very common need. >> >> Stefan Keeping them entirely disabled in an svnserve.conf file would be more sensible. As Stefan pointes out elsewhere, svnserve will run without an svnserve.conf. Perhaps it *shouldn't*, and the default svnserve.conf should be published as svnserve.conf.tmpl? That would force manual enabling of a service that should not be available by default.
