You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by jehan procaccia <je...@it-sudparis.eu> on 2010/10/06 14:57:24 UTC
svn Farm
hello,
I need to provide svn service to many small groups of students.
I'am looking for a tool that would help industrialize managment of
repositories.
I don't want to issue hundreds of "svn create", "vi authz" , edit ssh
keys for svn+ssh access etc ...
Are there such tools already existing ?
FYI,
- all my users are in a common ldap directory,
- users will use both https and svn+ssh to acces repos
- eventually, it would be great for http if we could benefit from our
http SSO (jasig CAS).
regards .
Re: svn Farm
Posted by jehan procaccia <je...@it-sudparis.eu>.
Le 10/10/2010 22:17, Nico Kadel-Garcia a écrit :
> On Sat, Oct 9, 2010 at 3:05 PM, jehan procaccia<je...@gmail.com> wrote:
>> Le 09/10/2010 20:40, Nico Kadel-Garcia a écrit :
>>> svn+ssh is the most secure, but it conflcts with your desire for LDAP
>>> access. The SSH keys normally live under a single user's account, the
>>> user who owns the repository, who hsould have a locked password. You
>>> see why this conflicts with LDAP based user information and logins?
>>>
>>>
>> No, I don't see why it conflicts ?
>> here's again my scenario,
>> 1) I set and manage all repositories with a unique local unix account (for
>> example username svn !), that account issues all "svn create" and owns the
>> repos filesystem directories
>> 2) enable the server to resolve ldapusers (pam& nss ldap), so that the
>> --tunnel-user=ldapusername option (see 3 below) works.
> Right, all LDAP based. So rar, so good, this can be woven into the
> HTTPS access or, conceivably, into the svnserve based access, although
> I've never seen it done.
No, I don't want to use only HTTPS, if it's served only by HTTPS then i
must use svn + https URLs, then I come into the problem of re-entering
ldap password at each svn command (back to the "rant" of this weekend
;-) ...) .
I want to stick with svn+ssh just because that will allow my clients to
use svn without re-auth at each commands.
As long as their key is in the unique svn manager authorized_key file,
users won't have to enter a password.
I need ldap (nss+pam) on the svn server though, to enable the system to
resolve ldapusername for the
--tunnel-user=ldapusername
option of command "svnserve" , so that authz do resolve username and
hence restrict acces to users allowed to a specific repository .
>> 3) then add ldap users public ssh keys to the ~.ssh/authorized_keys of that
>> unique svn manager account as in :
>> "command="svnserve -t --tunnel-user=ldapusername"ssh_rsa KEYXXXXX...
>> COMMENT"
>> The sysadmin (me ) will have to find a way to push ldapusers public keys to
>> that unique svn manager (script/CGI ...)
> This is an entirely distinct access technology. It contains not a
> single fleck of LDAP in it it, except perhaps to publish the user
> account information for the "svn manager account".
this is svn+ssh, in the svn manager authorized_key file I will have for
each of my ldapusernames a line:
"command="svnserve -t --tunnel-user=ldapusername"ssh_rsa KEYXXXXX...
which will issue a svn process on the server for that specific ldapuser
(owner of the private key pair of that public key) => hence allow authZ
acces to his repo .
>> Anything wrong in that scenario ?
> Wrong, no, just confused. Steps 1 and 2 have nothing to do with step 3
> and can be entirely discarded.
I think you misunderstood my scenario, here step 3 is the following
step 1 & 2 because I choosed svn+ssh !.
regards .
Ps: I'll have to test all these though .... just wanted to be reassured
that the scenario is not foolish ?
Re: svn Farm
Posted by jehan procaccia <je...@it-sudparis.eu>.
Le 10/10/2010 22:17, Nico Kadel-Garcia a écrit :
> On Sat, Oct 9, 2010 at 3:05 PM, jehan procaccia<je...@gmail.com> wrote:
>> Le 09/10/2010 20:40, Nico Kadel-Garcia a écrit :
>>> svn+ssh is the most secure, but it conflcts with your desire for LDAP
>>> access. The SSH keys normally live under a single user's account, the
>>> user who owns the repository, who hsould have a locked password. You
>>> see why this conflicts with LDAP based user information and logins?
>>>
>>>
>> No, I don't see why it conflicts ?
>> here's again my scenario,
>> 1) I set and manage all repositories with a unique local unix account (for
>> example username svn !), that account issues all "svn create" and owns the
>> repos filesystem directories
>> 2) enable the server to resolve ldapusers (pam& nss ldap), so that the
>> --tunnel-user=ldapusername option (see 3 below) works.
> Right, all LDAP based. So rar, so good, this can be woven into the
> HTTPS access or, conceivably, into the svnserve based access, although
> I've never seen it done.
No, I don't want to use only HTTPS, if it's served only by HTTPS then i
must use svn + https URLs, then I come into the problem of re-entering
ldap password at each svn command (back to the "rant" of this weekend
;-) ...) .
I want to stick with svn+ssh just because that will allow my clients to
use svn without re-auth at each commands.
As long as their key is in the unique svn manager authorized_key file,
users won't have to enter a password.
I need ldap (nss+pam) on the svn server though, to enable the system to
resolve ldapusername for the
--tunnel-user=ldapusername
option of command "svnserve" , so that authz do resolve username and
hence restrict acces to users allowed to a specific repository .
>> 3) then add ldap users public ssh keys to the ~.ssh/authorized_keys of that
>> unique svn manager account as in :
>> "command="svnserve -t --tunnel-user=ldapusername"ssh_rsa KEYXXXXX...
>> COMMENT"
>> The sysadmin (me ) will have to find a way to push ldapusers public keys to
>> that unique svn manager (script/CGI ...)
> This is an entirely distinct access technology. It contains not a
> single fleck of LDAP in it it, except perhaps to publish the user
> account information for the "svn manager account".
this is svn+ssh, in the svn manager authorized_key file I will have for
each of my ldapusernames a line:
"command="svnserve -t --tunnel-user=ldapusername"ssh_rsa KEYXXXXX...
which will issue a svn process on the server for that specific ldapuser
(owner of the private key pair of that public key) => hence allow authZ
acces to his repo .
>> Anything wrong in that scenario ?
> Wrong, no, just confused. Steps 1 and 2 have nothing to do with step 3
> and can be entirely discarded.
I think you misunderstood my scenario, here step 3 is the following
step 1 & 2 because I choosed svn+ssh !.
regards .
Ps: I'll have to test all these though .... just wanted to be reassured
that the scenario is not foolish ?
Re: svn Farm
Posted by Nico Kadel-Garcia <nk...@gmail.com>.
On Sat, Oct 9, 2010 at 3:05 PM, jehan procaccia <je...@gmail.com> wrote:
> Le 09/10/2010 20:40, Nico Kadel-Garcia a écrit :
>>
>> svn+ssh is the most secure, but it conflcts with your desire for LDAP
>> access. The SSH keys normally live under a single user's account, the
>> user who owns the repository, who hsould have a locked password. You
>> see why this conflicts with LDAP based user information and logins?
>>
>>
>
> No, I don't see why it conflicts ?
> here's again my scenario,
> 1) I set and manage all repositories with a unique local unix account (for
> example username svn !), that account issues all "svn create" and owns the
> repos filesystem directories
> 2) enable the server to resolve ldapusers (pam & nss ldap), so that the
> --tunnel-user=ldapusername option (see 3 below) works.
Right, all LDAP based. So rar, so good, this can be woven into the
HTTPS access or, conceivably, into the svnserve based access, although
I've never seen it done.
> 3) then add ldap users public ssh keys to the ~.ssh/authorized_keys of that
> unique svn manager account as in :
> "command="svnserve -t --tunnel-user=ldapusername"ssh_rsa KEYXXXXX...
> COMMENT"
> The sysadmin (me ) will have to find a way to push ldapusers public keys to
> that unique svn manager (script/CGI ...)
This is an entirely distinct access technology. It contains not a
single fleck of LDAP in it it, except perhaps to publish the user
account information for the "svn manager account".
> Anything wrong in that scenario ?
Wrong, no, just confused. Steps 1 and 2 have nothing to do with step 3
and can be entirely discarded.
Re: svn Farm
Posted by jehan procaccia <je...@gmail.com>.
Le 09/10/2010 20:40, Nico Kadel-Garcia a écrit :
> svn+ssh is the most secure, but it conflcts with your desire for LDAP
> access. The SSH keys normally live under a single user's account, the
> user who owns the repository, who hsould have a locked password. You
> see why this conflicts with LDAP based user information and logins?
>
>
No, I don't see why it conflicts ?
here's again my scenario,
1) I set and manage all repositories with a unique local unix account
(for example username svn !), that account issues all "svn create" and
owns the repos filesystem directories
2) enable the server to resolve ldapusers (pam & nss ldap), so that the
--tunnel-user=ldapusername option (see 3 below) works.
3) then add ldap users public ssh keys to the ~.ssh/authorized_keys of
that unique svn manager account as in :
"command="svnserve -t --tunnel-user=ldapusername"ssh_rsa KEYXXXXX...
COMMENT"
The sysadmin (me ) will have to find a way to push ldapusers public
keys to that unique svn manager (script/CGI ...)
Anything wrong in that scenario ?
Thanks .
Re: svn Farm
Posted by jehan procaccia <je...@gmail.com>.
Le 09/10/2010 20:40, Nico Kadel-Garcia a écrit :
> svn+ssh is the most secure, but it conflcts with your desire for LDAP
> access. The SSH keys normally live under a single user's account, the
> user who owns the repository, who hsould have a locked password. You
> see why this conflicts with LDAP based user information and logins?
>
>
No, I don't see why it conflicts ?
here's again my scenario,
1) I set and manage all repositories with a unique local unix account
(for example username svn !), that account issues all "svn create" and
owns the repos filesystem directories
2) enable the server to resolve ldapusers (pam & nss ldap), so that the
--tunnel-user=ldapusername option (see 3 below) works.
3) then add ldap users public ssh keys to the ~.ssh/authorized_keys of
that unique svn manager account as in :
"command="svnserve -t --tunnel-user=ldapusername"ssh_rsa KEYXXXXX...
COMMENT"
The sysadmin (me ) will have to find a way to push ldapusers public
keys to that unique svn manager (script/CGI ...)
Anything wrong in that scenario ?
Thanks .
Re: svn Farm
Posted by jehan procaccia <je...@gmail.com>.
Le 09/10/2010 15:39, Nico Kadel-Garcia a écrit :
> On Fri, Oct 8, 2010 at 11:15 AM, Bob Archer<Bo...@amsi.com> 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 Linux you need to set up gnome keyring or kde-wallet.
>>
>> http://svnbook.red-bean.com/nightly/en/svn-book.html#svn.serverconfig.netmodel.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?
>
>
>> •For other Unix-like operating systems, no standard “keychain” services 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 “GNOME Keyring” and “KDE Wallet” 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/ caching 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 only the user (owner) can read data from it, not the world at large. The operating system's own file permissions protect the passwords from other non-administrative users on the same system, provided they have no direct physical 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 test of perfection. So for those folks willing to sacrifice convenience for the ultimate in security, Subversion provides various ways of disabling its credentials 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.
>
Whaooo , that is a comprehensive analysis, thanks, I must admit that I
didn't consider all these "holes" ....
Back to my original need => provide svn repositories for hundred of
ldap students, without the burden to re-created users, passwords, and
possibly share a central/common authZ file for all repos.
My conclusion to the "rant" above, is that I should consider svn+ssh
beeing the best solution in terms of security, I am right ?.
Also, if I set "store-auth-creds = no " and accept users to re-enter
their password at each svn action, svn + LDAPS URLs method might be a
good security option too !?
One last idea, what about git-svn on the client side, would it be better ?
Thanks .
Re: svn Farm
Posted by Stefan Sperling <st...@elego.de>.
On Sun, Oct 17, 2010 at 03:14:09PM +0200, Stefan Sperling wrote:
> The gpg-agent password store will be optional and behave just like
> the gnome-keyring and kwallet stores.
Just FYI, the current implementation of this feature doesn't seem
to be usable: http://svn.haxx.se/dev/archive-2010-10/0286.shtml
Re: svn Farm
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Nico Kadel-Garcia wrote on Sun, Oct 17, 2010 at 08:41:51 -0400:
> On Sun, Oct 17, 2010 at 3:52 AM, Alan Barrett <ap...@cequrux.com> wrote:
> > On Sun, 17 Oct 2010, Nico Kadel-Garcia wrote:
> >> > What he really wants is an alternate-universe Subversion which never
> >> > had the plaintext password storage feature in the first place.
> >>
> >> I'd settle for being able to block that local use on the server side:
> >
> > OK, so you want a feature in which the client reports to the server
> > "here are some important aspects of my configuration", and the server
> > replies "I don't like <this> aspect of your configuration, so I refuse
> > to work with you". I suggest that you write up a proposal for such a
> > feature, or begin a focused discussion about how such a feature could
> > work and could be useful.
>
> I think the gpg-agent support will provide that by forcing people to a
> new authentication protocol. Won't that work?
http://article.gmane.org/gmane.comp.version-control.subversion.devel/121768
Re: svn Farm
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Nico Kadel-Garcia wrote on Sun, Oct 17, 2010 at 08:41:51 -0400:
> On Sun, Oct 17, 2010 at 3:52 AM, Alan Barrett <ap...@cequrux.com> wrote:
> > On Sun, 17 Oct 2010, Nico Kadel-Garcia wrote:
> >> > What he really wants is an alternate-universe Subversion which never
> >> > had the plaintext password storage feature in the first place.
> >>
> >> I'd settle for being able to block that local use on the server side:
> >
> > OK, so you want a feature in which the client reports to the server
> > "here are some important aspects of my configuration", and the server
> > replies "I don't like <this> aspect of your configuration, so I refuse
> > to work with you". I suggest that you write up a proposal for such a
> > feature, or begin a focused discussion about how such a feature could
> > work and could be useful.
>
> I think the gpg-agent support will provide that by forcing people to a
> new authentication protocol. Won't that work?
http://article.gmane.org/gmane.comp.version-control.subversion.devel/121768
Re: svn Farm
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Johan Corveleyn wrote on Tue, Oct 19, 2010 at 11:18:20 +0200:
> Maybe there is already some functionality present for protocol/feature
> negotiation, I don't know ...
All RA layers have a 'capability negotiation' support:
svn_ra_has_capability() allows the client to ask the server what it
supports.
In ra_svn the protocol supports bidirectional capabilities (i.e., it
allows the client to advertise capabilities to the server). I don't
remember offhand if the ra_dav protocol supports that too.
Re: svn Farm
Posted by David Brodbeck <br...@uw.edu>.
On Mon, Oct 18, 2010 at 12:56 AM, Stephen Connolly
<st...@gmail.com> wrote:
> It would be trivial to fork svn to lie and report that it only stored
> passwords encrypted, stick that forked client on my machine and hey
> presto, away I go storing my password in plaintext.
If someone is *that* determined to shoot themselves in the foot, and
willing to go to that much effort to do it, I don't think there's much
you can do. They probably have their password on a sticky note on the
bottom of their keyboard, too. ;)
--
David Brodbeck
System Administrator, Linguistics
University of Washington
Re: svn Farm
Posted by Stephen Connolly <st...@gmail.com>.
On 19 October 2010 10:18, Johan Corveleyn <jc...@gmail.com> wrote:
> On Tue, Oct 19, 2010 at 9:46 AM, Stephen Connolly
> <st...@gmail.com> wrote:
>> Exposing the feature would not in an of itself force the client to use
>> the keyring, but it would allow the server to have a start-commit hook
>> that blocked a commit if the user had plaintext password storage
>> enabled...
>
> Just keep in mind that alerting users with start-commit hook only
> works for users that actually commit of course. You won't reach users
> that merely checkout/update/log/blame/...
true, but that assumes you require authentication to have read access.
we do not require authentication for read, only for write
>
> It might be a better solution to implement this check in a lower
> level, in the ra-protocols (naïvely, e.g. with http(s): client sends
> with every request a header announcing the way it stores its
> password). Of course, you'd like to do this without adding too much
> overhead (handshaking, ... for every tiny request that the client
> makes to the server). Maybe there is already some functionality
> present for protocol/feature negotiation, I don't know ...
>
> Just my 0.02€
>
> Cheers,
> --
> Johan
>
I agree that this would be better!
-Stephen
Re: svn Farm
Posted by Johan Corveleyn <jc...@gmail.com>.
On Tue, Oct 19, 2010 at 9:46 AM, Stephen Connolly
<st...@gmail.com> wrote:
> Exposing the feature would not in an of itself force the client to use
> the keyring, but it would allow the server to have a start-commit hook
> that blocked a commit if the user had plaintext password storage
> enabled...
Just keep in mind that alerting users with start-commit hook only
works for users that actually commit of course. You won't reach users
that merely checkout/update/log/blame/...
It might be a better solution to implement this check in a lower
level, in the ra-protocols (naïvely, e.g. with http(s): client sends
with every request a header announcing the way it stores its
password). Of course, you'd like to do this without adding too much
overhead (handshaking, ... for every tiny request that the client
makes to the server). Maybe there is already some functionality
present for protocol/feature negotiation, I don't know ...
Just my 0.02€
Cheers,
--
Johan
Re: svn Farm
Posted by Stephen Connolly <st...@gmail.com>.
On 19 October 2010 02:17, Nico Kadel-Garcia <nk...@gmail.com> wrote:
> On Mon, Oct 18, 2010 at 3:56 AM, Stephen Connolly
> <st...@gmail.com> wrote:
>
>> Add a capability called "keyringenabled" to Subversion and now Nico
>> will probably be much happier... but of course he doesn't trust his
>> users so he cannot trust that they report "keyringenabled"
>> correctly... but he might be pragmatic enough to accept that as a
>> compromise.
>
> Now, now. Don't put words in my mouth. I'm concerned about obvious and
> possible and documented attack vectorrs: passwords in cleartext are
> one of them. Eventually, any idiot can write a script that stores
> passwords in clear-text to mishandle local passwords or passphrase
> protected keys, but putting the capability in as the default behavior
> is extremely poor practice and should not be supported by default
> configuration or behavior.
>
> I don't think that "keyring enabled" is sufficient. A protocol shift
> that *requires* a better protected password and blocks the currently
> unsecured local password storage access would be interesting, I
> thought the gpg-agent changes would do that, but Stefan pointed out
> the flaws, dang it.
>
the svn client would only report keyringenabled if the keyring was
enabled for password storage and the client was configured to not
store plaintext... perhaps "plaintextpasswordstoragedisabled" is a
better name for the feature.
> svn+ssh actually works reasonably well: it just doesn't suppor the
> "use my normal login password" approach to managing user access.
>
>> and that's probably a feature we could add in 1.6.14 with only minor
>> effort (most of the work being deciding what the feature name should
>> be ;-) )
>>
>> -Stephen
>
> If it could require the client to actually *use* the keyring, I could
> see it. How would we support that for TortoiseSVN clients?
>
Exposing the feature would not in an of itself force the client to use
the keyring, but it would allow the server to have a start-commit hook
that blocked a commit if the user had plaintext password storage
enabled...
so ok, if I have a client with plaintext storage enabled and I attempt
a commit, there is a possibility that my password will get stored in
plaintext on my system, but the start-commit hook can send back the
message saying something like "Your client is storing passwords in
plaintext, which is against the policy for this server. To commit
your changes you need to configure your client to securely store the
password or else use --no-auth-cache on the command line. See
http://internal-wiki-page-link for details."
The wiki page can describe how to remove the plaintext passwords and
how to configure a keyring.
So you would not get completely secure by default, but one could have
the start-commit.tmpl have code to show how to secure the system, and
you would have what you require to ensure the system is secure going
forward.
-Stephen
Re: svn Farm
Posted by Nico Kadel-Garcia <nk...@gmail.com>.
On Mon, Oct 18, 2010 at 3:56 AM, Stephen Connolly
<st...@gmail.com> wrote:
> Add a capability called "keyringenabled" to Subversion and now Nico
> will probably be much happier... but of course he doesn't trust his
> users so he cannot trust that they report "keyringenabled"
> correctly... but he might be pragmatic enough to accept that as a
> compromise.
Now, now. Don't put words in my mouth. I'm concerned about obvious and
possible and documented attack vectorrs: passwords in cleartext are
one of them. Eventually, any idiot can write a script that stores
passwords in clear-text to mishandle local passwords or passphrase
protected keys, but putting the capability in as the default behavior
is extremely poor practice and should not be supported by default
configuration or behavior.
I don't think that "keyring enabled" is sufficient. A protocol shift
that *requires* a better protected password and blocks the currently
unsecured local password storage access would be interesting, I
thought the gpg-agent changes would do that, but Stefan pointed out
the flaws, dang it.
svn+ssh actually works reasonably well: it just doesn't suppor the
"use my normal login password" approach to managing user access.
> and that's probably a feature we could add in 1.6.14 with only minor
> effort (most of the work being deciding what the feature name should
> be ;-) )
>
> -Stephen
If it could require the client to actually *use* the keyring, I could
see it. How would we support that for TortoiseSVN clients?
Re: svn Farm
Posted by Stephen Connolly <st...@gmail.com>.
On 17 October 2010 08:52, Alan Barrett <ap...@cequrux.com> wrote:
> On Sun, 17 Oct 2010, Nico Kadel-Garcia wrote:
>> > What he really wants is an alternate-universe Subversion which never
>> > had the plaintext password storage feature in the first place.
>>
>> I'd settle for being able to block that local use on the server side:
>
> OK, so you want a feature in which the client reports to the server
> "here are some important aspects of my configuration", and the server
> replies "I don't like <this> aspect of your configuration, so I refuse
> to work with you". I suggest that you write up a proposal for such a
> feature, or begin a focused discussion about how such a feature could
> work and could be useful.
>
> --apb (Alan Barrett)
>
The reality is if you don't trust the client, then you don't trust the
client so how can you trust it to report what it supports correctly?
It would be trivial to fork svn to lie and report that it only stored
passwords encrypted, stick that forked client on my machine and hey
presto, away I go storing my password in plaintext.
I think that the best compromise would be for the SVN client to report
its capabilities like the SVN 1.5+ clients do:
You can have a start-commit hook. It can reject commits from clients
that don't have the "mergeinfo" capability.
http://svnbook.red-bean.com/en/1.5/svn.ref.reposhooks.start-commit.html
And that sorts out Nico's requirement for blocking the insecure 1.4
clienst in Redhat EL/CentOS
Add a capability called "keyringenabled" to Subversion and now Nico
will probably be much happier... but of course he doesn't trust his
users so he cannot trust that they report "keyringenabled"
correctly... but he might be pragmatic enough to accept that as a
compromise.
and that's probably a feature we could add in 1.6.14 with only minor
effort (most of the work being deciding what the feature name should
be ;-) )
-Stephen
Re: svn Farm
Posted by Nico Kadel-Garcia <nk...@gmail.com>.
On Sun, Oct 17, 2010 at 3:52 AM, Alan Barrett <ap...@cequrux.com> wrote:
> On Sun, 17 Oct 2010, Nico Kadel-Garcia wrote:
>> > What he really wants is an alternate-universe Subversion which never
>> > had the plaintext password storage feature in the first place.
>>
>> I'd settle for being able to block that local use on the server side:
>
> OK, so you want a feature in which the client reports to the server
> "here are some important aspects of my configuration", and the server
> replies "I don't like <this> aspect of your configuration, so I refuse
> to work with you". I suggest that you write up a proposal for such a
> feature, or begin a focused discussion about how such a feature could
> work and could be useful.
>
> --apb (Alan Barrett)
I think the gpg-agent support will provide that by forcing people to a
new authentication protocol. Won't that work?
Re: svn Farm
Posted by Alan Barrett <ap...@cequrux.com>.
On Sun, 17 Oct 2010, Nico Kadel-Garcia wrote:
> > What he really wants is an alternate-universe Subversion which never
> > had the plaintext password storage feature in the first place.
>
> I'd settle for being able to block that local use on the server side:
OK, so you want a feature in which the client reports to the server
"here are some important aspects of my configuration", and the server
replies "I don't like <this> aspect of your configuration, so I refuse
to work with you". I suggest that you write up a proposal for such a
feature, or begin a focused discussion about how such a feature could
work and could be useful.
--apb (Alan Barrett)
Re: svn Farm
Posted by Stefan Sperling <st...@elego.de>.
On Sun, Oct 17, 2010 at 12:14:12AM -0400, Nico Kadel-Garcia wrote:
> On Sat, Oct 16, 2010 at 10:00 AM, Stefan Sperling <st...@elego.de> wrote:
> > I share Nico's concerns, and when I did (successfully) try to get the
> > behaviour changed, the community was OK with adding a prompt, but not
> > with dropping the feature entirely. Which I would have happily done if
> > people had let me do it. But fair enough, the community's decision is
> > binding, and overrules my own, personal, opinion.
>
> How did "the community" vote?
There was no vote on this matter.
We only vote when consensus cannot be reached.
AFAIK this only happened once or twice in the lifetime of the project.
One vote was about whitespace formatting rules in the code.
> the only one whose "vote" really counts, unless others want to write
> a fork.
All discussion happens on the public dev@ list and everyone is invited
to participate. Of course, opinions of committers tend to carry more weight
than opinions of people who don't have commit access. But that is not because
of random circumstance -- it's because committers have earned the trust of the
community to be in that position. And often enough committers disagree with
each other just like non-committers can disagree with committers.
Some links into the archives regarding the plaintext password discussion:
http://svn.haxx.se/dev/archive-2007-10/0525.shtml
http://svn.haxx.se/dev/archive-2008-04/0685.shtml
http://svn.haxx.se/dev/archive-2008-04/0832.shtml
> > So I don't think Nico will ever get what he wants, no matter how much
> > he'll be ranting about it or be trying to actually contribute towards
> > getting this feature removed.
>
> Would patch files for the config files help to get it enabled by
> default help? I can send them.
I'm not sure I understand what you want to send.
Any submissions are welcome. For huge changes, sparking off a discussion
within the community before doing a lot of work is a good idea, in case
the idea ends up being rejected. And usually the idea gets refined quite
a lot during discussion.
> > And I suppose he won't be happy with GPG support either.
>
> I'd be happy if you'd call it it by its correct name. It's not GPG
> support. It's gpg-agent support, which is a local daemon for providing
> access to unlocked GPG keys. It's a great widget, I've used it, and
> I'd love to see it in the Subversion code base. It would allow admins
> to prevent the use of the existing older releases and enforce an
> upgrade to a more securite technology. Go, Dan Engel for submitting
> it!
The server doesn't care about what the client does with the password,
and the gpg-agent support won't change that.
The gpg-agent password store will be optional and behave just like
the gnome-keyring and kwallet stores.
> > What he really wants is an alternate-universe Subversion which never
> > had the plaintext password storage feature in the first place.
>
> I'd settle for being able to block that local use on the server side:
> that means a structural change.
It will never work reliably because the client can lie about it.
There has been discussion about "repository-dictated configuration" before.
Here's a recent thread: http://svn.haxx.se/dev/archive-2010-08/0166.shtml
Re: svn Farm
Posted by Nico Kadel-Garcia <nk...@gmail.com>.
On Sat, Oct 16, 2010 at 10:00 AM, Stefan Sperling <st...@elego.de> wrote:
> It should be noted that, in our community, contributing towards such
> goals will also require compromise. Which people concerned about security
> are rarely willing to make ("good enough" isn't good enough, it needs to
> be as good and secure as it can possibly be).
Certainly compromises are necessary in life. I've *been* compromising,
I'm helping peoplle get svn+ssh working and publishing notes on
getting it working.
> I share Nico's concerns, and when I did (successfully) try to get the
> behaviour changed, the community was OK with adding a prompt, but not
> with dropping the feature entirely. Which I would have happily done if
> people had let me do it. But fair enough, the community's decision is
> binding, and overrules my own, personal, opinion.
How did "the community" vote? I'm glad to see the query, I really am.
It's a step forward. But the person who owns the central repository is
the only one whose "vote" really counts, unless others want to write
a fork. Who stopped you?
> So I don't think Nico will ever get what he wants, no matter how much
> he'll be ranting about it or be trying to actually contribute towards
> getting this feature removed.
Would patch files for the config files help to get it enabled by
default help? I can send them.
> And I suppose he won't be happy with GPG support either.
I'd be happy if you'd call it it by its correct name. It's not GPG
support. It's gpg-agent support, which is a local daemon for providing
access to unlocked GPG keys. It's a great widget, I've used it, and
I'd love to see it in the Subversion code base. It would allow admins
to prevent the use of the existing older releases and enforce an
upgrade to a more securite technology. Go, Dan Engel for submitting
it!
> What he really wants is an alternate-universe Subversion which never
> had the plaintext password storage feature in the first place.
I'd settle for being able to block that local use on the server side:
that means a structural change. Hopefully, this gpg-agent shift will
provide that. Unfortunately, the 1.7 code base has already blown by
its release date, and RHEL 6 is already in feature freeze. We've
missed the window of opportunity: expect it to be another 4 years
before the next major release and Subversion update for their core
distribution.
I'd still be happy to see it and be delighted to double check and
submit it to RPMforge for updates.
> Precisely. There's no one-size-fits-all solution.
> Well, there is one on Windows and Mac because they have standard password
> stores. But in the Linux/UNIX world there isn't.
>
> Stefan
Re: svn Farm
Posted by Stefan Sperling <st...@elego.de>.
On Sat, Oct 16, 2010 at 10:43:01AM +0200, Erik Huelsmann wrote:
> Hi Nico,
>
> > 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.
>
> I'm affraid "ranting about it" does not really help: it puts
> Subversion in a bad light, but doesn't really solve anything. So,
> instead of just stating what's wrong all the time, it would be nice if
> you started actually contributing toward the goals you think need to
> be achieved.
It should be noted that, in our community, contributing towards such
goals will also require compromise. Which people concerned about security
are rarely willing to make ("good enough" isn't good enough, it needs to
be as good and secure as it can possibly be).
I share Nico's concerns, and when I did (successfully) try to get the
behaviour changed, the community was OK with adding a prompt, but not
with dropping the feature entirely. Which I would have happily done if
people had let me do it. But fair enough, the community's decision is
binding, and overrules my own, personal, opinion.
So I don't think Nico will ever get what he wants, no matter how much
he'll be ranting about it or be trying to actually contribute towards
getting this feature removed.
And I suppose he won't be happy with GPG support either.
What he really wants is an alternate-universe Subversion which never
had the plaintext password storage feature in the first place.
> By the way: there are users (lots) who are actually not at all that
> uncomfortable with the current situation: I'm my own sysadmin with no
> network disks around. There's nothing to be hidden on this system.
> There are many others with situations alike, so plainly removing the
> current support is *no* option for me, unless you offer me a
> password-less alternative which also doesn't introduce additional
> setup requirements.
Precisely. There's no one-size-fits-all solution.
Well, there is one on Windows and Mac because they have standard password
stores. But in the Linux/UNIX world there isn't.
Stefan
Re: svn Farm
Posted by David Brodbeck <br...@uw.edu>.
On Thu, Oct 14, 2010 at 2:22 PM, Stefan Sperling <st...@elego.de> wrote:
> I hope the work-in-progress gpg-agent support I mentioned will fill that gap.
> Would using gpg-agent work for you?
Quite likely. I haven't really played with gpg-agent, but I don't
know of any reason it shouldn't work.
--
David Brodbeck
System Administrator, Linguistics
University of Washington
Re: svn Farm
Posted by Stefan Sperling <st...@elego.de>.
On Thu, Oct 14, 2010 at 01:58:19PM -0700, David Brodbeck wrote:
> On Thu, Oct 14, 2010 at 11:28 AM, Stefan Sperling <st...@elego.de> wrote:
> > 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.
>
> Yup. There are, as noted, unfortunately a lot of hassles involved
> with those tools in a non-GUI environment; what we really need is a
> lightweight, secure, standard keyring service. But getting Linux
> distros to standardize on *anything* is like herding cats, so I'm not
> holding my breath. ;) The assumption seems to be that these are
> things that only desktop users really want, so bundling them as part
> of the GUI is sufficient. I don't blame Subversion for that, though.
I hope the work-in-progress gpg-agent support I mentioned will fill that gap.
Would using gpg-agent work for you?
Stefan
Re: svn Farm
Posted by Nico Kadel-Garcia <nk...@gmail.com>.
On Sat, Oct 16, 2010 at 10:54 AM, Les Mikesell <le...@gmail.com> wrote:
> On 10/16/10 8:53 AM, Nico Kadel-Garcia wrote:
>
>>
>> And I'd like a pony. More seriously, "doesn't introduce additional
>> setup requirements" is an amazingly high bar for real world security.
>> The small vulnerabilities stack up to a far too common, vulnerable set
>> up that exists world wide.
>
> If you are willing to throw additional setup requirements into the mix, why
> not add an encrypted file system to hold your items that need to be secured.
> And use https with required client certificates as your transport.
Well, I was trying to make the point that very modest security efforts
get you big advantages. For example, activating that warning before
storing local passwords was very helpful. Disabling it in the default
config files would be better.
What you mention are interesting approaches, out of the reach of many
users but available. If you've got the resources to do that, fabulous.
For laptops, or Kerberos servers or GPG key repositories, I think
they're great. It does nothing in the still-quite-common NFS home
directory environments, or the "we need to be able to share files!!!"
environments where users do insist on having easy access.
Required SSL certificates is equivalent to SSH keys. Unless you have
some sort of agent to unlock them for dynamic use without constantly
typing a password or unlocking password, their primary advantage is
that they restrict the access from being based on the user's password,
especially their normal account password, and protect that access. And
unless there is some means to generate or recover that SSL certificate
for new hosts or debugging environments that can only access the
Subversion server, I detect some difficlties.
The problem there is that people do tend to want to have
single-sign-on andn account centralization, such as LDAP based account
management and back-end Kerberos management. As soon as you go there,
you block the use of this kind of private certificate based access.
I've actually been looking at Kerberized access to a subversion
management account, in order to support svn+ssh and allow the Kerberos
keys or LDAP to use Kerberos key, not password based access. The
difficulty is in restricting it to non-shell login on a user account,
much as the SSH public key command restrictions normally work. So I'm
looking at the "rssh" tool to help with that, by providing a
restricted shell for that svn+ssh account owner, but having difficulty
unwinding the user name from the connectoin for Subversion logging and
getting a good clean package.
There are lighter weight approaches. Simply publishing the default
configuration files for Subversion to disable password storage by
default, much as it used to be enabled for silent storage by default,
would be a good move: force people to *think* and do something
manually before they store passwords. The failure of the "make they
say yes" approach is borned out by the number of blank or poorly
written passwords accepted by local "passwd" files where it warns you,
but eventually allows you to store a poor or even blank password by
hitting "Enter" enough times. (Went thorugh that again this years:
demonstrated it for an NIS setup that the owner wasn't aware the users
had published blank passwords in.)
Re: svn Farm
Posted by Les Mikesell <le...@gmail.com>.
On 10/16/10 8:53 AM, Nico Kadel-Garcia wrote:
>
> And I'd like a pony. More seriously, "doesn't introduce additional
> setup requirements" is an amazingly high bar for real world security.
> The small vulnerabilities stack up to a far too common, vulnerable set
> up that exists world wide.
If you are willing to throw additional setup requirements into the mix, why not
add an encrypted file system to hold your items that need to be secured. And
use https with required client certificates as your transport.
--
Les Mikesell
lesmikesell@gmail.com
Re: svn Farm
Posted by Nico Kadel-Garcia <nk...@gmail.com>.
On Sat, Oct 16, 2010 at 4:43 AM, Erik Huelsmann <eh...@gmail.com> wrote:
> Hi Nico,
>
>> 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.
>
> I'm affraid "ranting about it" does not really help: it puts
> Subversion in a bad light, but doesn't really solve anything. So,
> instead of just stating what's wrong all the time, it would be nice if
> you started actually contributing toward the goals you think need to
> be achieved.
I do. Both by explaining the real risks, and pointing out the tools
that do work. (svn+ssh, and keeping your passwords for Subversion
separate from your system passwords.)
> By the way: there are users (lots) who are actually not at all that
> uncomfortable with the current situation: I'm my own sysadmin with no
> network disks around. There's nothing to be hidden on this system.
> There are many others with situations alike, so plainly removing the
> current support is *no* option for me, unless you offer me a
> password-less alternative which also doesn't introduce additional
> setup requirements.
And I'd like a pony. More seriously, "doesn't introduce additional
setup requirements" is an amazingly high bar for real world security.
The small vulnerabilities stack up to a far too common, vulnerable set
up that exists world wide.
More seriously,
Re: svn Farm
Posted by Erik Huelsmann <eh...@gmail.com>.
Hi Nico,
> 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.
I'm affraid "ranting about it" does not really help: it puts
Subversion in a bad light, but doesn't really solve anything. So,
instead of just stating what's wrong all the time, it would be nice if
you started actually contributing toward the goals you think need to
be achieved.
By the way: there are users (lots) who are actually not at all that
uncomfortable with the current situation: I'm my own sysadmin with no
network disks around. There's nothing to be hidden on this system.
There are many others with situations alike, so plainly removing the
current support is *no* option for me, unless you offer me a
password-less alternative which also doesn't introduce additional
setup requirements.
Bye,
Erik.
Re: svn Farm
Posted by David Brodbeck <br...@uw.edu>.
On Wed, Oct 20, 2010 at 4:30 PM, David Brodbeck <br...@uw.edu> wrote:
> If I have root access to the filesystem, it doesn't matter what SSH
> does to try to encrypt the password...
Typo. s/SSH/SVN/
--
David Brodbeck
System Administrator, Linguistics
University of Washington
Re: svn Farm
Posted by David Brodbeck <br...@uw.edu>.
On Fri, Oct 15, 2010 at 7:01 PM, Nico Kadel-Garcia <nk...@gmail.com> wrote:
> 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.
I don't doubt that, but my point is in this particular scenario there
are far bigger issues that render anything SVN does entirely moot.
If I have root access to the filesystem, it doesn't matter what SSH
does to try to encrypt the password, because I have full access to
your account. I can just change your PATH to point to my trojaned SVN
binary and grab your password that way, for example. There simply
isn't any level of precaution sufficient to protect you from a rogue
root user on a UNIX system.
I'm not saying there aren't situations where it's a good idea to have
SVN encrypt passwords, just that this isn't a very good example of
one. If people can boot a LiveCD and get root access to your NFS
shares, they already have the keys to the castle.
--
David Brodbeck
System Administrator, Linguistics
University of Washington
Re: svn Farm
Posted by Nico Kadel-Garcia <nk...@gmail.com>.
On Thu, Oct 14, 2010 at 2:28 PM, Stefan Sperling <st...@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 <nk...@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.
Re: svn Farm
Posted by Mark Phippard <ma...@gmail.com>.
On Thu, Oct 14, 2010 at 4:58 PM, David Brodbeck <br...@uw.edu> wrote:
> On Thu, Oct 14, 2010 at 11:28 AM, Stefan Sperling <st...@elego.de> wrote:
>> 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.
>
> Yup. There are, as noted, unfortunately a lot of hassles involved
> with those tools in a non-GUI environment; what we really need is a
> lightweight, secure, standard keyring service. But getting Linux
> distros to standardize on *anything* is like herding cats, so I'm not
> holding my breath. ;) The assumption seems to be that these are
> things that only desktop users really want, so bundling them as part
> of the GUI is sufficient. I don't blame Subversion for that, though.
GNOME keyring can work well in a non-GUI environment. I use it in an
environment where I just SSH into a remote Linux server without any X
environment. I just start gnome-keyring-daemon when I login. Not
sure if KWallet has an equivalent.
This even works with the ancient gnome-keyring libraries included in
RHEL 4. I've also used it on Solaris.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Re: svn Farm
Posted by David Brodbeck <br...@uw.edu>.
On Thu, Oct 14, 2010 at 11:28 AM, Stefan Sperling <st...@elego.de> wrote:
> 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.
Yup. There are, as noted, unfortunately a lot of hassles involved
with those tools in a non-GUI environment; what we really need is a
lightweight, secure, standard keyring service. But getting Linux
distros to standardize on *anything* is like herding cats, so I'm not
holding my breath. ;) The assumption seems to be that these are
things that only desktop users really want, so bundling them as part
of the GUI is sufficient. I don't blame Subversion for that, though.
--
David Brodbeck
System Administrator, Linguistics
University of Washington
Re: svn Farm
Posted by Stefan Sperling <st...@elego.de>.
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 <nk...@gmail.com> wrote:
> > 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 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.
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.
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.
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
Stefan
Re: svn Farm
Posted by David Brodbeck <br...@uw.edu>.
On Sat, Oct 9, 2010 at 6:39 AM, Nico Kadel-Garcia <nk...@gmail.com> wrote:
> 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 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.
--
David Brodbeck
System Administrator, Linguistics
University of Washington
Re: svn Farm
Posted by Nico Kadel-Garcia <nk...@gmail.com>.
I did just misspell "sudo" and tell the same story twice about opening
up people's email with their stored passwords, didn't I?
Remind me to re-edit *twice* before sending a rant.....
Re: svn Farm
Posted by jehan procaccia <je...@gmail.com>.
Le 09/10/2010 15:39, Nico Kadel-Garcia a écrit :
> On Fri, Oct 8, 2010 at 11:15 AM, Bob Archer<Bo...@amsi.com> 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 Linux you need to set up gnome keyring or kde-wallet.
>>
>> http://svnbook.red-bean.com/nightly/en/svn-book.html#svn.serverconfig.netmodel.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?
>
>
>> •For other Unix-like operating systems, no standard “keychain” services 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 “GNOME Keyring” and “KDE Wallet” 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/ caching 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 only the user (owner) can read data from it, not the world at large. The operating system's own file permissions protect the passwords from other non-administrative users on the same system, provided they have no direct physical 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 test of perfection. So for those folks willing to sacrifice convenience for the ultimate in security, Subversion provides various ways of disabling its credentials 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.
>
Whaooo , that is a comprehensive analysis, thanks, I must admit that I
didn't consider all these "holes" ....
Back to my original need => provide svn repositories for hundred of
ldap students, without the burden to re-created users, passwords, and
possibly share a central/common authZ file for all repos.
My conclusion to the "rant" above, is that I should consider svn+ssh
beeing the best solution in terms of security, I am right ?.
Also, if I set "store-auth-creds = no " and accept users to re-enter
their password at each svn action, svn + LDAPS URLs method might be a
good security option too !?
One last idea, what about git-svn on the client side, would it be better ?
Thanks .
Re: svn Farm
Posted by Nico Kadel-Garcia <nk...@gmail.com>.
On Sun, Oct 10, 2010 at 4:26 PM, Les Mikesell <le...@gmail.com> wrote:
> On 10/10/10 3:12 PM, Nico Kadel-Garcia wrote:
>>> If they didn't, it would be impossible to do automated commands. There
>>> are
>>> times when you have to choose between trusting the OS to protect your
>>> files
>>> (which is, after all, one of its jobs) or not being able to do what you
>>> want.
>>
>> This is incorrect. There are at least 5 tools in common use to support
>> unlocking SSH keys and making them available for other programs to
>> use, all based on the "ssh-agent" built-in technology of all vaguely
>> complete SSH software packages. The include:
>>
>> * Pageant, built into the Putty installer, for Windows users.
>> * gnome-keyring, already mentioned in this thread and aimed at X
>> sessions, possible to use for command line sessions with considerable
>> work.
>> * kde-wallet, similar to gnome-keyring
>> * keychain, a popular and lightweight Perl script for just this use.
>> * Typing "eval ssh-agent" and "ssh-add [name of your SSH private key"
>> from the command line in the window or session you will run Subversion
>> from.
>
> All of which require user interaction at some point. What if the machine
> reboots? And what do you do about other files with contents that need to be
> protected? Your ssh key probably isn't the only thing you'd like to keep
> private.
[ We've drifted like crazy from the original subject: if this is
getting boring or confusing, let me know. ]
Well, yes. Your keys are *supposed* to be unavailable until
re-authenticated if your system reboots, and it's in conflict with the
idea that "it should work unattended no matter what" that you've just
described. But then, so is having a password at all: we find ways to
work around it, such as a notification email that a machine has
rebooted and your keys are no longer available for your cron job
automated Subversion updates tag building.
There are key systems that don't normally require re-authentication,
such as SSH host keys webserver SSL keys that are owned locally and
owned by root. But it's not a practice used for secure web sites or
critical systems such as Kerberos servers, and I've certainly done so
with web servers that handled critical data, especially money and
medical data.
Also note that the system that holds the SSH keys, and unlocks them
with a passphrase, need not be the system doing the checking out. That
key holding can forward its SSH agents to connect to another host and
do its work: for example, my Windows client can use Pageant and Putty
to connect to a Linux server and do Subversion work with only my local
client unlocking the keys. That keeps my SSH keys somewhere even
safer: on my USB key, along with my svnsync m anaged copy of critical
source code.
If you're granting access that has to be available unattended, you've
entered a problematic security environment. It's why you *absolutely
should not* provide normal shell access with such an unattended key
access, and you should use different keys for svn+ssh than you do for
normal logins. It helps prevent people who are careless with their
Subversion keys from imperiling their normal login access.
Re: svn Farm
Posted by Les Mikesell <le...@gmail.com>.
On 10/10/10 3:12 PM, Nico Kadel-Garcia wrote:
> On Sat, Oct 9, 2010 at 2:05 PM, Les Mikesell<le...@gmail.com> wrote:
>> On 10/9/10 12:51 PM, Nico Kadel-Garcia wrote:
>
>>> Yeah, both Subversion and SSH share the flaw of *ALLOWING* such
>>> unprotected keys to be stored locally, with no special command line
>>> arguments or special settings, and impossible to compile out of the
>>> clients with the current source trees.
>>
>> If they didn't, it would be impossible to do automated commands. There are
>> times when you have to choose between trusting the OS to protect your files
>> (which is, after all, one of its jobs) or not being able to do what you
>> want.
>
> This is incorrect. There are at least 5 tools in common use to support
> unlocking SSH keys and making them available for other programs to
> use, all based on the "ssh-agent" built-in technology of all vaguely
> complete SSH software packages. The include:
>
> * Pageant, built into the Putty installer, for Windows users.
> * gnome-keyring, already mentioned in this thread and aimed at X
> sessions, possible to use for command line sessions with considerable
> work.
> * kde-wallet, similar to gnome-keyring
> * keychain, a popular and lightweight Perl script for just this use.
> * Typing "eval ssh-agent" and "ssh-add [name of your SSH private key"
> from the command line in the window or session you will run Subversion
> from.
All of which require user interaction at some point. What if the machine
reboots? And what do you do about other files with contents that need to be
protected? Your ssh key probably isn't the only thing you'd like to keep private.
--
Les Mikesell
lesmikesell@gmail.com
Re: svn Farm
Posted by Nico Kadel-Garcia <nk...@gmail.com>.
On Sat, Oct 9, 2010 at 2:05 PM, Les Mikesell <le...@gmail.com> wrote:
> On 10/9/10 12:51 PM, Nico Kadel-Garcia wrote:
>> Yeah, both Subversion and SSH share the flaw of *ALLOWING* such
>> unprotected keys to be stored locally, with no special command line
>> arguments or special settings, and impossible to compile out of the
>> clients with the current source trees.
>
> If they didn't, it would be impossible to do automated commands. There are
> times when you have to choose between trusting the OS to protect your files
> (which is, after all, one of its jobs) or not being able to do what you
> want.
This is incorrect. There are at least 5 tools in common use to support
unlocking SSH keys and making them available for other programs to
use, all based on the "ssh-agent" built-in technology of all vaguely
complete SSH software packages. The include:
* Pageant, built into the Putty installer, for Windows users.
* gnome-keyring, already mentioned in this thread and aimed at X
sessions, possible to use for command line sessions with considerable
work.
* kde-wallet, similar to gnome-keyring
* keychain, a popular and lightweight Perl script for just this use.
* Typing "eval ssh-agent" and "ssh-add [name of your SSH private key"
from the command line in the window or session you will run Subversion
from.
It's a pain in the backside, but it's fairly common practice. It
wouldn't be so necessary if Subversion didn't rely on central
repository access for committing any changes. but that's pretty core
to the way CVS and and now Subversion work, and I don't see that going
away.
Re: svn Farm
Posted by Les Mikesell <le...@gmail.com>.
On 10/9/10 12:51 PM, Nico Kadel-Garcia wrote:
> On Sat, Oct 9, 2010 at 11:06 AM, Les Mikesell<le...@gmail.com> wrote:
>> On 10/9/10 8:39 AM, Nico Kadel-Garcia wrote:
>>>
>>> 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.
>>
>> If you are going to rant, you should also point out that ssh keys without a
>> passphrase and agent to manage it are not really any different than a
>> file-stored password. If you can copy the private side of the identity key,
>> you can get access.
>
> Yeah, both Subversion and SSH share the flaw of *ALLOWING* such
> unprotected keys to be stored locally, with no special command line
> arguments or special settings, and impossible to compile out of the
> clients with the current source trees.
If they didn't, it would be impossible to do automated commands. There are
times when you have to choose between trusting the OS to protect your files
(which is, after all, one of its jobs) or not being able to do what you want.
--
Les Mikesell
lesmikesell@gmail.com
Re: svn Farm
Posted by Nico Kadel-Garcia <nk...@gmail.com>.
On Sat, Oct 9, 2010 at 11:06 AM, Les Mikesell <le...@gmail.com> wrote:
> On 10/9/10 8:39 AM, Nico Kadel-Garcia wrote:
>>
>> 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.
>
> If you are going to rant, you should also point out that ssh keys without a
> passphrase and agent to manage it are not really any different than a
> file-stored password. If you can copy the private side of the identity key,
> you can get access.
Yeah, both Subversion and SSH share the flaw of *ALLOWING* such
unprotected keys to be stored locally, with no special command line
arguments or special settings, and impossible to compile out of the
clients with the current source trees. I've raised concerns about that
since way, way back with ssh-1.21 and the early releases of ssh-2.0.
This is why, ideally, the SSH keys for Subversion should be distinct
from normal user login keys, but that can be very difficult to enforce
as well.
Re: svn Farm
Posted by Les Mikesell <le...@gmail.com>.
On 10/9/10 8:39 AM, Nico Kadel-Garcia wrote:
>
> 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.
If you are going to rant, you should also point out that ssh keys without a
passphrase and agent to manage it are not really any different than a
file-stored password. If you can copy the private side of the identity key, you
can get access.
--
Les Mikesell
lesmikesell@gmail.com
Re: svn Farm
Posted by Nico Kadel-Garcia <nk...@gmail.com>.
On Fri, Oct 8, 2010 at 11:15 AM, Bob Archer <Bo...@amsi.com> 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 Linux you need to set up gnome keyring or kde-wallet.
>
> http://svnbook.red-bean.com/nightly/en/svn-book.html#svn.serverconfig.netmodel.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?
> •For other Unix-like operating systems, no standard “keychain” services 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 “GNOME Keyring” and “KDE Wallet” 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/ caching 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 only the user (owner) can read data from it, not the world at large. The operating system's own file permissions protect the passwords from other non-administrative users on the same system, provided they have no direct physical 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 test of perfection. So for those folks willing to sacrifice convenience for the ultimate in security, Subversion provides various ways of disabling its credentials 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.
RE: svn Farm
Posted by Bob Archer <Bo...@amsi.com>.
> Le 08/10/2010 15:59, Bob Archer a écrit :
> >> Now, is collabnet solution able to serve tradition unix shell
> >> comand
> >> line clients ? is there a svnserve server behind it or is apache
> >> able to
> >> serve those clients using svn protocol too ?
> > BTW: If you have http(s) access you don't also need svn protocol.
> The svn command line client supports http(s) just fine.
> >
> > BOb
> Damn it ! I didn't realized it was possible ... I though svn
> command
> line tool could only talk to svnserve (svn or svn+ssh URLs) .
> Indeed, svn + ldaps URL might simplify my project .
> However, I already see a usage diffulty, any time I issue a svn
> command
> line, I'am asked to enter my password (apache authN !) , is there a
> workaround to that authN password call ?
> with svn+ssh I could push ssh public keys once for all .
>
> thanks .
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 Linux you need to set up gnome keyring or kde-wallet.
http://svnbook.red-bean.com/nightly/en/svn-book.html#svn.serverconfig.netmodel.credcache
BOb
Re: svn Farm
Posted by jehan procaccia <je...@it-sudparis.eu>.
Le 08/10/2010 15:59, Bob Archer a écrit :
>> Now, is collabnet solution able to serve tradition unix shell
>> comand
>> line clients ? is there a svnserve server behind it or is apache
>> able to
>> serve those clients using svn protocol too ?
> BTW: If you have http(s) access you don't also need svn protocol. The svn command line client supports http(s) just fine.
>
> BOb
Damn it ! I didn't realized it was possible ... I though svn command
line tool could only talk to svnserve (svn or svn+ssh URLs) .
Indeed, svn + ldaps URL might simplify my project .
However, I already see a usage diffulty, any time I issue a svn command
line, I'am asked to enter my password (apache authN !) , is there a
workaround to that authN password call ?
with svn+ssh I could push ssh public keys once for all .
thanks .
Re: svn Farm
Posted by jehan procaccia <je...@it-sudparis.eu>.
Le 08/10/2010 15:59, Bob Archer a écrit :
>> Now, is collabnet solution able to serve tradition unix shell
>> comand
>> line clients ? is there a svnserve server behind it or is apache
>> able to
>> serve those clients using svn protocol too ?
> BTW: If you have http(s) access you don't also need svn protocol. The svn command line client supports http(s) just fine.
>
> BOb
Damn it ! I didn't realized it was possible ... I though svn command
line tool could only talk to svnserve (svn or svn+ssh URLs) .
Indeed, svn + ldaps URL might simplify my project .
However, I already see a usage diffulty, any time I issue a svn command
line, I'am asked to enter my password (apache authN !) , is there a
workaround to that authN password call ?
with svn+ssh I could push ssh public keys once for all .
thanks .
RE: svn Farm
Posted by Bob Archer <Bo...@amsi.com>.
> Now, is collabnet solution able to serve tradition unix shell
> comand
> line clients ? is there a svnserve server behind it or is apache
> able to
> serve those clients using svn protocol too ?
BTW: If you have http(s) access you don't also need svn protocol. The svn command line client supports http(s) just fine.
BOb
Re: svn Farm
Posted by jehan procaccia <je...@it-sudparis.eu>.
Le 08/10/2010 14:54, Andy Levy a écrit :
> On Fri, Oct 8, 2010 at 08:09, Nico Kadel-Garcia<nk...@gmail.com> wrote:
>> Also note: both the 'svn' and 'http' access send the passwords ovder
>> the network in clear text. There are ways around this (such as SSH or
>> SSL tunneling), but they're pesky to set up. Fortunately, "https"
>> already has that built in.
> HTTP Digest Authentication does not send the password in cleartext, it
> sends an MD5 hash. Yes, the hash is sent in cleartext, but that is not
> exactly the same as sending the *password* in cleartext.
>
> If you configure your svnserve to use SASL, it can use several methods
> of encryption for authentication.
> http://svnbook.red-bean.com/en/1.5/svn.serverconfig.svnserve.html#svn.serverconfig.svnserve.sasl
>
> I understand that you're very concerned with security shortcomings,
> but you're leaving out important details that may make the system
> appear less secure than it really can be with proper configuration.
After all, I think I might consider svn+ssh for large scale svn unix
command line acces.
here's the scenario,
1) I set and manage all repositories with a unique local unix account
(for example username svn !), that account issues all "svn create" and
owns the repos filesystem directories
2) enable the server to resolve ldapusers (pam & nss ldap), so that the
--tunnel-user=ldapusername option (see 3 below) works.
3) then add ldap users public ssh keys to the authorized_keys of that
unique svn manager account as in :
"command="svnserve -t --tunnel-user=ldapusername"ssh_rsa KEYXXXXX COMMENT"
4) write a script / web GUI that enable users to push their key in the
~svn/.ssh/authorized_key
5) copy a centraly managed authz file in every repos/conf/authz file,
if I understand well svnserve there's no such AuthzSVNAccessFile central
authz directive as in apache DAV svn !?
Does this scenario make sense ?
I agree step 4 will take some time ...
thanks for you remarks .
Re: svn Farm
Posted by jehan procaccia <je...@it-sudparis.eu>.
Le 08/10/2010 14:54, Andy Levy a écrit :
> On Fri, Oct 8, 2010 at 08:09, Nico Kadel-Garcia<nk...@gmail.com> wrote:
>> Also note: both the 'svn' and 'http' access send the passwords ovder
>> the network in clear text. There are ways around this (such as SSH or
>> SSL tunneling), but they're pesky to set up. Fortunately, "https"
>> already has that built in.
> HTTP Digest Authentication does not send the password in cleartext, it
> sends an MD5 hash. Yes, the hash is sent in cleartext, but that is not
> exactly the same as sending the *password* in cleartext.
>
> If you configure your svnserve to use SASL, it can use several methods
> of encryption for authentication.
> http://svnbook.red-bean.com/en/1.5/svn.serverconfig.svnserve.html#svn.serverconfig.svnserve.sasl
>
> I understand that you're very concerned with security shortcomings,
> but you're leaving out important details that may make the system
> appear less secure than it really can be with proper configuration.
After all, I think I might consider svn+ssh for large scale svn unix
command line acces.
here's the scenario,
1) I set and manage all repositories with a unique local unix account
(for example username svn !), that account issues all "svn create" and
owns the repos filesystem directories
2) enable the server to resolve ldapusers (pam & nss ldap), so that the
--tunnel-user=ldapusername option (see 3 below) works.
3) then add ldap users public ssh keys to the authorized_keys of that
unique svn manager account as in :
"command="svnserve -t --tunnel-user=ldapusername"ssh_rsa KEYXXXXX COMMENT"
4) write a script / web GUI that enable users to push their key in the
~svn/.ssh/authorized_key
5) copy a centraly managed authz file in every repos/conf/authz file,
if I understand well svnserve there's no such AuthzSVNAccessFile central
authz directive as in apache DAV svn !?
Does this scenario make sense ?
I agree step 4 will take some time ...
thanks for you remarks .
Re: svn Farm
Posted by Andy Levy <an...@gmail.com>.
On Fri, Oct 8, 2010 at 08:09, Nico Kadel-Garcia <nk...@gmail.com> wrote:
> Also note: both the 'svn' and 'http' access send the passwords ovder
> the network in clear text. There are ways around this (such as SSH or
> SSL tunneling), but they're pesky to set up. Fortunately, "https"
> already has that built in.
HTTP Digest Authentication does not send the password in cleartext, it
sends an MD5 hash. Yes, the hash is sent in cleartext, but that is not
exactly the same as sending the *password* in cleartext.
If you configure your svnserve to use SASL, it can use several methods
of encryption for authentication.
http://svnbook.red-bean.com/en/1.5/svn.serverconfig.svnserve.html#svn.serverconfig.svnserve.sasl
I understand that you're very concerned with security shortcomings,
but you're leaving out important details that may make the system
appear less secure than it really can be with proper configuration.
Re: svn Farm
Posted by Johan Corveleyn <jc...@gmail.com>.
On Fri, Oct 8, 2010 at 2:09 PM, Nico Kadel-Garcia <nk...@gmail.com> wrote:
> On Fri, Oct 8, 2010 at 4:10 AM, jehan procaccia
> <je...@it-sudparis.eu> wrote:
>> Le 08/10/2010 02:19, Nico Kadel-Garcia a écrit :
>>> Unless you can guarantee that they will not use Linux or UNIX based
>>> clients, don't even consider this. The problem is that the Linux and
>>> UNIX clients, by default, continue to store passwords in clear text.
>>> They whinge about it now before storing it, but it's still an issue.
>>>
>>> Is there any reason you use 'svn' access, rather than HTTPS? The
>>> mod_dav_svn module works well, even though I detest the clear text
>>> password problem.
>>
>> I need my users to be able to work with svn repos both from unix shell
>> command "svn" or through GUI clients (web browser, eclipse, tortoise ...)
>> For web (http) acces, it looks good now, indeed if I set ldap users login
>> name in the global authZ (file edit from the admin collabnet
>> .../editAuthorization) it works fine .
>
> That's great if that's what you need. There is no way, though, to
> prevent your UNIX/Linux command line clients from storing their
> passwords in cleartext. This isn't a server problem. It's a command
> line client problem.
Hi Nico,
Slightly OT for this thread, but it may interest you to know that very
recently some initiatives were started to include gpg-agent support in
svn (just two days ago a feature branch was created to work on that
functionality). I don't know any details about it myself (just read
the posts on the dev list), but maybe that's the sort of improvement
that would help to solve the cached-passwords-in-cleartext problem for
UNIX/Linux?
See these recent threads from the dev-list:
- http://svn.haxx.se/dev/archive-2010-10/0099.shtml
- http://svn.haxx.se/dev/archive-2010-10/0149.shtml
Cheers,
--
Johan
Re: svn Farm
Posted by Nico Kadel-Garcia <nk...@gmail.com>.
On Fri, Oct 8, 2010 at 4:10 AM, jehan procaccia
<je...@it-sudparis.eu> wrote:
> Le 08/10/2010 02:19, Nico Kadel-Garcia a écrit :
>>
>> On Thu, Oct 7, 2010 at 12:18 PM, jehan procaccia
>> <je...@it-sudparis.eu> wrote:
>>>
>>> Le 06/10/2010 17:06, Siva Kumar a écrit :
>>>>>
>>>>> I need to provide svn service to many small groups of students.
>>>>> I'am looking for a tool that would help industrialize managment of
>>>>> repositories.
>>>>> I don't want to issue hundreds of "svn create", "vi authz" , edit ssh
>>>>> keys
>>>>> for svn+ssh access etc ...
>>>>> Are there such tools already existing ?
>>>>
>>>> Subversion Edge(http://www.open.collab.net/go/csvne2_r2a/) might fit
>>>> your
>>>> bill.
>>>
>>> good point !
>>> I've installed and run it, looks good.
>>> but now I need to find a way to link my ldap users to svn roles/authz , I
>>> still can't find how to do that wihout creating csvn local accounts for
>>> all
>>> my users :-( ... !?
>>
>> Unless you can guarantee that they will not use Linux or UNIX based
>> clients, don't even consider this. The problem is that the Linux and
>> UNIX clients, by default, continue to store passwords in clear text.
>> They whinge about it now before storing it, but it's still an issue.
>>
>> Is there any reason you use 'svn' access, rather than HTTPS? The
>> mod_dav_svn module works well, even though I detest the clear text
>> password problem.
>
> I need my users to be able to work with svn repos both from unix shell
> command "svn" or through GUI clients (web browser, eclipse, tortoise ...)
> For web (http) acces, it looks good now, indeed if I set ldap users login
> name in the global authZ (file edit from the admin collabnet
> .../editAuthorization) it works fine .
That's great if that's what you need. There is no way, though, to
prevent your UNIX/Linux command line clients from storing their
passwords in cleartext. This isn't a server problem. It's a command
line client problem.
> Now, is collabnet solution able to serve tradition unix shell comand line
> clients ? is there a svnserve server behind it or is apache able to serve
> those clients using svn protocol too ?
Subversion over HTTP is handled with the "WebDAV" protocol. I'm sure
that svnserve protocl, run from the CollabNet packate, is using the
svnserve package built into the Subversion source code. (Maybe with a
few tweaks.) I've not personally taken it apart, so I don't know
whether it uses its own webserver or plugs modules into Apache to run
the commonly used https access.
Also note: both the 'svn' and 'http' access send the passwords ovder
the network in clear text. There are ways around this (such as SSH or
SSL tunneling), but they're pesky to set up. Fortunately, "https"
already has that built in. And svn+ssh not only has the tunneling, it
correctly forces the clients to use SSH keys, instead of passwords
that might be stored unlocked by the UNIX or Linux clients.
>> There remains no good GUI or published toolkit for svn+ssh access
>> configuration. This is one of Subversion's profound deficits, combined
>> with the password issues with the Linux/UNIX clients. Various
>> companies and groups have internal kits, including Sourceforge, but
>> I've never seen their tools published.
>
> Too bad indeed that there is no toolkit for svn+ssh :-(
I agree. If anyone finds or writes one, I'd love to see it. I'm not
good at writing gui's from scratch, or I'd try to port one of the git
toolkits over to Subversion for just this purpose.
> Can I start aside collabnet (great and easy HTTP interface) a svnserve
> serving the same repostories ?
I've not tried it. You, or it, will have to be careful to set
ownership of the repository to grant access to both the "apache" user
for a normal webserver, if it's using the built-in Apache, or tun the
Apache daemon and the svn daemon as the same user to assure consistent
and controlled write access to the repository.
> If my unix collabnet server does know and authenticate my ldap users (with
> pam_ldap, nss etc ...)
> wouldn't they be able to connect to svnserve with their ldap password !?
svnserve !=- Apache. They're serving different protocols, with
different daemons. I've not personally tried to hook svnserve to
LDAP/Kerberos. (Most LDAP setups use Kerberos for managing the
passwords: LDAP stores the user information.) I'd review the options
in the svnserve configuration settings for a normal repository: I'd be
really surprised if CollabNet's version differs a lot from the normal
subversion svnserve daemon: it's the management tool, and the support,
you'd get and pay for from CollabNet. (This can be well worth paying
for!!!)
I've not taken apart the CollabNet packages: I assume they're good
interfaces, CollabNet is a generally competent company and I've gotten
good recommendations for it, especially to get commercial support for
more recent releases on operating systems like RHEL where the vendor's
published subversion is so "stable" it's dangerously obsolete. (They
used to host the public wiki's and websites for it, a very good
example of how to handle open source projects.)
Re: svn Farm
Posted by jehan procaccia <je...@it-sudparis.eu>.
Le 08/10/2010 02:19, Nico Kadel-Garcia a écrit :
> On Thu, Oct 7, 2010 at 12:18 PM, jehan procaccia
> <je...@it-sudparis.eu> wrote:
>> Le 06/10/2010 17:06, Siva Kumar a écrit :
>>>> I need to provide svn service to many small groups of students.
>>>> I'am looking for a tool that would help industrialize managment of
>>>> repositories.
>>>> I don't want to issue hundreds of "svn create", "vi authz" , edit ssh
>>>> keys
>>>> for svn+ssh access etc ...
>>>> Are there such tools already existing ?
>>> Subversion Edge(http://www.open.collab.net/go/csvne2_r2a/) might fit your
>>> bill.
>> good point !
>> I've installed and run it, looks good.
>> but now I need to find a way to link my ldap users to svn roles/authz , I
>> still can't find how to do that wihout creating csvn local accounts for all
>> my users :-( ... !?
> Unless you can guarantee that they will not use Linux or UNIX based
> clients, don't even consider this. The problem is that the Linux and
> UNIX clients, by default, continue to store passwords in clear text.
> They whinge about it now before storing it, but it's still an issue.
>
> Is there any reason you use 'svn' access, rather than HTTPS? The
> mod_dav_svn module works well, even though I detest the clear text
> password problem.
I need my users to be able to work with svn repos both from unix shell
command "svn" or through GUI clients (web browser, eclipse, tortoise ...)
For web (http) acces, it looks good now, indeed if I set ldap users
login name in the global authZ (file edit from the admin collabnet
.../editAuthorization) it works fine .
Now, is collabnet solution able to serve tradition unix shell comand
line clients ? is there a svnserve server behind it or is apache able to
serve those clients using svn protocol too ?
> There remains no good GUI or published toolkit for svn+ssh access
> configuration. This is one of Subversion's profound deficits, combined
> with the password issues with the Linux/UNIX clients. Various
> companies and groups have internal kits, including Sourceforge, but
> I've never seen their tools published.
Too bad indeed that there is no toolkit for svn+ssh :-(
Can I start aside collabnet (great and easy HTTP interface) a svnserve
serving the same repostories ?
If my unix collabnet server does know and authenticate my ldap users
(with pam_ldap, nss etc ...)
wouldn't they be able to connect to svnserve with their ldap password !?
Re: svn Farm
Posted by jehan procaccia <je...@it-sudparis.eu>.
Le 08/10/2010 02:19, Nico Kadel-Garcia a écrit :
> On Thu, Oct 7, 2010 at 12:18 PM, jehan procaccia
> <je...@it-sudparis.eu> wrote:
>> Le 06/10/2010 17:06, Siva Kumar a écrit :
>>>> I need to provide svn service to many small groups of students.
>>>> I'am looking for a tool that would help industrialize managment of
>>>> repositories.
>>>> I don't want to issue hundreds of "svn create", "vi authz" , edit ssh
>>>> keys
>>>> for svn+ssh access etc ...
>>>> Are there such tools already existing ?
>>> Subversion Edge(http://www.open.collab.net/go/csvne2_r2a/) might fit your
>>> bill.
>> good point !
>> I've installed and run it, looks good.
>> but now I need to find a way to link my ldap users to svn roles/authz , I
>> still can't find how to do that wihout creating csvn local accounts for all
>> my users :-( ... !?
> Unless you can guarantee that they will not use Linux or UNIX based
> clients, don't even consider this. The problem is that the Linux and
> UNIX clients, by default, continue to store passwords in clear text.
> They whinge about it now before storing it, but it's still an issue.
>
> Is there any reason you use 'svn' access, rather than HTTPS? The
> mod_dav_svn module works well, even though I detest the clear text
> password problem.
I need my users to be able to work with svn repos both from unix shell
command "svn" or through GUI clients (web browser, eclipse, tortoise ...)
For web (http) acces, it looks good now, indeed if I set ldap users
login name in the global authZ (file edit from the admin collabnet
.../editAuthorization) it works fine .
Now, is collabnet solution able to serve tradition unix shell comand
line clients ? is there a svnserve server behind it or is apache able to
serve those clients using svn protocol too ?
> There remains no good GUI or published toolkit for svn+ssh access
> configuration. This is one of Subversion's profound deficits, combined
> with the password issues with the Linux/UNIX clients. Various
> companies and groups have internal kits, including Sourceforge, but
> I've never seen their tools published.
Too bad indeed that there is no toolkit for svn+ssh :-(
Can I start aside collabnet (great and easy HTTP interface) a svnserve
serving the same repostories ?
If my unix collabnet server does know and authenticate my ldap users
(with pam_ldap, nss etc ...)
wouldn't they be able to connect to svnserve with their ldap password !?
Re: svn Farm
Posted by Nico Kadel-Garcia <nk...@gmail.com>.
On Thu, Oct 7, 2010 at 12:18 PM, jehan procaccia
<je...@it-sudparis.eu> wrote:
> Le 06/10/2010 17:06, Siva Kumar a écrit :
>>>
>>> I need to provide svn service to many small groups of students.
>>> I'am looking for a tool that would help industrialize managment of
>>> repositories.
>>> I don't want to issue hundreds of "svn create", "vi authz" , edit ssh
>>> keys
>>> for svn+ssh access etc ...
>>> Are there such tools already existing ?
>>
>> Subversion Edge(http://www.open.collab.net/go/csvne2_r2a/) might fit your
>> bill.
>
> good point !
> I've installed and run it, looks good.
> but now I need to find a way to link my ldap users to svn roles/authz , I
> still can't find how to do that wihout creating csvn local accounts for all
> my users :-( ... !?
Unless you can guarantee that they will not use Linux or UNIX based
clients, don't even consider this. The problem is that the Linux and
UNIX clients, by default, continue to store passwords in clear text.
They whinge about it now before storing it, but it's still an issue.
Is there any reason you use 'svn' access, rather than HTTPS? The
mod_dav_svn module works well, even though I detest the clear text
password problem.
There remains no good GUI or published toolkit for svn+ssh access
configuration. This is one of Subversion's profound deficits, combined
with the password issues with the Linux/UNIX clients. Various
companies and groups have internal kits, including Sourceforge, but
I've never seen their tools published.
RE: svn Farm
Posted by Bob Archer <Bo...@amsi.com>.
> Le 06/10/2010 17:06, Siva Kumar a écrit :
> >> I need to provide svn service to many small groups of students.
> >> I'am looking for a tool that would help industrialize managment
> of
> >> repositories.
> >> I don't want to issue hundreds of "svn create", "vi authz" ,
> edit ssh keys
> >> for svn+ssh access etc ...
> >> Are there such tools already existing ?
> > Subversion Edge(http://www.open.collab.net/go/csvne2_r2a/) might
> fit your bill.
> good point !
> I've installed and run it, looks good.
> but now I need to find a way to link my ldap users to svn
> roles/authz ,
> I still can't find how to do that wihout creating csvn local
> accounts
> for all my users :-( ... !?
Oh man, I thought edge did that for you and provided a web UI to set it up. Which is why I was considering moving to it when 1.7 came out. Not so?
BOb
Re: svn Farm
Posted by jehan procaccia <je...@it-sudparis.eu>.
Le 06/10/2010 17:06, Siva Kumar a écrit :
>> I need to provide svn service to many small groups of students.
>> I'am looking for a tool that would help industrialize managment of
>> repositories.
>> I don't want to issue hundreds of "svn create", "vi authz" , edit ssh keys
>> for svn+ssh access etc ...
>> Are there such tools already existing ?
> Subversion Edge(http://www.open.collab.net/go/csvne2_r2a/) might fit your bill.
good point !
I've installed and run it, looks good.
but now I need to find a way to link my ldap users to svn roles/authz ,
I still can't find how to do that wihout creating csvn local accounts
for all my users :-( ... !?
Re: svn Farm
Posted by jehan procaccia <je...@it-sudparis.eu>.
Le 06/10/2010 17:06, Siva Kumar a écrit :
>> I need to provide svn service to many small groups of students.
>> I'am looking for a tool that would help industrialize managment of
>> repositories.
>> I don't want to issue hundreds of "svn create", "vi authz" , edit ssh keys
>> for svn+ssh access etc ...
>> Are there such tools already existing ?
> Subversion Edge(http://www.open.collab.net/go/csvne2_r2a/) might fit your bill.
good point !
I've installed and run it, looks good.
but now I need to find a way to link my ldap users to svn roles/authz ,
I still can't find how to do that wihout creating csvn local accounts
for all my users :-( ... !?
Re: svn Farm
Posted by Siva Kumar <gs...@gmail.com>.
> I need to provide svn service to many small groups of students.
> I'am looking for a tool that would help industrialize managment of
> repositories.
> I don't want to issue hundreds of "svn create", "vi authz" , edit ssh keys
> for svn+ssh access etc ...
> Are there such tools already existing ?
Subversion Edge(http://www.open.collab.net/go/csvne2_r2a/) might fit your bill.