[Accidentally sent this just to Les: Les, sorry if you get two copies!]
On Sun, Oct 30, 2011 at 3:04 PM, Les Mikesell <lesmikesell_at_gmail.com> wrote:
> On Sun, Oct 30, 2011 at 1:26 PM, Nico Kadel-Garcia <nkadel_at_gmail.com> wrote:
>>
>> 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.
>
> It's not that it is not subversion's problem, rather that it is every
> application and file's problem on a system, and it is not reasonable
> to include system-level security training into every application's
> initial tutorial.
>
>>> 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.
>
> You misunderstand. It's as much every other application's problem as
> subversion.
No, it's *really* not. The use of HTTP/HTTPS access exposes the
Subversion database to at least read, if not write access, to every
other utility running under the "apache" user. Since many services
tend to be published with equally "not our problem" security models,
they all leave each other exposed.
To turn the problem around, a poorly written "post-commit" script that
does published and synchronized deployed software directories and
which does using "rsync -a --delete workcopy/ /builddir/workcopy/" and
doesn't handle target directories with spaces in the names carefully,
could be triecked with branches with a traliing " " on the end.tricked
into doing "rsync -a --delete workcopy / /builddir/workcopy /". And
chaos would ensue. Sadly, I've seen something very much like this
happen. (And I'm approaching NDA issues, so can't explain the
magnitude of what happendd.) We were lucky we caught it
early, but it was nasty.
>> 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.
>
> By others? Why is having something writable by apache leaving it
> writable by others? Apache has well-tested authentication mechanisms.
> Is it subversion's problem if you don't use them to control access?
When "$HOME/public_html" became a popular way for people to make
http://hostname/~username/ accessible, and many sites enabled PHP
scripting in those directories. Voila! Everything owned by apache is
now writable by anyone with access to their home directory.
Anytime you introduce server-side scripting to a web server, and
especially when you introduce multiple applications on the web server,
you expose them to each other's security issues.
>> 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.
>
> Because it is undeniably true, and until you have accomplished that
> part there is not much sense in wasting additional time on the
> problem. If, for example, you chose or were bribed to corrupt the
> systems you manage, what would stop you?
And it's a great excuse for doing *nothing* about known and ongoing risks.
>> 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.
>
> Sharing resources securely is complicated. You have your choice of
> dedicating hardware (or a VM) to a resource, or hiring a security
> expert to analyze every change on a system that shares them. Which is
> cheaper these days? But it really isn't subversion's problem if you
> choose to allow unrelated logins and services on the same machine and
> let them have write access to some of the same things.
It is Subversion's problem because it is the default supported access.
>> 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.
>
> Can you package this so it is reusable? And document proper
> cross-platform care of the private side of the key (if there is such a
> thing)? If so it would be a great addition to distribution
> packaging.
I've taken a few shots at it, but ran out of resources. I tried to
port the "gitosis" package, but got bogged down, and spent time on RPM
building instead.
Received on 2011-10-30 20:35:56 CET