On Tue, 2015-06-30 at 01:23 +0200, Vincent Lefevre wrote: > On the other hand, having the wrong charmap on the other side is a > security issue, because remote utilities could send characters that > they think to be printable, but are actually control characters / > escape sequences due to the wrong charmap interpretation. Well but there one knows / must assume at least that this can happen: When one remotely accesses a system and processes output from there, it must be assumed that there are different locales/etc. and appropriate means taken. But programs on remote side shouldn't need to assume that they're invoked remotely. But practically,... are there any issues? Most systems likely either use C or UTF-8, and I'd be tempted to say it's a their problem if they use some obscure charmap. > I wish SSH could pass the charmap Wouldn't that basically end up in the same concerns? > A SSH user should read the SSH documentation. If SSHENV_* is > documented by SSH, then I don't see any problem with that. If one doesn't have a globally standardised list of "reserved" env vars, then IMHO the duty is to be set on the responsible side. By that I mean, a program that runs on the remote side, shouldn't have the duty to take into account that it may be executed from via another host. It hast the "right" to assume it's usual environment. The duty should be on the side who is doing the remote call (i.e. the client) respectively the sysadmin/user who maintains SSH on the remote side. "SSH user" as you write above is however the developer of the remotely running program,... as you assume he'd be a SSH user and should therefore read the docs. I know this sounds all quite philosophical,... but where would that end? Can the developer of some application (and the sysadmins) really be expected to: a) take into account that some application may run from remote with a potentially even maliciously changed environment? b) if we start making exceptions of variables beyond e.g. POSIX,...like XTERM_* or VTE*, can we expect developers and admins to keep up with that (possibly growing) list? That they adapt scripts/programs which may be ages old and/or unmaintained, so that they don't collide with such variables? > If you complain about SSHENV_*, why not complaining about > the existing SSH_ORIGINAL_COMMAND too? Theoretically it's the same problem. In practise it works, however, for those reason: 1) hopefully not one accidentally uses these names for other purposes, completely unrelated to SSH. 2) Those special vars are at least consistent across all OpenSSH, i.e. it's not a Debian speciality that SSH_ORIGINAL_COMMAND is set, while it would be for e.g. XTERM_VERSION 3) And the main differences with the SSH_* vars is: sshd sets their value, it's not really env var passing as in the sense of XTERM_VERSION, where an arbitrary value can be set. > > The ForceCommand option wouldn't be enough... there are other ways > > in > > SSH to restrict the executed commands. > > Well, also with command="command" in the authorized_keys file. > This would cover most needs. > > Nothing prevents the remote server's admin to run special shells > > where > > env var setting isn't possible. > > He could even forbid execution of any foreign programs (using > > selinux > > and the like),... so no real way for the client to circumvent this. > > IMHO, an admin who takes the time to set up such special shells > and so on, could also take some very little time to change the > sshd Debian defaults. Since it's easily configurable, and since it seems to be rather a problem of difficult sysadmin from systems which oneself doesn't control,... I'd rather says the responsibility lays at the other side. Further, this isn't such an completely obscure scenario: A special shell could be something like gitolite. It's invoked via ssh, it writes files to the disks, these files are perhaps somehow parsed later for authz questions and so on. The default behaviour of ssh is to not accept env vars. And the default behaviour of most programs/servers, I'd know, is to assume "if the envvar is there, then it'save". That's why e.g. apache's suexec deletes everything except a few ones which are known to be safely set. So again, I don't think it's the responsibility of all these people to secure themselves against a possibly growing list of var names which may or may not affect their programs. You should further take into account, that if we make an exception now, further desires may sooner or later grow. Why not forwarding things like HTTP_PROXY* (which may include some password) ... if the user uses e.g. Tor locally, he may want to have the same done out-of-the box remotely. Or why not forwarding stuff like XDG_* or GTK_*? If the user runs GUI applications remotely any maybe have his homedir mounted there, it could "help" to provide a more homogeneous "experience" (e.g. same GTK theme). *shrugs* This examples may sound exaggerated, but I think it demonstrates quite well how problematic these things may be; btw. not only in terms of security but also data privacy (e.g. do I really want, that arbitrary remote sides get to know which local I run, without my explicit consent? e.g. whether I'm French, German or Chinese?). In the end, it should be clear to everyone that by default, SSH is a clear cut between a local and a remote system. Anything the integrates the sides more closely, like the env var passing may do, or like SSH agent forwarding, should be possible - but not done by default. Best wishes, Chris.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature