Re: I-D ACTION:draft-ietf-secsh-connect-12.txt

[Bill Sommerfeld <sommerfeld%east.sun.com@localhost>]

> If I haven't misunderstood anything, then perhaps an alternative
> wording might be:
> 
> | Uncontrolled setting of environment variables in a privileged
> | process can be a security hazard, so it is recommended that
> | implementations either maintain a list of allowable variable names,
> | or do not actually set the variables until after the server process
> | has dropped its privileges.

comments:

(personal observation, wg chair hat off)

Unrestricted setting of environment variables, even *after* the daemon
process sets apparently-appropriate privileges, could conceivably also
cause trouble when sshd is used to implement restricted environments
rather than give full shell access -- I'm thinking of setups like the
ones you can build with the `command="..."' option in the
authorized_keys file)... i.e., it would be a Good Thing for server
implementations to allow fine-grained control over what environment
variables can be set).

(wg chair hat on).

The IETF is primarily about wire protocols, not implementations.
environment variables are very much a local matter.  In particular,
while we can make vague recommendations, exactly when and where it's
"safe" to allow environment variables to be set is inherently
implementation specific.

Any comments on this text?

   Uncontrolled setting of environment variables can be a security
   hazard.   It is recommended that implementations exercise due care
   with requests to set environment variables, possibly including
   some form of fine-grained control over which variables may be set.

					- Bill