Bug#780797: openssh-server: modifies the user configuration
On 2015-03-20 05:54:03 +0100, Christoph Anton Mitterer wrote:
> 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.
Using * is bad because some environment variables are known to be
used by the system and can affect security (e.g. LD_PRELOAD).
IMHO, LC_* is an acceptable *compromise* (no known problems
in practice).
> > 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.
No, this is not the practical usage. Some output are both for human
and the machine ("grep -r LC_ /etc" can give you some idea of scripts
that may depend on the locales if not set back to C).
> > 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.
No need to check all software. Just the restricted commands that
can be run via SSH. Some commands might do other harm (e.g. run
an interactive shell), so that the admin should check all the
possibilities anyway.
> > > 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?
This is disabled by default, for security reasons!
See "PermitRootLogin no".
> > 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).
For these specific case, one can check that the default AcceptEnv
is safe.
> Uh? I haven't looked at that bug, but when I SendEnv / AcceptEnv my
> local variables it works just as expected, regardless of PAM.
Perhaps because your system isn't configured to enforce some
locales. The corresponding bugs on the Debian BTS:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=313317
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=408029
> > That was the only clean way to pass the charmap.
> Which software is using that variable?
No software. This is for *private* use. The locales are set-up via
my .zshenv file, using this private LC_CHARMAP variable.
--
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Reply to: