openssh unix dev - Aug 2009 - PermitUserEnvironment in sshd match block?

Hello,

Our campus environment would find it very useful to pass user- 
environment variables for certain login ssh connections, but of course  
want to avoid the security problems with LD_PRELOAD and  
PermitUserEnvironment as described in sshd_config manpages.

Would the best answer be a patch that adds PermitUserEnvironment  
support inside match blocks? Are there technical or other reasons this  
has already been considered and rejected?

Thanks,
Daniel Allen

Computing Technology Specialist
Computer Science Computing Facility (CSCF)
David R. Cheriton School of Computer Science
University of Waterloo
(519) 888-4567 ext. 35448
drallen at uwaterloo.ca

Daniel Allen wrote:
> Hello,
> 
> Our campus environment would find it very useful to pass 
> user-environment variables for certain login ssh connections, but of 
> course want to avoid the security problems with LD_PRELOAD and 
> PermitUserEnvironment as described in sshd_config manpages.
> 
> Would the best answer be a patch that adds PermitUserEnvironment support 
> inside match blocks?
That seems like a reasonable thing to do.
> Are there technical or other reasons this has 
> already been considered and rejected?
The approach to adding things to Match has been on a case by case basis, 
checking if the thing is a) useful and b) safe.  It's a lot easier to 
evaluate these thing one at a time than in a large batch of them.

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
     Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.

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

On Wed, 26 Aug 2009, david knodel wrote:
> 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.
We could make PermitUserEnvironment accept a pattern-list to match
environment variables, while retaining "yes", "no",
"true" and "false"
as their current meanings of allow/deny-all.

-d

Daniel Allen wrote:

 > Would the best answer be a patch that adds PermitUserEnvironment  
support
 > inside match blocks?

Darren Tucker wrote:

 > The approach to adding things to Match has been on a case by case  
basis,
 > checking if the thing is a) useful and b) safe.  It's a lot easier to
 > evaluate these thing one at a time than in a large batch of them.

Damien Miller wrote:

 > We could make PermitUserEnvironment accept a pattern-list to match
 > environment variables, while retaining "yes", "no",
"true" and
"false"
 > as their current meanings of allow/deny-all.

Both (or either) of these options would meet our current needs very  
well.  The pattern-list would seem the more elegant approach for our  
use.  I am sorry that I don't have the wherewithal to submit a patch  
now, though if it helps things along I'd be happy to submit a bugzilla  
request.  Or not, if you prefer.

Thanks for your work,
Daniel Allen

Computing Technology Specialist
Computer Science Computing Facility (CSCF)
David R. Cheriton School of Computer Science
University of Waterloo
(519) 888-4567 ext. 35448
drallen at uwaterloo dot ca

Daniel Allen wrote:
> Our campus environment would find it very useful to pass
> user-environment variables for certain login ssh connections,
I guess it's arbitrary variables? If only a limited set you could
sprinkle some AcceptEnv into sshd_config.


//Peter