Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: OpenSSH: Dev

PermitUserEnvironment in sshd match block?

 

 

OpenSSH dev RSS feed   Index | Next | Previous | View Threaded


drallen at cs

Aug 25, 2009, 12:08 PM

Post #1 of 7 (3113 views)
Permalink
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
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev


dtucker at zip

Aug 25, 2009, 6:27 PM

Post #2 of 7 (3010 views)
Permalink
Re: PermitUserEnvironment in sshd match block? [In reply to]

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.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev


david.l.knodel at gmail

Aug 25, 2009, 7:28 PM

Post #3 of 7 (3011 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


djm at mindrot

Aug 26, 2009, 10:10 AM

Post #4 of 7 (2998 views)
Permalink
Re: PermitUserEnvironment in sshd match block? [In reply to]

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
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev


drallen at cs

Sep 4, 2009, 6:46 AM

Post #5 of 7 (2919 views)
Permalink
Re: PermitUserEnvironment in sshd match block? [In reply to]

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

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev


peter at stuge

Sep 4, 2009, 7:13 AM

Post #6 of 7 (2920 views)
Permalink
Re: PermitUserEnvironment in sshd match block? [In reply to]

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
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev


djm at mindrot

Sep 4, 2009, 1:13 PM

Post #7 of 7 (2916 views)
Permalink
Re: PermitUserEnvironment in sshd match block? [In reply to]

On Fri, 4 Sep 2009, Peter Stuge wrote:

> 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.

AcceptEnv only applies to environment variables passed by the ssh(1)
client, not to ~/.ssh/environment.

-d
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

OpenSSH dev RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.