On Fri, Jul 30, 2010 at 6:50 PM, Stefan Sperling <s...@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?
