chroot howto for sftp-server

[MH - Entwicklung]

Dear Dan,

of course this chroot patch is very quick and dirty and doesn't make any further checks. On the other hand - if I give the users which will get the chrooted sftp-server no shell login they shouldn't be able to play around with $HOME. I think $HOME can be trusted in this special case:

$HOME ist set to the home path given in passwd with every new shell a user opens. After connecting to ssh $HOME ist set from passwd. As I give no real shell but only sftp-server as the login shell no manipulation of $HOME should be possible.

I can see a problem for "trusted" users who login via ssh then manipulate their $HOME and then invoke the chrooted sftp-server. They will be able to access directories they shouldn't have access to. And if file permissions under this directories are set in a lax way this really means that users can access files they shouldn't see at all.

The only way to prevent this is to give no shell login to anybody. Another idea is to use a special "chroot control file" - but that means some more coding :-)

As I already mentioned I don't know if there are any possibilities using sftp-server itself for doing "nasty" things.

If I'm completely wrong with trusting $HOME please let me know.


Regards
Manfred Heubach

----- Original Message ----- 
From: "Dan Astoorian" <djast at cs.toronto.edu>
To: "MH - Entwicklung" <entwicklung at heubach-edv.de>; <openssh-unix-dev at mindrot.org>
Sent: Tuesday, December 18, 2001 5:48 PM
Subject: Re: chroot howto for sftp-server 


> 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
>