Transferring file to local machine when SSHing into a foreign box

[John Olsson M]

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


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

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


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

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.


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


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


/John

-----Original Message-----
From: Dotan Cohen [mailto:dotancohen at gmail.com] 
Sent: den 14 maj 2012 15:31
To: John Olsson M
Cc: Ángel González; openssh-unix-dev at mindrot.org
Subject: Re: Transferring file to local machine when SSHing into a foreign box

On Mon, May 14, 2012 at 1:33 PM, John Olsson M <john.m.olsson at ericsson.com> wrote:
>> If the user has access to read a file in a BASH shell then what is to 
>> prevent him from copying the text of that file right from his 
>> terminal? In fact, that is exactly what I have been doing and is 
>> quite the reason for suggesting the download feature.
>
> You are missing my point. I'm talking about a node/computer/machine/... that offers a CLI interface via SSH on port 22 that is *not* a generic Bash-like shell. Instead it is a text-based managmenet interface of some equipment (for instance a switch or a router). This interface does not operate on files, instead it is configuration commands.
>

So the feature does not have to be exposed under those connection conditions. Only expose the feature when connecting to a shell instance.


> This node also offers an SFTP interface where a file system is exposed (some kind of virtual filesystem) where files can be uploaded and downloaded. Files in this virtual filesystem can ofcourse be referenced from the SSH CLI interface (e.g. configuration data is read from a file etc.).
>

So this interface doesn't even need the feature. Terrific. I don't understand what the problem is.


> The SFTP service might run in a chrooted environemnt, whereas the SSH CLI interface can not do this due to that it must be able to access (behind the scenes) all of the physical filesystem.
>

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.


> If you now enable support so that you could transfer /etc/passwd via a built-in SSH command from a node that does not expose a filesystem in the shell I see this as a security problem. That is, since the SSH CLI process can access a larger/different part of the filesystem, the proposed built-in SSH CLI filesystem transfer command could then expose any file that the process can access, right?
>

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?


> I'm just raising this issue, since not all nodes that offer SSH access 
> looks and behave the same way. Not everything is a Bash shell. :)
>

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.


Also, presumably there will be configuration options to disable this feature, something like "PermitCpLocal".

--
Dotan Cohen

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