On Wednesday 27 July 2011, Andy Canfield wrote:
> I was trying to get http, svn, and svn+ssh to work.
Just one thing: Why? Why do you want more than one protocol? I could imagine
read-only HTTP and read-write HTTPS, but that's the only reason for multiple
access methods I could imagine.
> 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.
>
> 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.
Not true, they will create a new revision in the repository and that revision
is empty. ;^) No need to check out for that either, you can pass URLs to "svn
delete". No data loss either, all earlier revisions are still present and
unchanged. I agree that such a revision is disturbing though, but not a fatal
data loss.
Anyhow, if you are using svn+ssh, you are only tunnelling the svn network
protocol through an SSH connection. This is achieved by starting an svnserve
process through SSH. svnserve itself will use direct file access to the
repository. So, if you can do that and you can simply log in with a shell
using SSH, then your security hole is that users have direct access to the
files that make up a repository using an SSH shell.
If, as you claim, users don't have file access to the repo via SSH, then you
have some privilege escalation in between, probably using SUID executables.
Summary: There is no security hole in SVN that you didn't drill yourself,
either using the wrong permissions on the repository or using SUID
executables.
> 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!
The "permission [..] in Subversion" only exists in the actually used server
like Apache or svnserve (even though the svnserve configs are stored in the
repo folder). With the file access method, you need file-level access to the
repo anyway, so any "permissions" could only be considered a suggestion
anyway.
> 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?
Disable the file-level access to the repository for users, only allow access
to servers. If you need encryption, you could restrict access to using HTTPS
or restrict access via svn to connections from localhost. In the latter case,
users would have to SSH into the machine and work there or, better, create a
tunnel.
Uli
**************************************************************************************
Domino Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
**************************************************************************************
Visit our website at http://www.dominolaser.com
**************************************************************************************
Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empfänger sein sollten. Die E-Mail ist in diesem Fall zu löschen und darf weder gelesen, weitergeleitet, veröffentlicht oder anderweitig benutzt werden.
E-Mails können durch Dritte gelesen werden und Viren sowie nichtautorisierte Änderungen enthalten. Domino Laser GmbH ist für diese Folgen nicht verantwortlich.
**************************************************************************************
Received on 2011-07-27 15:50:34 CEST