Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

scp -t . - possible idea for additional parameter

0 views
Skip to first unread message

Larry Becke

unread,
Oct 2, 2007, 7:57:53 PM10/2/07
to

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
_______________________________________________
openssh-unix-dev mailing list
openssh-...@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

Bob Proulx

unread,
Oct 2, 2007, 8:45:39 PM10/2/07
to
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

Larry Becke

unread,
Oct 3, 2007, 5:07:21 AM10/3/07
to

One of the minor issues we face as we tackle security issues is the idea th=
at scp allows someone to navigate directory structures that aren't restrict=
ed to the user that is logging in.
=

If we were to implement a switch that a) forced pathing to be relative to t=
he startup directory parameter, and b) either filtered the client side scp =
command parameters to ensure that it remained relative, or errored out if "=
../" were used as part of the destination path parameter.
=

How this is implemented is by tying keys to specific directories, so when y=
ou =

=

scp -i xyz_key filename.ext remhost:
the remote server is configured to do
=

command=3D"/full/path/to/bin/scp -t /some/home/dir" =

=

It would copy the filename.ext file to the /some/home/dir directory on remh=
ost.
=

However, at this time, this does not *lock* the user into that directory.
=

If they were to execute
=

scp -i xyz_key filename.ext remhost:/tmp
=

It would allow the user to copy filename.ext to the /tmp directory on remho=
st.
=

If we implemented -T to force relative to startup path, then
=

command=3D"/full/path/to/bin/scp -T /some/home/dir"
=

when the user used
=

scp -i xyz_key filename.ext remhost:/tmp
=

it would attempt to copy the file to /some/home/dir/tmp on remhost
=

If /some/home/dir/tmp didn't exist on remhost, it would fail.
=

=

That is what I am looking for, and am hoping would be trivial to implement.
=

This would give a relatively simple way to control where a user went, and i=
f configured as a startup parameter in sshd_config, could force *all* scp c=
onnections to be relative.
=

=

=

> Date: Tue, 2 Oct 2007 18:39:20 -0600> To: guyv...@hotmail.com> CC: opens=
sh-un...@mindrot.org> Subject: Re: scp -t . - possible idea for addition=
al parameter> From: b...@proulx.com> > Larry Becke wrote:> > By locking, I m=
ean 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.> > N=
ot 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
_________________________________________________________________
Help yourself to FREE treats served up daily at the Messenger Caf=E9. Stop =
by today.
http://www.cafemessenger.com/info/info_sweetstuff2.html?ocid=3DTXT_TAGLM_Oc=
tWLtagline

Peter Stuge

unread,
Oct 3, 2007, 10:26:46 PM10/3/07
to
On Wed, Oct 03, 2007 at 02:46:06AM -0500, Larry Becke wrote:
> One of the minor issues we face as we tackle security issues is the
> idea that scp allows someone to navigate directory structures that
> aren't restricted to the user that is logging in.

That is not how scp works, that is how the server operating system
works.

scp does not allow or enable anything that has been disabled before
or outside scp.

OpenSSH uses the user's shell for any and all executions on behalf of
a user, including scp and sftp-server. If you want to restrict users,
the shell is a nice place to implement policy.


//Peter

0 new messages