openssh unix dev - Dec 2024 - PAM session setup and environment variables

On Thu, 19 Dec 2024, Dmitry V. Levin wrote:
> > We could potentially allow-list some variables, but I'd like to
get
> > some input from people who (for example) maintain PAM for
distributions
> > on what is acceptable.
> 
> With my Linux-PAM hat on, the most essential difference between the
> authenticated user code that currently gets the environment variables
> listed in AcceptEnv, and the PAM modules session code that currently
> doesn't get them, is that PAM modules session code is privileged, so
extra
> care should be taken not to forward there accidentally any environment
> variables that could affect that privileged code in an unintended way.
> 
> While XDG_SESSION_CLASS and XDG_SESSION_TYPE variables mentioned by Michal
> are harmless, those LC_* variables AcceptEnv'ed in many default setups
are
> also likely to be OK, allowing arbitrary variables listed in AcceptEnv
> could be risky given that some PAM session modules like pam_namespace and
> pam_exec invoke external executables and could be affected by e.g. LD_*
> variables.
> 
> 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?

-d

On Fri, Dec 20, 2024 at 09:25:11AM +1100, Damien Miller
wrote:
> On Thu, 19 Dec 2024, Dmitry V. Levin wrote:
> 
> > > We could potentially allow-list some variables, but I'd like
to get
> > > some input from people who (for example) maintain PAM for
distributions
> > > on what is acceptable.
> > 
> > With my Linux-PAM hat on, the most essential difference between the
> > authenticated user code that currently gets the environment variables
> > listed in AcceptEnv, and the PAM modules session code that currently
> > doesn't get them, is that PAM modules session code is privileged,
so extra
> > care should be taken not to forward there accidentally any environment
> > variables that could affect that privileged code in an unintended way.
> > 
> > While XDG_SESSION_CLASS and XDG_SESSION_TYPE variables mentioned by
Michal
> > are harmless, those LC_* variables AcceptEnv'ed in many default
setups are
> > also likely to be OK, allowing arbitrary variables listed in AcceptEnv
> > could be risky given that some PAM session modules like pam_namespace
and
> > pam_exec invoke external executables and could be affected by e.g.
LD_*
> > variables.
> > 
> > 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.


-- 
ldv