From users-return-5264-daniel=haxx.se@subversion.apache.org Sat Oct 9 15:40:28 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on giant.haxx.se X-Spam-Level: X-Spam-Status: No, score=-1.5 required=3.0 tests=BAYES_00,FREEMAIL_FROM, T_DKIM_INVALID,T_RP_MATCHES_RCVD autolearn=ham version=3.3.1 Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by giant.haxx.se (8.14.3/8.14.3/Debian-9.1) with SMTP id o99DeQiH019031 for ; Sat, 9 Oct 2010 15:40:27 +0200 Received: (qmail 93758 invoked by uid 500); 9 Oct 2010 13:40:17 -0000 Mailing-List: contact users-help@subversion.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list users@subversion.apache.org Received: (qmail 93747 invoked by uid 99); 9 Oct 2010 13:40:16 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 09 Oct 2010 13:40:16 +0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests=FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS Received-SPF: pass (athena.apache.org: domain of nkadel@gmail.com designates 209.85.216.178 as permitted sender) Received: from [209.85.216.178] (HELO mail-qy0-f178.google.com) (209.85.216.178) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 09 Oct 2010 13:40:12 +0000 Received: by qyk4 with SMTP id 4so2108272qyk.16 for ; Sat, 09 Oct 2010 06:39:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=46gjeYPEzY56t5ctvOiiSiqKZVpbyutahaFA8dTjYG8=; b=Swxyf3m//WSMzW5nGuWmzYtLcBPKT7y4EkkLX/OBQ9nn8mE3JO+nNypqVh3gLK3qiR vu+xBZkUTsFs0Hm9P731PrBTXBlIQb+Me82lt5VFuMPhB0jThh61vil/7tdQEBq0HveH vY0AjJsjshax7RIDCaH9JmqCJlCh8kXWC/GbM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=uyD/2GDyS1jhxcPEsxIqmaQS738MSbNTe2BoEzLvZjkQCnGg/zXl1Q15UujI5w2mfX CyOE+OCt4YlyjSfrmpCSePQccA72sz+4rSICMTPzhiOZOiQeCA5GNq0nkvvHefndFXZo L4SITvVhY8PQH2+nWHEwmxhNIR9iumDFgXNB8= MIME-Version: 1.0 Received: by 10.229.217.83 with SMTP id hl19mr3200210qcb.15.1286631589664; Sat, 09 Oct 2010 06:39:49 -0700 (PDT) Received: by 10.220.128.197 with HTTP; Sat, 9 Oct 2010 06:39:49 -0700 (PDT) In-Reply-To: References: <4CAC8E54.3090206@it-sudparis.eu> <4CADF2BB.5010106@it-sudparis.eu> <4CAED202.7090301@it-sudparis.eu> <4CAF3143.8050807@it-sudparis.eu> Date: Sat, 9 Oct 2010 09:39:49 -0400 Message-ID: Subject: Re: svn Farm From: Nico Kadel-Garcia To: Bob Archer Cc: "jehan.procaccia@it-sudparis.eu" , Siva Kumar , "users@subversion.apache.org" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.3.5 (giant.haxx.se [80.67.6.50]); Sat, 09 Oct 2010 15:40:28 +0200 (CEST) X-Friend: Nope On Fri, Oct 8, 2010 at 11:15 AM, Bob Archer 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 Li= nux you need to set up gnome keyring or kde-wallet. > > http://svnbook.red-bean.com/nightly/en/svn-book.html#svn.serverconfig.net= model.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? > =95For other Unix-like operating systems, no standard =93keychain=94 serv= ices 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 =93GNOME Keyring=94 and =93KDE Wallet=94 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/ cac= hing 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 on= ly the user (owner) can read data from it, not the world at large. The oper= ating system's own file permissions protect the passwords from other non-ad= ministrative users on the same system, provided they have no direct physica= l 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 tes= t of perfection. So for those folks willing to sacrifice convenience for th= e ultimate in security, Subversion provides various ways of disabling its c= redentials 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.