
david.l.knodel at gmail
Aug 25, 2009, 7:28 PM
Post #3 of 7
(2768 views)
Permalink
|
|
Re: PermitUserEnvironment in sshd match block?
[In reply to]
|
|
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 _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev [at] mindrot https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
|