On 12/29/10 8:34 AM, Nico Kadel-Garcia wrote:
> 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.
So my concern is this: I want to be able to easily, clearly, and with high confidence set up SVN to *only* work via Apache, and no other way. And I think that it's not unreasonable for the admin to be able to tell "svnadmin create" which access method he plans on using.
>> 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?
Blaming the admin on software that's poorly designed and doesn't follow the most obvious of principles (the Principle of Least Astonishment being amongst them) is a cop out.
Admins today have to be competent in operating a few hundred different subsystems. Let's cut them some slack.
I'm a dev, I don't even do admin regularly, but this fell upon me because we're short-handed right now.
And I can say, as an admin a decade ago, that software that is simple and clear to setup and operate is a joy in an otherwise largely thankless job (since people only talk to you when things are broken, not when they work correctly).
> 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.
Yes, exactly. This is what I'm concerned about: lack of more visible/obvious separation between what enables Apache and what enables svnserve.
> 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.
Agreed. If you have the opportunity to make the software easier to use, why not do it?
-Philip
>>>> 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 18:04:09 CET