[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: SVN Security

From: Nico Kadel-Garcia <nkadel_at_comcast.net>
Date: 2006-04-13 21:33:39 CEST

----- Original Message -----
From: "Timo Wendt" <twendt@online.de>
To: <david.anderson@calixo.net>
Cc: <users@subversion.tigris.org>
Sent: Thursday, April 13, 2006 2:34 PM
Subject: Re: SVN Security

>
>> * Timo Wendt <twendt@online.de> [2006-04-13 17:10:35]:
>>
>>> I have evaluated Subversion for the last few days. The features are
>>> really great. My problem with it are the security things in some
>>> areas. There are a lot of nice features when you connect to the
>>> repository remotely. From 1.3.1 you don't even need Apache anymore to
>>> use the features from authz. But to my idea Subversion lacks a lot of
>>> security when it comes to local access to the repository via
>>> file:///. All I can to is hook scripts for commits and such things.
>>> But what if I like no access.
>>
>> Not integrating authz in the file:// access method is a deliberate
>> decision. The reason is simple: if you're accessing the repository
>> through the file RA, you must have permission to read and write all
>> files within the repository (the physical files on your disk I mean -
>> not the ones actually stored within the repository).
>>
>> So, if authz denies you access, there is absolutely nothing stopping
>> you from going in and editing the files manually, or with a modified
>> svn client which ignores authz configurations. Implementing authz in
>> this case would be akin to building a solid titanium door on a house
>> with no walls: nothing stops you walking right round the locks.
>>
>> There is really not much that can be done against this. The file RA
>> method was written because it is a relatively simple RA (no
>> client/server logic involved), and because it provides a very simple
>> solution to users who want to version data in a single-user,
>> single-machine scenario.
>>
>> For more complex scenarios (multiple users, multiple network
>> locations), two server applications have been implemented. These can
>> be configured so that they are the only ones with direct access to the
>> repository storage area, so that they can enforce the security policy
>> given in the configuration.
> I understand what you mean. You are right when you say that users can
> still access the files locally if they have privileges.

> Is there probably a plan for using a real database system like Oracle or
> MySQL? This could probably somehow solve the problem.

A typical database implementation has *absolutely nothing to do* with
security. Seriously: The user authentication is normally so poorly
implemented and so reliant on such vagaries as locally stored cleartext
password files that the only security involved is through obscurity.

Filesystem security is not bad, if it can be configured to separate the
group or user ownership of the files from some other structure, such as the
"apache" user for HTTPS, and the repository is not directly exported to
other machines. (The foolishness of people thinking that NFS exporting files
owned by other users leaves them secure is unfortunate, but far too common.)

> Is there a way of athenticating Apache users against Active Directory
> using Kerberos? Best would be if Authorization would also be possible via
> LDAP in AD. That would be the perfect solution. Another good thing would
> be svnserve to use pam for authentication and also use system groups for
> authotization via authz.

There's certainly LDAP support:

>>> Another thing that bothers me is the auth cache and it even on per
>>> default. Saving clear text passwords on disk is bad. In my case the
>>> file was even world readable even thogh the book states it is only
>>> readable by the owner. I understand that this feature is nice for
>>> usage, but is there no way of shutting it off completely apart from
>>> changing the source code, which I did? As long as this feature is
>>> available, users will use it. Users always find nice ways to make
>>> their work easiest.
>>
>> This is directly addressed in the FAQ on the website:
>>
>> http://subversion.tigris.org/faq.html#plaintext-passwords
> I read this, but I still don't like it. It says that this is no problem
> because if I don't like it then I can disable it through my runtime
> configuration. I think that this is misleading, because the user can
> still decide if he wants to disable it or not. This should not be left up
> to the user. Is is not possible to force this by the repository conf?
> This is something I really like about about svn+ssh.
>>
>> Also, something which the reply does not point out is that we are
>> progressively offering integration with desktop keyring services. I
>> know that we have this on OS X, and it should be possible to
>> contribute patches for other desktops which provide this service, such
>> as Gnome or KDE.
>>
>> Secure storage of passwords is a hard problem if you want to do it
>> right. That's basically the reason we don't implement this
>> ourselves, and let external storage mechanisms do it for us, when it
>> is possible. When it is not possible, we do offer the option to turn
>> off password caching completely, as explained in our FAQ.
>>
>>> Don't misunderstand me, this product is really great, but please also
>>> understand my point of view.
>>
>> I hope I've replied adequately to your concerns. If you have more
>> concerns, I'll be happy to discuss those as well.
> I guess there is no perfect solution for everything that I want. CV
> certainly is not better when it comes to security.
> For me there are still two methods to think about. svn+ssh or https.
>>
>> - Dave.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Apr 13 21:45:37 2006

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.