On Wed, Dec 29, 2010 at 11:01 AM, Stefan Sperling <stsp_at_elego.de> wrote:
> 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.
That's unclear, I agree. I've taken it in a slightly different
direction, trying to address his concerns.
> 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.
Right. The easy way is to publish svnserve.conf.tmpl, and not publish
svnserve.conf. Old repositories will continue to work, repositories in
which svnserve.conf does not exist *would* stop working, but I think
that's pretty non-standard and could be covered by a change
announcement, perhaps as part of the 1.7 release.
>> > 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.
No, it's inactive, not disabled. That's an important distinction.
>> 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.
The "Invoking the server" chapter would seem the obvious location. A
comment that "svnserve works by default against new repositories",
with a paragraph added about enabling the service with the
svnserve.conf file if the "svnserve.conf.tmpl" change gets accepted
would do it.
If folks like, I'll think about how to insert this gracefully in that section.
>> 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.
They are *one* problem. And what we can do is what I've just
described: make it not merely "inactive" but "disabled" by default.
>> 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?
Because the documentation is wrong. Here it it.
> If you've decided to use either Apache or stock svnserve, create a single svn user on your system and run the server process as that user. Be sure to make the repository directory wholly owned by the svn user as well. From a security point of view, this keeps the repository data nicely siloed and protected by operating system filesystem permissions, changeable by only the Subversion server process itself.
In fact, the documentation above is extremely misleading. An
additional step is necessary to *remove* access by others, on every
normal user or system configuration I've ever seen.
> 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?
The common approach *is* to use an unprivileged user. But see above:
the locking out of non-designated users from read or write access to
Subversion repositories is under-documented.
Setting up repositories to do this for two users, such as "apache" and
"svn", is even more fun and creates its own security overlap issues.
Coupled with the "svnadmin hotcopy" lack of preservation of group
permissions or sgid bits, and it's even more adventuresome.
These sorts of issues are why I discourage trying to support multiple
access technologies for one repository. Use HTTP for read-only if you
need it, but use svn+ssh for write access: that's relatively easy to
manage with "apache" a member of a group with read access and POSIX
permissions set to "2750" for the directories.
>> > 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.
And what happens in normal situations.
>> > 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 getting one allocated is awkward, yes, I remember when SSH got allocated.
>> 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.
See above. It's inactive, not disabled.
Received on 2010-12-29 17:34:59 CET