Hi, It's a shame that the sshd/sftp-server programs do not support chroot and sftp-only users. As far as I can tell, there's a patch availble that modifies OpenSSH to chroot() based on a specific entry in /etc/passwd. Since, I personally, do not enjoy applying unofficial patches to released programs, I was looking for an alternative but found none. I've written a small sample program 'sftpsh' which acts as a shell replacement for sftp-only users. The 'sftpsh' is assigned to users in /etc/passwd and is used instead of fully functional shells such as /bin/bash. 'sftpsh' is primitive and only performs two tasks. First it changes the root directory to the user's home directory (chroot($HOME)) and then it exec's the 'sftp-server'. Since chroot() can only be invoked successfully as root, 'sftpsh' unfortunately has to run as root. The first thing 'sftpsh' does is chroot() followed by resetting the uid/gid. The source for 'sftpsh' is available from http://www.jonaslehmann.info/linux/sftpsh.c . If there's a more official way to accomplish this without patching or additional programs, I'd appreciate pointers. Regards, -Jonas _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp.
On Thu, 27 Dec 2001 09:02:13 EST, "Jonas Lehmann" writes:> > 'sftpsh' is primitive and only performs two tasks. First it changes the > root directory to the user's home directory (chroot($HOME)) and then it > exec's the 'sftp-server'. Since chroot() can only be invoked successfully > as root, 'sftpsh' unfortunately has to run as root. The first thing > 'sftpsh' does is chroot() followed by resetting the uid/gid.This program, like the sftp-server.c patch recently posted to this list, is potentially a huge security hole, and IMHO should not be used in its present form. There's a *reason* you have to be root in order to use the chroot() system call. This program lets any user on the system chroot() to an arbitrary directory under the user's control by setting the HOME environment variable. This can quickly lead to a root compromise, e.g., by creating hard links to privileged programs which expect to be run under the real filesystem root (or at least a secure one). Also: - the program doesn't check whether the chdir() after the chroot is successful; - the code which attempts to reset the uid/gids has a number of problems, which I won't go into here. -- 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
Thanks Dan. I agree with you. I wouldn't use either yet, either.
I did look at attempting to fix some of the obvious shortcomings you easily
and quickly detected.
The chroot($HOME) problem I had underestimated. I knew that a user with
shell access could set his $HOME and then run /bin/sftpsh. I tried that and
it certainly worked. But, I falsely assumed that by exec'ing the
sftp-server the security risk to the system would be minimal. But, I'm most
likely just naive.
I added a success check to chdir() to make sure that worked.
I'm interested in (maybe not appropriate for newsgroup) why the setreuid()
and success checking is not sufficient after chroot().
To remove the risk of $HOME exploits, I changed the sample program to use
getpwent() instead of getenv("HOME"). I'm sure this is not great
either. I
know that a user's home directory may not be secure in itself but I
conceptually like the simplicity of working with home directories.
Appreciate your feedback,
-Jonas
>From: Dan Astoorian <djast at cs.toronto.edu>
>To: "Jonas Lehmann" <dalco_lehmann at hotmail.com>
>CC: openssh-unix-dev at mindrot.org
>Subject: Re: sftp-server and chroot
>Date: Thu, 27 Dec 2001 10:18:19 -0500
>This program lets any user on the system chroot() to an arbitrary
>directory under the user's control by setting the HOME environment
>variable.
>Also:
>- the program doesn't check whether the chdir() after the chroot is
> successful;
>- the code which attempts to reset the uid/gids has a number of
> problems, which I won't go into here.
>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
_________________________________________________________________
MSN Photos is the easiest way to share and print your photos:
http://photos.msn.com/support/worldwide.aspx