> If we're aiming for flexibility without sacrificing security, then a new
> sshd_config keyword (e.g. PAMSessionAcceptEnv) could be added to specify
> what is allowed to be forwarded to the PAM session modules.
Thanks for chiming in. How about we accept variables from a narrow
allow-
list (XDG_SESSION_CLASS/TYPE, LC_*) for now and see how it goes?
Sounds good. Since nobody asked to forward LC_* and LANG variables to
the
PAM session modules yet, we could start with just XDG_SESSION_CLASS and
XDG_SESSION_TYPE variables.
Wouldn't it be better (as in, more secure) to define
the session type and/or class on the server side
in the authorized_keys line?
That would provide the "if our monitoring system comes asking"
differentiation
without allowing any new untrusted client-side data.
Or is that too late already?
Thinking more about this, a Match in sshd_config might also be helpful
--
though that can't (as of yet) use the incoming pubkey.
But at least the logical incoming user can be matched up,
even if that one then translates to "just" another UID 0 or whatever.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
