On Sun, Oct 30, 2011 at 12:26 PM, Les Mikesell <lesmikesell_at_gmail.com> wrote:
> On Sat, Oct 29, 2011 at 11:27 PM, Nico Kadel-Garcia <nkadel_at_gmail.com> wrote:
>>>
>>> Yes, but the packaged linux versions pretty much just come up working
>>> under http(s) with a appropriate line or two added to the packaged
>>> configuration to point to the repository location, and once a network
>>> server works, svnsync 'just works' to back it up from elsewhere.
>>
>> Les, I'm afraid that's handwaving. Like implementing Wikis and FTP
>> sites, it leaves out the boobytraps. Let's look specifically at the
>> HTTP setup. The one in Fedora 15's subversion-1.6.17 is pretty good,
>> and I'm using it myself in the SRPM for 1.7.1 Unfortunately, it has
>> the profound flaw that it explicitly recommends creating the
>> repositories owned by the "apache" user. But this leaves not merely
>> the Subversion database, but the *configuration* and hook scripts for
>> the Subversion repository owned by the "apache" user, so any other PHP
>> script or poorly secured services running on that HTTP server can edit
>> *anything* in the Subversion repository, unmanaged by and unknown to
>> the repository maintainer.
>
> So if it hurts, don't do that. It is hardly subversion's fault that
> running other services under the same uid exposes all of those
> services to more code that can be subverted - but you don't have to
> run other services on the same machine and more specifically you don't
> have to give people you don't trust administrative access to install
> that code.
This is turning into a security rant, a merry-go-round I've been on
before for Subversion.
In many setups, the "apache" user has only read access to the
filesystem, including to /var/www/html and similar software
repositories. In others, where additional access is needed, the
""suexec" utilities are workable. Unfortunately, for Subversion,
suexec is not workable. (It relies on well-defined CGI utilities, and
is incompatible with mod_dav.) It's possible to run a separate HTTP
daemon on another port or a virtual IP address, but it's not well
defined or supported.
An ordinary newbie Subversion administrator *will not be aware* of
these security issues. Precisely as you've shown, it's considered "not
our problem" by the Subversion source developers.
>> Worse, there are setups where both HTTP and
>> SSH are used to access the same repository. And suddenly pre-commit
>> and post-commit scripts can be manipulated by another HTTP "apache"
>> owned process, and later get run if *root* comes in via SSH.
>
> If it hurts...
Which we can successfully translate as "Not our problem". You then go
on to give basically the same answer to the other three issues I
raised.
Unfortunately, security *IS* a big problem for source control systems,
especially publicly exposed ones, and worse yet for ones where
passwords may be stored in configuration data or passwords may be
based on normal user login credentials. After all the hardwork and
policy decisions to prevent any modification or deletion of old
revisions, because source control is considered sancrosanct and once
it's in source control, it should naver be modified, it violates the
basic idea of provenance of that source control to leave it writable
by others.
But that's "not our problem", right? You have to "trust your system",
because "if they're on the system, you have bigger problems". I've
been hearing that one a lot, for decades. It was and remains a common
though fundamentally broken approach to security for many open source
utilities. In particular, web-based services tend to put each other at
risk by paying no attention to shared access to what should be
distinct resources.
These sorts of issues are precisely why I only allow SSH key based
access to a designated "svn" user account: that "svn" account is
designated to repository ownership. It's also why Sourceforge does
much the same thing, with different "users" for different
repositories. We could explore how that's manageable, but it's a
different subject. If Pietro or others are intersted, we could review
it.
Received on 2011-10-30 19:27:06 CET