On Thu, Oct 14, 2010 at 2:28 PM, Stefan Sperling <stsp_at_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 <nkadel_at_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.
Received on 2010-10-16 04:02:15 CEST