On Fri, Jul 30, 2010 at 6:50 PM, Stefan Sperling <stsp_at_elego.de> wrote:
> On Fri, Jul 30, 2010 at 05:51:42PM -0400, Nico Kadel-Garcia wrote:
>> It's the integration of LDAP authentication the interferes
>> with restricting the ssh+svn access to strictly ssh+svn, and allows
>> access to the filesystem of the Subversion server via ssh, scp, and
>> possibly sftp.
>
> I see. Well, if you cannot use key-login with that, then you can't restrict
> users by using the 'command' directive in authorized keys files.
> Maybe one could use a custom login shell that only allow execution of
> certain commands, such as svnserve? A bit ugly, but this approach is used
> with e.g. anoncvs on OpenBSD systems: www.openbsd.org/anoncvs.shar
>
> I still object to your claim that this was Subversion's fault
> because "Security infrastructure is not Subversion's strong point."
> That's just FUD.
No, it's harsh experience since version 1.2 (when I started helping
rebuild it and rebundle it for Dag's RPM repository, now RPMfoge). The
UNIX/Linux clients should *never* have been permitted to store
passwords. That's a genuinely unfortunate legacy from its heritage as
the logical upgrade path from CVS, and that was CVS behavior that
should have been jettisoned at the design stage. It's that sort of
misfeature that led to Linus Torvald's infamous presentation comparing
Subversion and git at Google. I wish he'd had enough time to examine
the security ramifications.
I continue, even now, to have to display to people that just because
it's using HTTPS doesn't mean it hasn't stored their passwords in
cleartext, or just because they've switched to ssh+svn it doesn't do
so. This last educational demonstration was one week ago, and I've had
to demonstrate the issue 3 times in the past year. The programmers in
question believed that becuase it used an encrypted protocol, it must
be handling passwords safely. I had to show them where it was storing
their own passwwords in clear text, including one programmer I had to
email his password and email it to his supervisor along with the
company security policy to get him to stop doing it. (He didn't
believe it was *possible* that Subversion sould have been written to
do this.)
If Subversion is to lose its justified reputation as having
unfortunate security, password storage should be permanently deleted
from the code base, not merly papered over with a warning before doing
so. At a minimum, the system and personal configuration defaults
should disable password storage by default, not enable it at all.
> If OpenSSH supported key-based login based on public key credentials
> stored in LDAP, this would not be an issue.
OpenSSH does support public key credentials, quite effectively. It's
the difficulty of using LDAP credentials to allow login as the a
designated subversion repository owner, with restricted access to
svnserver or a similarly restricted access, and not as a shell capable
user with file system acces. SSH authorized_keys supports this: LDAP
authentication makes it extremely difficult, except, perhaps, with a
restricted shell and listing every single potential user in a
centrally managed LDAP system with their shell set to that restricted
shell for the Subversion server itself.
LDAP is normally activated for SSH or HTTPS access to ease management,
not to support a service specific set of add-on configurations. Even
if there were a reliable restricted shell for Subversion or svnserve
access, it would be awkward to manage. Possible, but awkward.
Unfortunately, there is not a restricted shell for Subverson or
svnserve access that I've been able to find. It's certainly not in the
publicly available source code. Do you have one?
Received on 2010-07-31 05:55:57 CEST