chroot howto for sftp-server

[Dan Astoorian]

On Tue, 18 Dec 2001 08:28:52 EST, Markus Friedl writes:
> On Tue, Dec 18, 2001 at 01:27:28PM +0100, MH - Entwicklung wrote:
> > 1. It checks if the HOME directory of the user ends with a "/./"
> 
> why does sftp-server use $HOME? should it be setuid root and
> trust $HOME?

In case Markus's subtlety is lost on some readers: privileged programs
need to be much more careful than this with chroot().  Even though
sftp-server itself gives up its privileges after the chroot(), an
attacker could create hard links to other privileged programs, which
expect to be able to trust absolute paths, and use sftp-server to run
them in unexpected contexts.

This is the reason the chroot() command is, by design, restricted to the
superuser.

Furthermore, it appears that this patch, as written, would allow a user
to gain information about directories he or she should not have
permission to access: for example, if /home/user1 is mode 0700, <user2>
can use this program to try to chroot() to /home/user1/privatedir/.  At
a minimum the attacker may determine whether or not this directory
exists based on whether the chroot() succeeds.

Even if the patch didn't trust $HOME, it doesn't do any sanity checking
on the directory it's chroot()'ing to; a more conservative patch would
verify that the target directory and its contents have nominally
acceptable ownership and permissions, e.g., that the new /, /etc, /dev,
/usr and so on are system-owned and not writable by anyone else.

The patch also fails to chdir() to the new root after the chroot(),
which is among the least of its worries given the problems listed above.

Finally: the manipulation of the environment in chroot_init() does not
look portable or safe: retrieving the value of a variable with getenv(),
modifying it, then setting the same environment variable with a
substring of the original value may be asking a bit much of the setenv()
implementation.

Yecch.

-- 
Dan Astoorian               People shouldn't think that it's better to have
Sysadmin, CSLab             loved and lost than never loved at all.  It's
djast at cs.toronto.edu        not, it's better to have loved and won.  All
www.cs.toronto.edu/~djast/  the other options really suck.    --Dan Redican