On 12/29/10 8:34 AM, Nico Kadel-Garcia wrote:
On Wed, Dec 29, 2010 at 11:01 AM, Stefan Sperling<s...@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<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.
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.
