On Thu, Oct 14, 2010 at 2:28 PM, Stefan Sperling <s...@elego.de> wrote: > On Thu, Oct 14, 2010 at 10:56:35AM -0700, David Brodbeck wrote: >> On Sat, Oct 9, 2010 at 6:39 AM, Nico Kadel-Garcia <nka...@gmail.com> wrote:
>> > 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 is why running public-facing NFS servers using auth_sys and >> no_root_squash is a BAD idea. If this is happening at your site, you >> have much more serious things to worry about than subversion passwords >> being stolen. For example, in your scenario it would be trivial to >> create an suid-root shell binary, which a local user could then run >> and gain root privileges. > > Exactly. Bad NFS configuration isn't Subversion's fault. > Neither are NFS implementations that have insecure default settings, > like not mapping 'root' to 'nobody' by default. No. system_auth is still the NFS standard for internal use in both academic and professional environments. auth_dh has uses, but it doesn't help against any machine with allocated or cracked local root access. This isn't your "local machine", it's the network wide home directory system, and there are plenty of them out there without even this step. auth_krb5, well, if someone's that sophisticated, they'ld probably fire you or kick you off your network if they found out you were use Subversion with local password storage. no_root_squash is only relevant if you can prevent local root user access on all NFS clients. But walk into any university and most corporate networks with a live CD, and go ahead and do a very slight amount of poking for NFS servers. Not many environments have invested the work to protect against that kind of access. > There are problems with plaintext passwords, no doubt. > But the above scenario description is hyped up and misses the point. > If you cannot trust root on a UNIX box, don't save anything of value > on that box. Conversely, if you can't trust an application or the defaults for a protocol not to store passwords in clear text, don't use it. Or at least never, never, never use system passwords for it. > As of 1.6, Subversion asks the user before saving passwords in > plaintext. 1.6 also added support for using GNOME Keyring and KDE Wallet > as password stores. Which is great. The asking for passwords was a long time coming, and I'm glad to see it. Frankly, I'd prefer to see the default configuraton disable it entirely. I can see storing a mickey mouse password for a Subversion server with mickey mouse security, designed to prevent casual access much like its CVS ancestor. But certainly never under current practices: I'm afraid that too many users believe in the "we have a firewall, we trust the people we work with, we have an IT department to help if we get cracked!" approach to the world. The results are... unfortunate. The keyring support is also good. But until the servers can block the use of the older clients, especially the actively supported 1.4 in RHEL and CentOS 5, which is their most recent release, it's an ongoing problem. SSH agents can work well without having to significantly udpate Subversion, and I am glad it's supported, albeit poorly on the server side. (Key management is an ongoing issue with no good software solutions published.) > It looks like there will be support for using PGP to encrypt passwords soon. > Maybe even in 1.7. Some code for this has already entered the repository: > http://svn.apache.org/viewvc?view=revision&revision=1005036 Hold it: PGP and GPG are different code bases, although they use the same protocol, and this is reliant on gpg-agent to keep the keys unlocked for local use. I like gpg-agent, but let's be careful about it. I'd love to see this deployed, and love to see the protocol updated enough to block the use of the older, less secure clients. But 1.7 has already blown well past its release date of "this summer. If it's not in feature freeze, I'll be pleasantly surprised to see such a feature. And let's be clear: I started ranting about this back in..... 2006? 2005? The changes have been positive, but hardly complete.
