-----Original Message-----
From: Nico Kadel-Garcia [mailto:nkadel@comcast.net]
Sent: Thursday, April 13, 2006 3:34 PM
To: Timo Wendt; david.anderson@calixo.net
Cc: users@subversion.tigris.org
Subject: Re: SVN Security
----- 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
Does Subversion plus some other OSS packages permit per-item access
control?
I was tasked to configure Subversion on a Debian Testing server with
Apache with Windows XP Pro clients to access the repository with file
level ACLs.
The goal was a single repository with differing user groups only seeing
those files within the repository they have rights to access. It's
desired that users can commit their changes back to the repository.
I'd seen references to LDAP providing 'fine-grained' access control in
Subversion, but don't know how to implement it in a Subversion context.
I'd seen that WANdisco appears to implement that capability -
http://www.wandisco.com/php/benefits_administrators.php
I'd implemented dav_svn_authz style directory access, and tested a
version with file level ACL. I found that doing a 'svn ls ...' from a
Windows command prompt would not list the files the user could see; the
command would request a username & password for the file the user
couldn't see.
- Ed.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Apr 14 16:44:51 2006