scp -t . - possible idea for additional parameter

[Jefferson Ogata]

On 10/11/07 15:00, Larry Becke wrote:
[please do not remove attributions on your responses; attribution restored]
> Jefferson Ogata wrote:
>> How does that stop them? So they scp it to somewhere under their home>dir, then they ssh in and mv it wherever they want. Or they use sftp.
> Let's see.... The users that would be given this feature, wouldn't be given a password for their login.  ie - they are required to use their key.
> Their login shell (in /etc/passwd) would be /usr/local/bin/scp -T ./data
> Their key would be locked via "command=" to running the same scp -T ./data command
>  
> Their authorized_keys file would be read-only.  Their .ssh directory would be read only.
> Their home directory would be read-only.  
> There would be a "data" directory under their home directory that is the only thing writeable.

Do you not see how baroque this setup is, while not actually
guaranteeing the particular result you want (e.g. if a symlink gets
created somehow)?

>> As to why, uh, because it's an effective way to do what you want that>doesn't require modifying scp semantics.
> Really?  How is it effective if you have to copy libraries to every users' home directory structure in order to allow them to use chroot'd code?

You can create a common chroot area and place all the home directories
under it. Permissions effectively prevent one user from writing to
another user's area. Of course permissions already do that on a properly
configured system, which is why I don't understand why you're bothering
with all this.

> chroot cannot be run as anyone but root, so you cannot use it in the "command=" section (i've tried).

Yes; if chroot could be executed by non-root users, it wouldn't provide
effective containment.

>> Ah, so you want to use scp as a shell. Most peculiar. Would that even work?  
> 
> Yes - it works very well, except that it doesn't restrict the user to their home directory.

By which you mean you've actually tested it? What happens to the sshd
process's attempt to tell the user's shell to execute scp -t or scp -f?

> I want to add a simple parameter parse that errors out if "../" is in the remote path, and adds "./" between the host segment and path segment of the remote path.

Disregarding symlinks, are you sure those measures will effectively
constrain the user's activity on every platform openssh runs on,
including, for example, Cygwin, or a system with a Unicode filesystem?

> I'm not asking to *enforce* anything.  I'm not asking for tons of changes to watchdog anything.  I'm only asking for a very simple front end change that takes effect when scp is started with "-T" instead of "-t".

You certainly are asking to enforce something. Or look at it this way:

1. You could do this properly and make *sure* a user can't write outside
the target directory. This requires examining every platform openssh
runs on to make sure that the strategy you've chosen works in all cases,
handling symbolic links, and thinking about any other escape vectors as
well. It also requires auditing scp to make sure that it doesn't allow
circumvention of these restrictions in *any* part of the protocol.

2. You could do it halfway, ignoring symbolic links and platforms other
than the one you happen to be interested in, to just get it working the
way you want. Any measure that does not address all platforms, or
attempts to add application security to openssh in an obviously
incomplete manner, may be rejected by the openssh maintainers.

If you do 1, you give ssh users the expectation that their users really
are confined to the target directory (in that particular configuration
you've described above where they have no access to the system other
than via scp, and authorized keys files have been effectively protected
against tampering). A very few people may actually rely on this for
system security, and if they set everything up correctly, their
expectation will be fulfilled. On the downside, you're adding additional
code to scp, and you're constraining future development not to break the
semantics you've imposed.

If you do 2 (i.e. don't do 1 properly), you give ssh users the *false*
expectation that their users really are confined to the target
directory. If they rely on this for security, this harms them.

> Simple administrative tasks and permissions will take care of the rest.

Indeed, these measures can take care of all of it reliably without any
modification to scp. This is pretty much the reason that filesystem
permissions were invented.

> It's a very subtle change, one that won't impact anyone who uses scp in it's default manner, and would give admins a very simple and effective tool to restrict secure file transfers (ie production system transfers - not day to day users) to the directory we designate as the remote source/destination.

It's that term "effective" that is in question.

> Whether or not you can see the need for something like this, or agree with my reasoning for this, I'm asking simply, can it be done?  What harm would there be in adding it?   

As to whether it can be done, why don't you give it a shot?

As to harm, see above.

-- 
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