openssh unix dev - Apr 2002 - Chroot of SCP and SFTP-server

Hi,

I was thinking about the difficulties and complexities of using chroot in
scp or sftp-server, in order to limit the user in which files they can
access.

I've seen a lot of arguments about how it is pointless to try and secure scp
or sftp (also from a logging perspective) because if we allow SSH access,
the user can simply provide their own scp or sftp binary, that does not do
the controls that the admin wants. 

But that presupposes that the user actually has shell access and can execute
arbitrary commands.

Setting the user's shell to /usr/bin/sftp-server or to /user/bin/scp should
be sufficient to restrict the user to only copying files. They DO still have
the ability to roam around the filesystem, however. Hence the debates around
chroot, and rejection of the various proposals, due to having to build
"chroot filesystems" that contain the necessary executables.

Here is a simpler proposal:

How difficult is it to restrict the parent directory that they may write to?
e.g. only permit relative paths, and prohibit any "../" path
components?
Exactly how one would tell scp or sftp-server to "pseudo-chroot"
themselves
is a different problem. Maybe have a "restricted-scp"?

So for example, user joe is allowed to scp files to his home directory, but
not anywhere above that.

joe:*:501:501:::/home/joe:/bin/restricted-scp

restricted-scp refuses to honour any paths that contain a leading '/',
or
contain a '/../' string. So he can't wander out of his home
directory. Can
SCP or sftp server create symlinks, that could potentially go above the home
directory? That functionality should also be restricted, as above, using the
same rules.

I think this would answer the problems that a number of people have, that
are preventing them from getting rid of FTP.

Maybe it would still be possible to use chroot in these circumstances, for
those that don't like trying to eliminate "parent paths". If
sftp-server
chroots at startup, wouldn't that solve the problem? Does sftp-server or scp
use any external binaries to implement any file transfer functionality?

One may have to implement a "-c" option to scp and sftp-server that
simply
exits, to handle instances where ssh tries to exec .profiles, or .ssh/rc
files, before actually running an interactive shell. Something like:

if [ $1 = '-c' ] ; then
  if [ "$2" = "$0" ] ; then
    shift
    shift
  else
    exit
  fi
  # parse the rest of the params
fi

if the parameter to the option == "my filename", then skip "-c
param", read
the rest of the params, else exit(0).

Does this make any sense?

Thanks

Rogan




Disclaimer and Confidentiality Note.

Everything in this e-mail and attachments relating to the
official business of Standard Bank Investment Corporation(Stanbic)
is proprietary to the company. It is confidential, legally privileged
and protected by law. Stanbic does not own and endorse
any other content. Views and opinions are those of the
sender unless clearly stated as being that of Stanbic.

The person addressed in the e-mail is the sole authorised recipient.
Please notify the sender immediately if it has unintentionally reached
you and do not read, disclose or use the content in any way.

Stanbic can not assure that the integrity of this communication has been
maintained nor that it is free of errors, virus, interception or interference.

"Dawes, Rogan R" wrote:
> 
> Hi,
> 
> I was thinking about the difficulties and complexities of using chroot in
> scp or sftp-server, in order to limit the user in which files they can
> access.
> 
> I've seen a lot of arguments about how it is pointless to try and
secure scp
> or sftp (also from a logging perspective) because if we allow SSH access,
> the user can simply provide their own scp or sftp binary, that does not do
> the controls that the admin wants.
> 
> But that presupposes that the user actually has shell access and can
execute
> arbitrary commands.
> 
> Setting the user's shell to /usr/bin/sftp-server or to /user/bin/scp
should
> be sufficient to restrict the user to only copying files. They DO still
have
> the ability to roam around the filesystem, however. Hence the debates
around
> chroot, and rejection of the various proposals, due to having to build
> "chroot filesystems" that contain the necessary executables.
> 
> Here is a simpler proposal:
> 
> How difficult is it to restrict the parent directory that they may write
to?
> e.g. only permit relative paths, and prohibit any "../" path
components?
> Exactly how one would tell scp or sftp-server to "pseudo-chroot"
themselves
> is a different problem. Maybe have a "restricted-scp"?
> 
> So for example, user joe is allowed to scp files to his home directory, but
> not anywhere above that.
> 
> joe:*:501:501:::/home/joe:/bin/restricted-scp
> 
> restricted-scp refuses to honour any paths that contain a leading
'/', or
> contain a '/../' string. So he can't wander out of his home
directory. Can
> SCP or sftp server create symlinks, that could potentially go above the
home
> directory? That functionality should also be restricted, as above, using
the
> same rules.
> 
> I think this would answer the problems that a number of people have, that
> are preventing them from getting rid of FTP.
> 
> Maybe it would still be possible to use chroot in these circumstances, for
> those that don't like trying to eliminate "parent paths". If
sftp-server
> chroots at startup, wouldn't that solve the problem? Does sftp-server
or scp
> use any external binaries to implement any file transfer functionality?
If you want to chroot() you need to be setuid root.  (becouse by this
stage sftp is running in user's context).  My preferred solution (shot
down once before, so I never got the coding finished) is to use
'realpath()', but it does have inherint race conditions.  

Andrew Bartlett

-- 
Andrew Bartlett                                 abartlet at pcug.org.au
Manager, Authentication Subsystems, Samba Team  abartlet at samba.org
Student Network Administrator, Hawker College   abartlet at hawkerc.net
http://samba.org     http://build.samba.org     http://hawkerc.net