On Fri, 2015-03-20 at 03:06 +0100, Vincent Lefevre wrote: > So, it's even easier: when the admin installs some software using, > say, LC_ALLOW_ARBITRARY_ACCESS, he can change the sshd config to > disallow this variable. Sorry, but this is a highly disturbing and simply plain wrong approach to security. That way you could just set the default AcceptEnv * assuming that uses will find out all occurrences of software where they need to restrict something. > But any software can also have specific problems with standard locales > variables. As an example, the admin may allow a user to run some > script via SSH. However the script works by filtering some output > messages and only works with English messages, which correspond to > the default locales on the system. If locales variables are passed, > the user may choose another language, so that the script will not run > correctly and may bypass restrictions. Similarly, changing LC_NUMERIC > may change the decimal separator, and in particular how numbers are > parsed, which can be problematic. Yep,... that's exactly what I've meant before when I wrote that the better default would be not to allow anything. > So, really, if you want to make sure to avoid problems with the > default config, then no variables should be accepted. Well one must perhaps add, that using any non machine readable output from programs is also kinda broken (I know every one does it, including myself), since that output may change not just depending on the locale. While in turn, machine readable output should be neutral to the locale. > If you assume > that the admin does a bit of work, then accepting LC_* should be > safe. A "bit of work"? I guess checking all software for whether it may or may not use some variables in a certain way is more than just "a bit" work. > On the other hand, not being to pass the charmap (which needs a > non-standard variable for portability) could be a security issue: > for instance, outputting UTF-8 sequences in an ISO-8859-1 terminal > may change the terminal configuration, and even send some data to > the printer (which may be a public printer). Well but the difference here is that LC_CHARMAP isn't a isn't a "standardised" variable for that purpose. *If* someone used that in a way that *may* be security critical, then that's why we should have a NEWS entry about it. But apart from that, it should be rather the majority which gets a safe(r) default, than a minority who may have used such non-standardised variable. > > a) depends what you mean by "per default"... per default, my systems > > have no users after installation except root and system accounts. ;) > In such a case, with such defaults, you won't be able to ssh into > the machine, so that the AcceptEnv value doesn't matter. Log in via root? > By default the user doesn't have a restricted shell, so that > restricting the environment variables is rather useless (except > the well-known dangerous ones such as LD_PRELOAD). This is only true for "normal" user accounts, i.e. not system user accounts, where there are several prominent examples that actually make use of the command restriction features of OpenSSH (e.g. gitolite). > > c) sudo/suexec/ssh don't strip these envvars because they may or may not > > be used by someone other than root. They strip it because environment > > variables can be dangerous and it's simply sane to do so, regardless of > > the user. > > For ssh, it isn't by default (see above). Uh? I haven't looked at that bug, but when I SendEnv / AcceptEnv my local variables it works just as expected, regardless of PAM. > Restricted command execution needs some specific config by the admin. > If the admin spends time to set up these restricted commands, he can > also adjust sshd_config. Not with programs that automatically make use of them. And the act of their installation isn't more manual intervention than the act of creating a normal user. > That was the only clean way to pass the charmap. Which software is using that variable? > IMHO, either there should be useful defaults for common use, in which > case the old behavior was satisfactory (though I would have preferred > to accept MY_* variables as the MY_ prefix is conventionally used for > private purpose) o.O I'm not aware of such convention... > or Debian should focus on strict security that would > be enforced by default in every case. I wouldn't mind if the maintainer chooses to use upstream's default here. Actually that would mean less surprises for people. > But in the latter case, why > doing that just for SSH? There are various packages that are far less > secure than openssh-server accepting LC_* variables (I'm much more > concerning by the lack of check for certificate revocation than the > unlikely local use of some non-standard LC_* variable for a security > context). Well I guess we're drifting off topic,... but generally you're right that we have much more critical things, but there is always a more critical things, which doesn't mean that one mustn't or shouldn't improve the lesser things. Anyway, I guess everything has been said here,... so I'm out of the discussion. Cheers, Chris.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature