[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: ssh+svn vs. bash security bug?

From: Nico Kadel-Garcia <nkadel_at_gmail.com>
Date: Thu, 25 Sep 2014 05:38:13 -0400

On Thu, Sep 25, 2014 at 4:08 AM, Stefan Sperling <stsp_at_elego.de> wrote:
> On Wed, Sep 24, 2014 at 07:30:57PM -0400, Nico Kadel-Garcia wrote:
>> Setting up a chroot for Subversion for just this purpose gets...
>> potentially adventuresome. The maintainers of OpenSSH have generically
>> refused to support chroot changes, so it's a bit awkward to even set
>> up. Various folks have published patches or integration kits to
>> support genuine chroot cages: heck, even I used to publish patches for
>> OpenSSH to provide them.
>
> I have to admit that while I did successfully chroot svnserve with
> svn:// once, I've never tried to chroot svn+ssh://
>
> But I'd be surprised if OpenSSH was making this difficult.
> The ChrootDirectory configuration option of OpenSSH won't do?
> If so, why not?

They used to reject it wholesale. I think due to demand, they've
lightened up in various ways. OpenSSH 6, which I've not personally
gotten to use in production, allegedly is the most graceful about it.
But this is what I run into with setting up sftp or ssh based cages
with OpenSSH 5 and ChrootDirectory:

           " Specifies a path to chroot(2) to after authentication. This
             path, and all its components, must be root-owned directories
             that are not writable by any other user or group. After the
             chroot, sshd(8) changes the working directory to the user’s
             home directory.

That means that if you "chroot to the the user's home direcotory" for
things like sftp or scp access, their home directory must be owned by
root, and they effectively cannot create or delete directories at the
top of their own home directory. This leads to..... interesting
confusion.

In theory, for svn+ssh, it's more workable. The top level directory
needs be owned by root, and the repository and other components can be
gracefully in subdirectories.

> Upgrading bash is a better solution to this particular problem,
> of course, but using a chroot containing the minimum components
> could still be a good idea in general.

Now that RHEL 7 is out with much more recentn OpenSSH, I'll see if I
can find some cycles to investigate chrooting svn+ssh with that. I
suspect I'll be be cheating like hell and using "bind" mounts of
"/usr", which is fairly loathsome to insert into a restrecticted
chroot cage, but potentially fast and effective.
Received on 2014-09-25 11:38:43 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.