On Wed, Jul 27, 2011 at 12:06 AM, Andy Canfield
<andy.canfield_at_pimco.mobi> wrote:
> I was trying to get http, svn, and svn+ssh to work.
Dude. Pick one. Getting all three to play nicely together is destablilizing.
> HERE IT IS USING HTTP:
> svn info http://athol/svn/subdoc
> Authentication realm: <http://athol:80> Athol Subversion Repository
> Password for 'andy':
> Path: subdoc
> URL: http://athol/svn/subdoc
> Repository Root: http://athol/svn/subdoc
> Repository UUID: 1dd2dddc-19a3-44a7-a91e-dc9b8306a138
> Revision: 4
> Node Kind: directory
> Last Changed Author: andy
> Last Changed Rev: 4
> Last Changed Date: 2011-07-27 03:27:29 +0700 (Wed, 27 Jul 2011)
Hold it right there. You're providing password based repository access
via HTTP, not HTTPS? Please rethink this unless you *want* the
passwords for this repository to be quite insecure and sniffable,
especially if you're using normal user login passwords.
Also note. For HTTP access from Linux and UNIX systems, the default
behavior is to store the password, in cleartext, in
$HOME/.subversioon/. *That* is a longstanding security issue that I've
been ranting about for *years*. Subversion 1.6.x, very reasonably, now
asks for permission before doing that, But if you're using the same
password authenticatoin for svn+ssh://, http://, https://, and svn://
based access, you're now writing your password in plain text. locally.
svn+ssh:// doesn't recored that plain text password, http:// and
htps:// do.
> HERE IT IS USING SVN:
> svn info svn://athol/subdoc
> Authentication realm: <svn://athol:3690> Subversion svnserve
> Password for 'andy':
> Path: subdoc
> URL: svn://athol/subdoc
> Repository Root: svn://athol/subdoc
> Repository UUID: 1dd2dddc-19a3-44a7-a91e-dc9b8306a138
> Revision: 4
> Node Kind: directory
> Last Changed Author: andy
> Last Changed Rev: 4
> Last Changed Date: 2011-07-27 03:27:29 +0700 (Wed, 27 Jul 2011)
Again. Unencrypted passwords, unless you're using something like SASL.
Do not use this for normal user passwords.
> HERE IS THE PROBLEM USING SVN+SSH:
> svn info svn+ssh://athol/data/svn/subdoc
> The authenticity of host 'athol (192.168.1.113)' can't be established.
> ECDSA key fingerprint is 4a:9d:73:24:94:24:15:a8:08:0c:cd:59:72:d4:3a:d7.
> Are you sure you want to continue connecting (yes/no)? yes
> kids_at_athol's password:
> Path: subdoc
> URL: svn+ssh://athol/data/svn/subdoc
> Repository Root: svn+ssh://athol/data/svn/subdoc
> Repository UUID: 1dd2dddc-19a3-44a7-a91e-dc9b8306a138
> Revision: 4
> Node Kind: directory
> Last Changed Author: andy
> Last Changed Rev: 4
> Last Changed Date: 2011-07-27 03:27:29 +0700 (Wed, 27 Jul 2011)
>
> What's 'worse' about it? Well, 'kids' is a valid user name on the server;
Which it need not be. The gudebook does not make this clear enough:
For users who have normal shell access *anyway*, many sites do use
this approach and simply set the repository to be manged with group
access to designated users. But in the "we don't want people to need
shell access to use svn+ssh", you need to set up something like an SSH
key on a shared account with forced commands, typically with this kind
of URL.
svn+ssh://svn@sitename/svn/reponame/
That "svn" user can be set to have no valid shell, with its shell set
to something like "/sbin/nologin". This is actually quite common for
system services to have no valid shell. This is how the "apache" or
"www-data" user is usually set up.
> 'kids' can ssh into the server. But 'kids' has no authorization to access
> any Subversion repository in any way. To me this means that svn+ssh is a
> GIGANTIC security hole.
See above. That "forced command" bit is really important for systems
where you don't want subverson authorized users to have shell access.
I've actually had extensive battles about this sort of thing with
sites where the internal policy was "as long as they're in, we already
trust them with shell on such servers".
This is actually tied to a subtler, longstanding deficit in
Subversion: a dedicated shell for an "svn" user. I've attempted myself
to integrate this sort of thing into the "rssh" toolkit used for rsync
access.
> Consider these commands:
> ssh kids_at_example.com
> rm -rf /data/svn/subdoc
> They do nothing; user 'kids' has no right to see anything inside the
> /data/svn directory, which is owned by www-data and readable (and writable)
> only by that user.
Only if you're using the "shared account" access method to svn+ssh,
where the URL includes the username or otherwise successfully forces
access to have that username. If you're doing the unfortunately common
approach of normal user accounts with shared group access to the
Subversion repository, you can scrub the database clean. It's one of
the reasons I *hate* that normal user account method. The same sort of
thing occurs in CVS repositories: it allows a considerable amount of
relocation and behind the scenes editing of Subversion repositories,
and is one of the ways to flush oversized binaries, such as DVD
images, that soomeone might accidentally incorporate. It's also a way
to *completely* screw up a repo for someone else, and one of the
strongest reasons to have a backup system that uses 'svnsync' and
talks to another location.
Yeah. This is why you use a shared, SSH key accessed account without
normal login shell access, but with for forced "commands" associated
with the SSH keys. It's awkward and means you need key management, and
it is untenable to use for single-sign-on tools such as Kerberos with
GSSAPI. But it does seem to be *exactly* what Sourceforge uses, and
has for years, for both CVS and Subversion repository access. Their
git repository access can use the built in git shell tool more easily,
and I'm sure it does.
> But consider these commands:
> mkdir t
> cd t
> svn checkout svn+ssh://example.com/data/svn/subdoc
> svn delete *
> svn commit
> These will post a revision deleting everything in the repository. And this
> second set of commands relies only on 'kids' being able to log in to the
> server; they need not have any permission to do anything in Subversion!
First: that command won't do what you think. You'll wind up with
t/subdoc, and the "svn delete" command will be in the "t" directory,
and the "svn delete *" will be run from a non-subversion parent
directory. But that's not the problem.
The problem you're describing here is that in a normal, casually
configured setup, it is *designed* to allow write access to the whole
repository, and you can do something like any of these:
svn delete http://athol/svn/subdoc/*
svn delete svn://athol/subdoc/*
svn delete svn+ssh://athol/data/svn/subdoc/*
You don't need to check out anything to do moves and deletions, and
this is normal. But all users in a casual setup have full access to
delete *ANYTHING*, and to re-arrange it at whim. This is why the
access control hooks are designed to allow people to say "OK, only the
admins are allwed to write to trunk" or "only admins are allowed to
write tags" or "anyone can create or flush branches, anyone can create
tags, but no one can *delete* or move tags", and all the other
options.
> Is there any way to modify things on the server to disable the svn+ssh:
> protocol without disabling either standard ssh or the svn: protocol?
Turn the question around. svn+ssh:// has to be *enabled* by providing
the shared write access to the Subversion repositories. Simply keep
the repositories owned with write permissions restricted to the
designated "www-data" or "apache" user, and rely on the authentication
to set the user for incoming connections, and there will be no enabled
svn+ssh:// access.
Frankly, I think people are a lot safer with the svn+ssh:// because of
the password handling.
Received on 2011-07-27 15:34:48 CEST