On Sun, Aug 1, 2010 at 5:23 AM, Stefan Sperling <stsp_at_elego.de> wrote:
> On Sat, Jul 31, 2010 at 10:22:42PM -0400, Nico Kadel-Garcia wrote:
>> On Sat, Jul 31, 2010 at 9:12 AM, Stefan Sperling <stsp_at_elego.de> wrote:
>> > Fortunately, today, we have support for KDE Wallet and Gnome Keyring.
>> > So you can set up a secure password cache on *nix, if you have KDE
>> > or Gnome, at least.
>>
>> Unfortunately, both are X session based, and don't work well with
>> command line sessions. X.... is a useful technology, but a painful
>> resource pig in many remote development environments. The "keychain"
>> tool works reasonably well for keeping access to an encrypted SSH key
>> for command line work.
>
> AFAIK it's possible to run gnome-keyring without X.
It's painful. Take a glance at
http://superuser.com/questions/141036/use-of-gnome-keyring-daemon-without-x,
which documents manually editing /etc/pam.d/ login settings. It's also
heavily dependent on X libraries.
> This works similar to the ssh-agent, which prints a couple of
> environment variables which help with contacting the running daemon.
> eval `gnome-keyring-deamon --some-magic-option-maybe`
> Never tried it myself though.
I've used it: it's available with into the 'gdm' window manager for X
sessions, which does not necessarily run for detached X sessions,
especially for single X programs run remotely.
>> Actually, while being somewhat rude, Linus made some good points about
>> the flaws of centralized source control systems, and the inferior
>> performance of Subversoin for merging.
>
> But those problems were well known before his talk.
Not to everyone. While he was rude, he made technical points about
merging difficulties, and about detached operations, and naming scheme
conflicts. We could get into other comparisons.
>> > If you use svn+ssh:// on unix, the password store in ~/.subversion/auth/
>> > is not used. I've been under the impression that SSH does not store passwords
>> > in plaintext. It can store passphrases for pubkeys in plaintext.
>>
>> Didn't it used to do this?
>
> AFAIK it never did that.
If it didn't, I apologize formally. I could have sworn that it did at
some point: I've had to deal with it since verson 1.2, and don't fancy
going back to test it right now.
>> Getting X servers deployed and configured is.... a separate
>> issue in many development environments.
>
> Yeah, but see above. It should be possible to run gnome-keyring without X.
It should be possible to have peace in the Middle East, tool.
Unfortunately, I don't see a feasible roadmap for this feature in any
distribution's pure-text logins. Don't get me wrong, it's a good
toolkit, but not complete.
>> I've given a few specific examples. While it's gotten better and
>> you've addressed some of my concerns, my overall concerns still stand.
>> Cleartext password storage is a big problem, frequently ignored by
>> deployers and developers who don't realize it's still there and who've
>> never had to clean up the mess when someone leave passwords on a
>> laptop or an NFS fileshare.
>
> Yes. But I'm not convinced adding another config knob to enable it
> will fix that. People who favour comfort over security will just
> enable it.
The "config knob" already exists, seriously. It's in the default
.subversion/config file, in these two lines:
# This should be uncommented, and the binary tweaked for it to be
"no" by default
store-passwords = no
# This should be uncommented, and the binary tweaked for it to be
"no" by default
store-auth-creds = no
The syntax of .subversion/config is, unfortunately, somewhat
confusing. For most such config files, the defaults are left in the
file, commented out. It's only when someone wants to change them that
they uncomment specific lines and modify their content: uncommenting
the line normally changes nothing in most such config files, such as
/etc/ssh/sshd_config or /etc/postfix/main.cf.
For whatever historical reason, the authors of this config file chose
to use an alternate layout with alternative settings commented out,
instead of the standard settings.
>> > Please raise the issue again when Subversion 2.x comes around.
>>
>> What is the timetable for that?
>
> None so far :)
Ahh. Vaporware. Then I'd like to give me a pony everytime I
successfully do a code merge. And a little man with a bucket and
shovel to clean up after the pony everytime I do a successful tagged
release.
>> The difficulty lies in *preventing* people with such password based
>> access from using the command line "svn" tool and storing the
>> passwords behind your back, in the face of such education.
>
> Well, that's a social problem to be solved, not a technical one.
> No amount of technical lock-down will fix the social problem.
Locking down the default .subversion/config file settings to refuse to
store authentication tokens without manual intervention would be a
helpful first step. That's a technologically modest configuration
change, and won't break existing instances, only cause some
well-earned consternation for new clients who shouldn't be storing
passwords there anyway.
>> It's
>> feasible on an individual level, but unenforceable in most
>> environments. As soon as you use passwords that are used for anything
>> else, you face this risk of password storage.
>
> One outstanding item on the svn roadmap is server-supplied client
> configuration. With that feature, unless developers temper with their
> svn client's code, the server will be able to tell the client not to
> store the password in clear text (among other things, it's also useful
> for configuring auto-props). This is a higly desirable feature, and will
> improve deployment of Subversion in enterprise environments once available.
> Current plan is adding this post-1.7. Maybe 1.8?
Oh, brother. While understandable, it seems like a protocol impereling
interface change. I can see it for auto-props.
>> No. I know my limitations and engineering time available. Anoncvs is
>> only acceptable for CVS because CVS essentially has no security,
>> anyway. Replicating it and calling it a "restricted shell" would be an
>> unfortunate misclaim.
>
> If you're saying that a special restricted shell would be a useful
> thing to be published in Subversion's standard distribution, that's
> certainly something we could talk about. I"d be interested to work
> on that if it really helps making svn+ssh:// deployments easier to secure.
Or as a 3rdparty add-on. anoncvs doesn't cut it: using a shell script
as a restricted shell is begging for people to break out of the shell
and gain command line access.
There are really two approaches to svn+ssh authentication management:
a restricted shell would allow LDAP and similar account management to
provide a system level tool for account management and password
management and GSSAPI authorization. (Note that GSSAPI is not
available for many enterprise SSH servers, but that is slowly
changing.) But as soon as it's hooked to HTTP or HTTPS access, the
passwords can wind up stored locally on the Linux or UNIX clients, so
it actually adds to the security risk in a startling and unexpected
way for most system administrators dealing with Subversion. A
dedicated shell would help for this, in that the LDAP server could
provide alternative passwords and shells for all users on a dedicated
Subversion server host and reduce the system access risks of the LDAP
provided passwords, and make certain not to use HTTP or HTTPS access,
but it's still an issue if the users use the same password elsewhere.
The SSH key management is technologically easier, since the SSH keys
can be tied to a particular application of a particular account. That
account would, ideally, use a restricted shell to limit system risks,
particularly when someone mishandles the "authorized_keys" entries.
And people do mishandle those, not realizing that they grant shell
access unless you read the *entire* Redbook entry on svn+ssh and do
the last, most complicated example.
But there is still no good management tool for those keys. I've looked
several times, and found nothing reliable or scalable. The "gitosis"
add-on tool for git would be a good model for this: it uses its own
git based repository for managing the user keys, with source control
of the key changes. I've seen nothing similarly capable for Subversion
yet, though, darn it. Do you know of one that works?
Received on 2010-08-01 18:59:47 CEST