On Tue, Dec 28, 2010 at 12:24 PM, Stefan Sperling <s...@elego.de> wrote: > On Tue, Dec 28, 2010 at 12:11:47PM -0500, Nico Kadel-Garcia wrote: >> 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. > > svnserve reads the repository's svnserve.conf file when it receives > a client request concerning this repository. In other words, there is > nothing we can do in the repository-specific svnserve.conf file to prevent > svnserve from starting in the first place.
Right. At the point where svnserve tries to read the svnserve.conf, it could be configured to fail if the file is inaccessible. This is vastly safer than automatically persevering and running an unconfigured service. > Also, I don't understand how starting svnserve would help an attacker > since to start svnserve the attacker would already need access to > the system. > > Users with shell access to the system can of course run their own > svnserve instance on an unprivileged port (and svnserve runs on an > unprivileged port by default). This is a basic security principle. Everything not explicitly needed should be disabled. Allow me to present a very common situation. The administrator spends their time on the Apache access, and carefully selects a thoughtful setup to manage it, tests it, and is satisfied that read-access is only available to authorized users. They even carefully set the configuration files, themselves, to be owned by an administrator user rather then same "Apache" or other user for the web access. They don't even realize that svnserve will work by default. They don't bother to disable it because it's not well documented in the manual pages or red book, or another less careful admin enables the default "svnserve" service in xinetd.d because they don't realize the danger. And they, or another admin who doesn't realize that the Apache service and svnserve security models are quite orthogonal, enables svnserve. It's also a high-numbered port. Any schmuck with shell access can start up the service, by default, on the standard access port. *BOOM*, all the thoughtful Apache configuration work is ignored. > There is no way to prevent this. The user might even copy an svnserve > binary from a remote system and run it. Well, yes. Guard rails don't block people who insist on climbing over the rail. But putting the guard rail in place to remind people that it's dangerous to go there is reasonable, especially when the guard rail is so simple. > But the same is true for any other network daemon that can be run on > an unprivileged port. You're treating the "unprivileged port" exactly backwards. As software developers and project contributors, it's our responsibility to make the default configurations as safe as possible, not say "oh, it's in unprivileged port so we won't even care". Why such a system service was ever put on an unprivileged port is a separate matter for discussion. And Subversion has some of the most well known for configuration issues with the multiple access methods. Multiple access methods are useful, but leaving multiple ones enabled by default is very awkward.
