On Tue, 2015-06-30 at 04:30 +0200, Vincent Lefevre wrote: > > 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. > > This is not possible. Or this would mean that the remote programs > can only output US-ASCII (which is compatible with everything). I don't understand what you mean. My point was, applications/systems use different locales. Nothing will change that. Thus when you process output from a remote application on the local system, you must assume that this is happening or assure that the expected locale is going to be set remotely as well. But the later doesn't mean that it should be done automagically and generally per default. > > 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. > > Well, ISO-8859-1 is not an obscure charmap and still exists in > Debian. Is there a strong reason to use it instead of UTF-8? (of course this alone doesn't fix your problem :) ). > Moreover I fear that with a C terminal, some UTF-8 sequences sent by > the remote side may be interpreted a escape sequences (if some bytes > are in the 0x80-0x9f range). See... the same, just looked at from the other side, is the reason why we shouldn't try to make these things automagically working. Plus there is no real guarantee that by accepting something like TERM, LC_*, etc. at the server side even guarantees that the client get's what it likes. For TERM this is most obvious: The terminfo files on the remote side may have a different version as locally, so even when one transmits it per default it still make be wrong in the end. And I wouldn't bet that this will be better for version string variables like XTERM_VERSION. Vars like this tend to be used improperly by 3rd party apps, making them sooner or later immutable or wrongly set. Again take TERM... many other terminal emulators != xterm (or is it just GNOME? ;) ) still set it to "xterm", thereby breaking the whole idea of TERM. There's no guarantee that this doesn't also happen for more clearly versions vars. In fact, I know some ugly hacked scripts that set things like BASH_VERSION unconditionally for obscure reasons - whether bash is used or not. All these things count to the many reasons why env vars are quite often considered problematic from a security PoV and towards my point of not automatically accepting/sending them. > > > I wish SSH could pass the charmap > > Wouldn't that basically end up in the same concerns? > > In what way? Doesn't it also potentially affect the output/behaviour of programs? > Anyway, the upstream recommendation is to use AcceptEnv, which is > precisely what Debian is doing. With one tiny but important difference: upstream doesn't set a default and is strongly against having a default that would send/accept variables. They even point to the security concerns in the manpage. AFAIU, they have the same policy that I try to defend here: It's important to have Send/AcceptEnv so that people can (hopefully knowing what they're doing) send/accept envvars. But not per default. > > > 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. > > The goal is to have SSHENV_* as being reserved. I still don't understand how this would help you, as you'd still need to feed that vars back into their real names for things to work automatically. So it seems a bit as if you just look for some (per default) white listed tunnel, where I'd rather say it seems like a hacky solution for the real problems of "difficult" sysadmins. > > > 1) hopefully not one accidentally uses these names for other > > purposes, > > completely unrelated to SSH. > > I don't see why. Why would some program accidentally use SSHENV_FOO > but could not accidentally use SSH_ORIGINAL_COMMAND? Some days ago, a package like "thefuck" or so was added to the NEW queue, along with a discussion about whether that name is acceptable for Debian. This in turn reminded me about the "Lumia" which is former Nokia's smartphone but also (IIRC) a Spanish slang word for "prostitute" or something like that. In other words, what may seem obvious (i.e. that an env var of a certain name "belongs" to a certain sytem) to you and me, may be not to someone else. > Well, IMHO, SSHENV_* (or similar) should become official upstream... > unless upstream thinks that this is not necessary and the current > AcceptEnv is fine. I still have concerns about this and would think it's rather not so good from the security POV (but of course better than directly sending/accepting e.g. LC_*) But in any case, *if* such "tunnel" namespace would be send/accepted per default, than this should be discussed/decided at upstream. > > 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. > > According to sshd(8), "The command originally supplied by the client > is available in the SSH_ORIGINAL_COMMAND environment variable." > > Since it is supplied by the *client*, it can be quite arbitrary. oops,... for SSH_ORIGINAL_COMMAND you're of course right, sorry,.. I had my minds circling around SSH_CLIENT, SSH_CONNECTION and that like. Well as I've said before, I also don't like SSH_* very much (which doesn't mean I'd have a better solution ;-) ). But SSH_ORIGINAL_COMMAND is at least not generally set, but rather only when command="command" and I think ForceCommand are used, which both again, isn't the case per default. > > 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. > > Similarly, the special shell could delete most of the environment > when > starting. This would be a bad design paradigm. - It's error prone: an arbitrary number of applications would need to be adapted, and all future applications would need to take the same steps for protecting themselves. That's just the reason why we e.g. don't do that env var sanitisation in each and every cgi script, but why apache has suexec which blocks everything for all of them. - Protecting themselves against something caused by a system which they may not even have direct business with. In other words, it pushes away responsibilities from those causing the change (i.e. the remote connection system - SSH) to those haven't caused it. - If such paradigm would be followed,... i.e. allow all changes and let the others do the work to protect themselves against it, it would be basically impossible for applications to keep up with that. > > 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. > > Why not? See above, the "This would be a bad design paradigm." part. > BTW, a ssh server can have several users, with different needs: > some will need some environment variable passing, others won't > need that and can always clean up the environment before doing > anything else (say, start with "env -i" or do something similar). Which can be easily facilitated by a number of technologies in OpenSSH: - environment="NAME=value" in authorized_keys - PermitUserEnvironment in sshd_config (notice again, that the default to this directive is of course "no" for security reasons - just as with Send/AcceptEnv) - Match/Host blocks that select config directive based on the User/Host in ssh[d]_config But the same applies here, we shouldn't add further variables that are set/send/accepted per default and we should ideally remove those which alrady are. > If the user doesn't want to send environment variables, then he > shouldn't use SendEnv in his config file! I think in the end, but sides must be protected, server and client. This is why I make not difference between sending/accepting env vars. > Note: I'm not sure whether the /etc/ssh/ssh_config SendEnv settings > can be overridden. If this is not possible, then the SendEnv > directive > should be removed from this file. This is not a problem for the user, > who can add SendEnv directives in his .ssh/config file if he wishes > to pass environment variables. In ssh usually (there are some strange special cases where this behaviour is a little bit altered) the first occurrence of a directive defines the value with later ones being ignored. So it can be overwritten. Best wishes, Chris.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature