sftp chroot requirements

[Nico Kadel-Garcia]

On Sat, May 2, 2015 at 9:05 AM, Stephan Leemburg
<sleemburg at hachimitsu.nl> wrote:
> Hi Damien,
>
> Thank you. I read the rationale.
>
> Just to summarize, a user writeable chroot target is considered dangerous
> if:
>
> 1) the user has another way of gaining non-chrooted access to the system
> 2) is able to create hardlinks to setuid-binaries outside of the chroot tree

Improperly secured symlinks are a similar though not identical
problem. The operating system does not know how to prevent a symlink
inside a chroot cage from being allowed to write a system-read file
for which that nominal chrooted user has privileges. Hilarity can
ensue.

> 3) there are bugs somewhere that allow privilige escalation or remote
> execution of other programs

I've been reviewing some of this lately, related to sftp, scp, and
rsync chrooted targets managed thorugh the 'rssh' software. There are
fascinating escalations that can happen. For example, 'suid' and
'sgid' are related but independent properties

> While all these arguments are legitimate, as can be - indeed - seen in
> CVE-2009-2904, I believe that there are also other situations.
>
> In our setup, we have users that currently only have vsftpd chrooted access.
> Their login shell is /sbin/nologin and they do not have any other way of
> accessing the system. So for this particular setup 1 and 2 are not
> applicable.

vsftpd doesn't keep the vsftpd binary, itself, inside the chroot cage
or any loadable libraries that might be found there. That is part of
where the problem comes from: you have to bring in quite a lot of
components tools to allow sftp or scp or ssh over rsync to operate
inside such a cage. And if you bring in copies of files, rather than
hardlinks or symlinks, how do you make sure they stay updated when you
update system OpenSSH or system libraries?

That is partly why I spent time recently on updating a 'mkchroot.sh'
script precisely for rssh users, at
https://github.com/nkadel/rssh-chroot-tools.

> I think 3 is not related to sftp chroot only, but in general.

> So, in my opinion there are use cases that would not compromise security by
> having the last component of the chroot sftp directory be owned by the user.
> If this could be a configurable option, then administrators that want to use
> such a setup could do so by explicitly allowing it.

If they can do an rsync, or write directly to it, they can re-arange
and replace bin or lib. That's pretty close to the core of the
concern.

I freely admit that in almost cases where people really need a chroot
cage, OpenSSH cages are the wrong solution. vsftpd works pretty well.
Git works well, and gets revision history, for recording changes. Even
WebDAV over HTTPS can work pretty well, and none of those have to have
anything owned by root or run as a root user inside the chroot cage.

If you *must* use chroot cages, you might look at using rssh as a
wrapper for it. It's a lot easier, and more stable than trying to
maintain the patched OpenSSH often used for full chroot cage
operations.

> Is that something you could live with? If so, can I create a patch and send
> it in?
>
> Again, thank you for the pointers. I had trouble finding them with just
> plain search engine lookups.
>
> Kind regards,
> Stephan