Transferring file to local machine when SSHing into a foreign box

[Dotan Cohen]

On Mon, May 14, 2012 at 4:50 PM, John Olsson M
<john.m.olsson at ericsson.com> wrote:
>> So the feature does not have to be exposed under those
>> connection conditions. Only expose the feature when
>> connecting to a shell instance.
>
> How does the SSH server know this? Shall it be a configuration option per subsystem?
>

The feature will be initiated by a CLI command on the server (remote)
side. So if there is no shell to run commands, then the feature is not
exposed to use by the user. See the prior mail on the subject, dated
Sun, 13 May 2012 17:32:58 +0300 by me. Later I'll summarise the issue
so that we won't have to keep referring back to eclectic emails.


>> So this interface doesn't even need the feature. Terrific.
>> I don't understand what the problem is.
>
> I do not want a situation where you suddenly out-of-the-box get file transfer capabilities for a node which does not intend to offer file transfer capabilities. Or for that matter gives access to another set of files compared to what is exposed via SFTP.
>

Then a config setting such as PermitCpLocal would be prudent.


> I really hope I have misunderstood what it is you want to do. :)
>

I hope not! I would rather that you point out the flaws to help hone
it into something feasible _and_ safe.


>> If the administrator of the machine provides the user with read
>> access to a file via BASH or any other shell in SSH, then the
>> user can provide himself with the contents of the file. Their
>> currently is no straightforward method, but there exist
>> painstaking methods and if that is not considered a security
>> hole (copy-pasta from console) then the proposed method is
>> neither a security hole. In other words, the proposed method
>> exposes no information that is not already exposed.
>
> I'm just considering the case when the "shell" is not an ordinary Bash-like shell that offers a filesystem view. Thus I do not want any mechanism that allows for escaping out of the sandboxed environment offered by the "shell". For instance being able to ferret out files that is not possible to see via the "shell". Or, for that matter, place files in the filesystem.
>

That is not an issue with the current idea of the implementation. Only
files that the user has read access to in his SSH session are
available to transfer, and if the user already has read access then he
can already just copy the (text) files out of his terminal.


> Please also note that the logon procedure might not be based on uid and gid. The "shell" might have its own security model based on custom LDAP attributes which restricts what the user is capable of doing and if the user is able to escape from the "shell" everything is done with the rights of the "shell" process.
>

There is no escaping from the shell. Only those file for which the
user has explicit read access are available.


>> How is this any different than the user typing "vim /etc/password"
>> in a shell via SSH and then copying the contents of the file from
>> his terminal?
>
> If it is possible to access /etc/passwd from an SSH built-in feature to escape from the "shell" to be able to get file access of the nodes filesystem to transfer files in and out it is a huge difference.
>

Huge difference? There is no escaping from the shell, I don't know why
you insist on using that term. If the user can open a file in VIM,
then he can download the file. It is the same exact file access which
UNIX has been providing for decades, and SELinux is refining.

Imagine the script running like this behind the scenes:
cat someFile > scp

Only if the user can cat the file then can he transfer it.


>> I appreciate that you raise the issue! I expect that there will
>> be contingencies that I do not think of, and it is better to
>> work them out right now. I thank you for providing your input,
>> _especially_ when it mentions things that I have not thought of.
>
>
> Excellent! That is my intention. People are doing weird things and all computers out there is not just a "Linux box with Bash"... ;)
>
>
>> Also, presumably there will be configuration options to disable
>> this feature, something like "PermitCpLocal".
>
> I would definitely prefer it the other way around; Opt-In instead of Opt-out. That is you must explicitly ask for the feature to enable it; default it should be turned off.
>

That might be a good idea to start with. New access features should
always be opt-in in my opinion.



-- 
Dotan Cohen

http://gibberish.co.il
http://what-is-what.com