Chroot of SCP and SFTP-server

[Andrew Bartlett]

"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