openssh unix dev - Oct 2007 - scp -t . - possible idea for additional parameter

How difficult would it be to add an additional parameter to the -t that would
*lock* the user at that directory level.  say -T instead of -t...
 
By locking, I mean translating /path/to/file as ./path/to/file, or
../../../path/../../../path/to/file as ./path/to/file.
 
Basically set a root point as the current home directory, then build the pathing
based on that, any "../" would become "./" if the
"../" would go above that home directory.
 
Just a thought...
_________________________________________________________________
Peek-a-boo FREE Tricks & Treats for You!
http://www.reallivemoms.com?ocid=TXT_TAGHM&loc=us

Larry Becke wrote:
> By locking, I mean translating /path/to/file as ./path/to/file, or
> ../../../path/../../../path/to/file as ./path/to/file.
>  
> Basically set a root point as the current home directory, then build
> the pathing based on that, any "../" would become "./"
if the "../"
> would go above that home directory.
Not sure this is what you want but look into the 'rsync --relative'
option.

  http://rsync.samba.org/
  http://rsync.samba.org/ftp/rsync/rsync.html

Bob

I understand that that is not how scp works today. 
I'm suggesting that we make a minor change to how it works. Here's the
underlying reason why I think this is a good idea. The efforts required to lock
down todays systems with their myriad of access features is not a trivial task. 
I'm not suggesting this will make it trivial to completely secure a system. 
I am suggesting this will make it trivial to secure one subset of the system. 
That subset being scp. Using chroot'd environments doesn't really work
(or at least they were never intended to be used as a security tool) without
tons of effort, and even then, they tend to break rapidly with simple
system/software updates. sftp at the present time, gives access to too many
additional commands / features that are unnecessary for a simple file transfer.
scp would fit the bill nicely, with one minor change. Let's forget about
translating ../ to something else. Given the "-T" instead of
"-t" startup parameter, a simple walk through the parameters passed by
the scp client spawning the scp server should do the following:Prefix the remote
path with "./", so that remhost:/path/to/file becomes
remhost:.//path/to/file.If the remote path contains "../" anywhere,
error out. With this change, we can forget about scp-only or chroot'd
environments and all the convoluted mess required to make that work. Either
spawn scp with the "-T" via a public key authentication command entry,
or the sshd_config file "UseSCPPathLock=Yes". Through this option, we
get a secure method of transfering files without much effort. Combine this with
pub-key authentication, and command= parameters, you can control where any user
places their files if outside of their home directories.  Simple user
permissions on the remote server control whether or not writes are allowed, or
just reads. A very simple change could open a whole lot of opportunity for usage
expansion. If sftp-server had this same option, then that might work, however, I
haven't seen that it does - yet there would seem to me to be a lot more
changes required to implement the same idea within sftp-server as it would
within scp.
_________________________________________________________________
Help yourself to FREE treats served up daily at the Messenger Caf?. Stop by
today.
http://www.cafemessenger.com/info/info_sweetstuff2.html?ocid=TXT_TAGLM_OctWLtagline

>1. Why do you think this change provides effective security?
 
   Specifying the starting directory, and not allowing the user to navigate
above it effectively locks the user within that directory.
>2. Have you ever tried to implement something like this, dealing
with>symbolic links, bind mounts, etc.?
   Since you cannot transfer symlinks directly via the scp command, there
wouldn't be any in the directories we would be using on the remote system.  
>If you want to confine users effectively, chroot them.
chroot'ing should not be used as a security method, that's been clearly
stated time and again.
_________________________________________________________________
Help yourself to FREE treats served up daily at the Messenger Caf?. Stop by
today.
http://www.cafemessenger.com/info/info_sweetstuff2.html?ocid=TXT_TAGLM_OctWLtagline