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.
> 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?
> 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?
> 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.
> 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.
--
Les Mikesell
lesmikesell_at_gmail.com
Received on 2011-10-30 20:04:44 CET