On Wed, Dec 29, 2010 at 10:43:13AM -0500, Nico Kadel-Garcia wrote:
> On Tue, Dec 28, 2010 at 12:24 PM, Stefan Sperling <stsp_at_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.
It is safer, yes.
There is also the possibility of using a single svnserve.conf files
for all repositories (--config-file option).
How should it behave then?
The initial concern raised in this thread was that there might exist
a hypothetical exploit of svnserve. I'm not sure if Philip was concerned
primarily about unauthorised access to repositories due to such an
exploit, or access to the server system itself. In the latter case,
your proposed change wouldn't make any difference.
I would agree with making svnserve ignore repositories by default,
unless they contain a special marker file. However, we'd have to
consider backwards compat, too. A new svnserve would suddenly stop
working in a setup that used to work fine before. We also keep telling
admins that we're never going to break their setups on purpose after
an update.
We could treat svnserve.conf itself as such a marker file, and create
a svnserve.conf.tmpl instead. However, that still leaves the question
of how to handle the case where the user passes a --config-dir.
> > 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.
svnserve is disabled by default. It doesn't start itself.
> 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,
Please point out the relevant sections of the book so someone can fix them.
Thanks.
> 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.
That admin is the real problem. There isn't much we can do to prevent
people from doing stupid things.
> 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.
Why does the svnserve process get access to the repositories served by apache?
Why aren't the repositories owned by the apache user not only readable
and writable by that user?
Or is svnserve run as root in your example?
Why doesn't the admin start svnserve in a chroot as an unprivileged user,
if he is a good admin?
> > 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.
I think this topic is much broader than svnserve.
We're essentially digressing into discussing administrator skills.
> > 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.
Because there are only 1024 privileged ports.
> 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.
They aren't enabled by default. Even in your example, someone had
to manually enable svnserve.
Stefan
Received on 2010-12-29 17:02:09 CET