RFE: sshd should be able to set environment variables defined by the client, e.g. it should be possible that the user defines a value of an environment variable as part of the "ssh" command-line arguments and "sshd" then sets that environment variable for the application to execute.
If we implement this, we will probably only do it for a couple of environment variables (LANG and maybe LC_*) as passing arbitrary environment variables provides new opportunities for a user to break out of restricted shell.
Damien Miller wrote: > If we implement this, we will probably only do it for a couple of environment > variables (LANG and maybe LC_*) as passing arbitrary environment variables > provides new opportunities for a user to break out of restricted shell. Good idea. I suggest to add support for filtering name=value pairs via extended regex pattern - one "accept" pattern and one "reject" pattern. Anything which matches the "accept" pattern and doesn't match the "reject" pattern should be accepted. accecpt_pattern should look like this ("match all" for now): ".*=.*" reject_pattern should look like this (kill linker and ssh env vars... and DISPLAY since that's used by the X11 forwarding code): "(^LD.*=.*|^SSH.*=.*|^DISPLAY.*=.*)" Generally whitelisted should be: CVSROOT CVS_RSH LANG LC_MESSAGES LC_TIME LC_NUMERIC LC_CTYPE LC_MONETARY LC_COLLATE LC_PAPER LC_ALL LPDEST (used by print spooler to set default printer) PRINTER (used by print spooler to set default printer) PDPRINTER (used by print spooler to set default printer) XPRINTER (used by Xprint - see http://xprint.mozdev.org) XPSERVERLIST (used by Xprint - see http://xprint.mozdev.org) TZ (timezone) MAIL (unix mail folder location)
Created attachment 578 [details] Implement environment passing The attached patch implements environment passing for -current. ssh gains an option "SendEnv", which specifies which environment variables may be sent. sshd gains "AllowEnv", which controls what environment variables are accepted (I don't much like this option, it may go away in favour of a fixed list). Both of these options may be specified multiple times (with cumulative results) and both take basic "*" and "?" wildcards. This needs testing, especially with non-OpenSSH implementations.
Damien Miller wrote: > ssh gains an option "SendEnv", which specifies which environment variables may > be sent. sshd gains "AllowEnv", What about the explicit "reject" list ? > which controls what environment variables are > accepted (I don't much like this option, it may go away in favour of a fixed > list). A hardcoded list may be bad. If someone finds a possible exploit via the "env-var"-forwarding it may be a good idea to have a quick way for admins to block the env var used for that.
reject lists are bogus. default should be 'deny'.
Created attachment 620 [details] Revised environment passing diff Revised diff with a couple of changes: - Manpages - s/AllowEnv/AcceptEnv/ in sshd_config, so hopefully people won't expect a symmetric DenyEnv (like the other Allow options) - Regress test - Passed env vars get added only if !use_login
This has been committed and will be in 3.9