Le 09/10/2010 15:39, Nico Kadel-Garcia a écrit :
> On Fri, Oct 8, 2010 at 11:15 AM, Bob Archer<Bob.Archer_at_amsi.com> wrote:
>
>
>> The client should be able to store the credentials if you have it set up to do so. On windows/mac it is encrypted with OS included libraries. For Linux you need to set up gnome keyring or kde-wallet.
>>
>> http://svnbook.red-bean.com/nightly/en/svn-book.html#svn.serverconfig.netmodel.credcache
>>
> Warning up front: this is a long analysis, and slightly ranting. I'll
> shorten it up to say "this is completely unreliable and misleading
> documentation".
>
>
> Let's quote it, shall we?
>
>
>> •For other Unix-like operating systems, no standard “keychain” services exist.
>>
> This is the fundamental problem, coupled with the default enabled
> storage of passwords and no way to prevent it on the server.
>
>
>> However, the Subversion client knows how to store password securely using the “GNOME Keyring” and “KDE Wallet” services.
>>
> Both of these tools require bulky sets of dependencies not mentioned
> or documented except, these days, in the on-line book. They're not
> installed by default, and using them from a non X session or a remote
> X terminal or Putty is damned akward. There are published widgets to
> aid this, such as the "gkeyring" utility, but they're not standardized
> yet in any UNIX or Linux distribution that I can find. So this claim
> is classic handwaving.
>
>
>> Also, before storing unencrypted passwords in the ~/.subversion/auth/ caching area, the Subversion client will ask the user for permission to do so.
>>
> This feature was only, finally, added in Subversion 1.6. Quite a few
> operating systems don't provide this recent a version: RHEL and
> CentOS, for example, are still stuck at Subversion 1.4. And it can't
> be enforced on the server, it's entirely client side optional
> behavior.
>
>
>> Note that the auth/ caching area is still permission-protected so that only the user (owner) can read data from it, not the world at large. The operating system's own file permissions protect the passwords from other non-administrative users on the same system, provided they have no direct physical access to the storage media of the home directory, or backups thereof.
>>
> And whowever wrote this has no idea what they're talking about. I'm
> going to be crude for a moment: this is complete horseshit.
>
> First, many backup systems are often enabled to allow network based
> recovery. After all, who would be stupid enough to put clear text
> passwords on their backup tapes?
>
> Second, many working environments in the UNIX world rely on NFS based
> home directoies, to share working environments and configurations
> across a variety of machines. In such environments, *any* host that
> can be leveraged to local root access can "su" or "suco" to become the
> target user, and access their entire home directory.
>
> Think I'm kidding? Walk into any university environment: plug in a
> live Linux CD. Run an "nmap" scan for hosts running NFS. Run
> "showmount" to detect what NFS shares are published to everyone. Go
> ahead and mount the shares. Look in them for home directoriies. Look
> in them, using your local root privileges, for Subversion passphrases.
> (Look for CVS passphrases and un-passphrase-protected SSH keys while
> you're at it.)
>
> This requires no internal knowledge of the remote system, and can also
> be done by any rootkitted system on the network. If you happen to
> already know the environment somewhat, just lok into any local system
> and take some notes.
>
> So, "local physical access', my eye. The equivalent to this behavior
> is taping your front door key under your front door mat. After all, if
> they're on you porch, you trust them, right? They must be your
> neighbor if they're on your street! This is how many business and
> educational environments treat their networks: once you're inside the
> perimeter, you're assumed to be trusted and have tremendous access,
> because locking things down further requires time and money and
> inconvencience to the people trying to do their work. So, assuming
> that "local physical access" is required is an extremely ill-founded
> assumption.
>
> Now, allow me to quote the next part:
>
>
>> Of course, for the truly paranoid, none of these mechanisms meets the test of perfection. So for those folks willing to sacrifice convenience for the ultimate in security, Subversion provides various ways of disabling its credentials caching system altogether.
>>
> It's not paranoia when they *are* out to get you. And these days, with
> cracking kiddies wandering the world and people working in large
> shared networks, they are out to get you just as a hobby. And the
> "ways of disabling its credentials caching sysem" are all local client
> configuraton based. They are entirely reliant on owning the local
> installation, and *none* of them are on by default. Very few
> Subversion administrators have such direct control of the client base:
> I've run it for small and large companies and home setups, and *never*
> had that kind of control.
>
> Look, Subversion inherited its practice of storing password in
> cleartext from its ancestor, CVS. It's been an uphill battle ever
> since to wallpaper over the practice: there are enough layers of
> wallpaper, finally, that it's almost thick enough to be a wall. It's
> fixed for TortoieSVN, and svn+ssh using SSH keys can work well. But
> *every single client* I've had in the last... four years has wanted to
> use their Windows passwords, and balked when I showed them this
> problem. Some gave up on password authentication, and simply used
> blank svnserve passwords to enforce the setting of usernames and
> logging of changes. Others went with SSH keys. Some refused to believe
> me, because "it uses HTTPS, they can't be stored in plaintext". (That
> took some extra work to disprove: it was a director of security, who
> couldn't imagine that any commercially supported software could be
> that stupid.)
>
> Look, I'm glad that Subversion finally started asking before storing
> passwords in version 1.6. That was a big step forward over its former
> practice of storing it unannounced, but guess what? Version 1.5 and
> 1.4 are still in use commercially. (Look in RHEL 5 and CentOS 5:
> they're still at Subversion 1.4.) I have had people in the last year,
> as part of new subversion client setups, go ahead and store their
> passwords locally thinking "of course it's stored encrypted, it uses
> HTTPS!!!". And I've shown them their own Windows login passwords and
> therefore email passwords this way, and opened up their email in front
> of them to show the problem.
>
> All that said, I'll call this my "annual rant on the subject", and
> simply post links to it when it comes up again. It does need
> occasional explanation, for newer users unfamiliar with the security
> implications of this local password storage problem.
>
Whaooo , that is a comprehensive analysis, thanks, I must admit that I
didn't consider all these "holes" ....
Back to my original need => provide svn repositories for hundred of
ldap students, without the burden to re-created users, passwords, and
possibly share a central/common authZ file for all repos.
My conclusion to the "rant" above, is that I should consider svn+ssh
beeing the best solution in terms of security, I am right ?.
Also, if I set "store-auth-creds = no " and accept users to re-enter
their password at each svn action, svn + LDAPS URLs method might be a
good security option too !?
One last idea, what about git-svn on the client side, would it be better ?
Thanks .
Received on 2010-10-11 01:37:29 CEST