Erik Auerswald <[email protected]> writes: >> Comparing to the SSH world, then OpenSSH has this: >> >> AcceptEnv >> Specifies what environment variables sent by the client will be >> copied into the session's environ(7). See SendEnv and SetEnv in >> ssh_config(5) for how to configure the client. The TERM >> environ‐ >> ment variable is always accepted whenever the client requests a >> pseudo-terminal as it is required by the protocol. Variables >> are >> specified by name, which may contain the wildcard characters ‘*’ >> and ‘?’. Multiple environment variables may be separated by >> whitespace or spread across multiple AcceptEnv directives. Be >> warned that some environment variables could be used to bypass >> restricted user environments. For this reason, care should be >> taken in the use of this directive. The default is not to >> accept >> any environment variables. >> >> Is there any reason we shouldn't adopt something similar? Especially >> the last sentence. Allowing clients to set environment variables seems >> like a never ending source of concerns. > > I'd say adding such a configuration option to telnetd could be useful. > I'd also prefer not to accept environment variables by default, i.e., > without explicit configuration.
So add a new telnetd parameter --accept-env that accepts names of environment variables to allow clients to set? And default it to the empty set? I'm not yet sure if this will actually work, or if we are just moving the same security problem to default /etc/inetd.conf files that allowlist some environments. But maybe this is consistent with /etc/ssh/sshd_config in many distributions containing things like: AcceptEnv LANG LC_* COLORTERM NO_COLOR We should review BSD telnet's etc to see if this problem has been solved before. /Simon
signature.asc
Description: PGP signature
