PermitUserEnvironment in sshd match block?

[david knodel]

Hi,
    I just thought I might propose a mechanism that would decrease the
security risks of enabling PermitUserEnvironment:

If there were some way in the config file to limit what variables are
allowed to be passed, this would let administrators tailor the permitted
environment configuration to their O/S and organisation.


I thought that this would be the most flexible, and cause the least
pollution to the sshd_config namespace, if the PermitUserEnvironment keyword
in sshd_config (whether globally or in a match block as proposed by Daniel,
which seems like a good idea to me) could accept either the current "no" or
"yes", or some sort of list specifying what variables may be passed.
Possibilities for the format of the list could be:
    - an explicit list of environment vailables that are permitted, or
    - a mix of glob-style patterns of variables to allow, possibly with
"sudoers"-style processing where a list element with a leading '!' would
deny things matching it.
I suspect that the first option would be much simpler to implement, and
would provide more security; the more elaborate second format was an attempt
to think how to cater for admins who wanted to say something like "deny
LD_PRELOAD and LD_LIBRARY_PATH, but let other things through", but that
might not be worth catering for.
I'm not sure what the implications would/should be for the "environment="
option in authorized_keys.


Anyway, I feel a bit guilty for not offering up a patch that implements
this, but I thought that, if it seemed like a good idea, that someone more
cluey that I might want to consider putting it in if they're concerned about
the current security implications of enabling the PermitUserEnvironment
setting.




Regards,
David Knodel