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

>> I understand that that is not how scp works today.>And it will
likely never change.
Why not?  Just because "That's how we've always not done it"
doesn't sound like a very good reason to me.
>> I'm suggesting that we make a minor change to how it works.>scp
is maintained for compatibility reasons only, as I've understood>things.
That's still not a valid reason to not implement a very simple
change.
>> I am suggesting this will make it trivial to secure one subset
of>> the system.  That subset being scp.>Moot point unless scp is the
only way users can use the system, which>I don't think is the case all
too often.
In my specific case, it is the point.   I'm using a public key
authentication, where the parameter defined in the authorized_keys file is
 
command="/usr/local/bin/scp -t /some/path/to/dir" ....remainder of
key....
>Either you're prepared to make an effort in order to make the
system>secure, or it doesn't matter. Hacking up scp is good for neither.
:\
Why should *everyone else in the world* have to go through all the hassle of
trying to make a "secure" product secure, when a very simple fix,
would effectively lock scp so that it couldn't go anywhere above the
directory specified in the startup with the -T (like -t) parameter.
 
The simple change outlined would truly make scp *secure* from all perspectives,
as opposed to only being secure via the transport.  It could be a significant
feather in the cap of the project.
 
If the -T were configurable to be a selectable (either through the build
process, or the sshd_config file) all scp transfers could be locked into the
user's home directory, which wouldn't be a bad thing at all for those
who would want it to be that way.
 
 
Larry
_________________________________________________________________
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

On 10/10/07 16:00, Larry Becke wrote:
> Why should *everyone else in the world* have to go through all the hassle
of trying to make a "secure" product secure, when a very simple fix,
would effectively lock scp so that it couldn't go anywhere above the
directory specified in the startup with the -T (like -t) parameter.
1. Why do you think this change provides effective security?

2. Have you ever tried to implement something like this, dealing with
symbolic links, bind mounts, etc.?

If you want to confine users effectively, chroot them.

-- 
Jefferson Ogata <Jefferson.Ogata at noaa.gov>
NOAA Computer Incident Response Team (N-CIRT) <ncirt at noaa.gov>
"Never try to retrieve anything from a bear."--National Park Service