openssh unix dev - Sep 2001 - reinit_creds (was Re: OpenSSHd barfs upon reauthentication: PAM, Solaris 8)

>Neither the Sun PAM documentation nor the Linux-PAM documentation
>describe the semantics of PAM_REINITIALIZE_CREDS in any useful detail.
I would agree it is vague, but then that is also a problem with the XSSO
document (http://www.opengroup.org/onlinepubs/008329799/)
>Could we please have a clarification on the semantics of
>PAM_CRED_ESTABLISH vs. the semantics of PAM_REINITIALIZE_CREDS?
My interpretation is:

You call PAM_ESTABLISH_CRED to create them
You call PAM_REINITIALIZE_CRED to update creds that can expire over time,
for example a kerberos ticket.
>My guess, given what OpenSSH does with PAM: PAM_CRED_ESTABLISH means
>"make it so we can use your module's credentials as root"
whereas
>PAM_REINITIALIZE_CREDS means "make it so we can use your module's
>credentials as pam_get_item(PAM_USER)."
That is wrong and is one thing the XSSO doc is clear on:

"The pam_setcred() function is used to establish, modify, or delete the 
credentials of the current user associated with the authentication handle,
pamh. "

The Solaris pam_setcred(3pam) man page is less clear - I'll file a man
page bug for Solaris to get it clarified better.
>And, given what OpenSSH does, it seems that
>pam_setcred(PAM_REINITIALIZE_CREDS) should be called with
>(euid==0 || uid==0) and gid/egid/groups setup to be the PAM_USER's.
That depends and unfortunately the whole issue of what the uids should
be in effect for the application calling any pam_* function is not
specified.

For Kerberos it will work just fine if called as the PAM_USER but for
Secure RPC creds that get established in pam_unix on Solaris there are
some times that the euid needs to be root.  Also for doing getspnam
lookups to statisfy pam_authenticate when using /etc/shadow.
>But none of this is documented!
Agreed the docs do not specify the level of privilege required by
the application for calling pam_* functions.

In someways I think it should be upto the modules to document what they
need but I also think this could break the abstraction that PAM is supposed
to provide.
>As for PAM_KRB5, assuming my interpretation of PAM_REINITIALIZE_CREDS is
>correct, it should create a root-owned ccache when it's pam_sm_setcred()
>is called to PAM_CRED_ESTABLISH and it should create PAM_USER-owned
>ccache when it's pam_sm_setcred() is called to PAM_REINITIALIZE_CREDS.
That is not how pam_krb5 on Solaris is designed to work.

If you call pam_setcred() with pam_krb5 on the stack it assumes that
you have already called pam_authenticate to get the kerberos password
and do the kerberos authentication.  That is fine for the case that
started this disucssion since pam_authenticate had been called since
password authentication was used.

It will always create a cred cache file owned by PAM_USER, the only
way you could get the effect you describe above is if you called
pam_setcred with PAM_USER as root, changed PAM_USER using pam_set_item
to be <user> - but this isn't what OpenSSH does (and it is wrong
anyway).

I'm not sure the call to pam_setcred with PAM_REINITIALIZE_CREDS is
actually required in session.c.  Why was it put there ?  Is there a
particular pam module that causes a problem ?


--
Darren J Moffat

Thanks. Inline.

On Wed, Sep 05, 2001 at 01:18:57PM -0700, Darren Moffat
wrote:
> >Neither the Sun PAM documentation nor the Linux-PAM documentation
> >describe the semantics of PAM_REINITIALIZE_CREDS in any useful detail.
> 
> I would agree it is vague, but then that is also a problem with the XSSO
> document (http://www.opengroup.org/onlinepubs/008329799/)
> 
> >Could we please have a clarification on the semantics of
> >PAM_CRED_ESTABLISH vs. the semantics of PAM_REINITIALIZE_CREDS?
> 
> My interpretation is:
> 
> You call PAM_ESTABLISH_CRED to create them
> You call PAM_REINITIALIZE_CRED to update creds that can expire over time,
> for example a kerberos ticket.
PAM_RENEW_CREDS is there for credential renewal (i.e., ticket renewal,
in the Kerberos case). That's clear from its name.

PAM_REINITIALIZE_CREDS is, well, completely undocumented (I'll recheck
the XSSO docs). The OpenSSH interpretation is clear.

And, IMO, as I think about it, the OpenSSH interpretation makes plenty
of sense. Consider an app that will not fork() a child that runs as the
PAM_USER (e.g., a web server) but which nonetheless needs the user's
Kerberos creds -- why bother creating a user-owned ccache then?

With the OpenSSH interpretation of PAM_REINITIALIZE_CREDS it is possible
to have such apps.
> >My guess, given what OpenSSH does with PAM: PAM_CRED_ESTABLISH means
> >"make it so we can use your module's credentials as root"
whereas
> >PAM_REINITIALIZE_CREDS means "make it so we can use your
module's
> >credentials as pam_get_item(PAM_USER)."
> 
> That is wrong and is one thing the XSSO doc is clear on:
> 
> "The pam_setcred() function is used to establish, modify, or delete
the
> credentials of the current user associated with the authentication handle,
> pamh. "
Why does that description not jive with my interpretation of the OpenSSH
interpretation of the pam_setcred() flags' semantics? I mean, I don't
see why.
> The Solaris pam_setcred(3pam) man page is less clear - I'll file a man
> page bug for Solaris to get it clarified better.
> 
> >And, given what OpenSSH does, it seems that
> >pam_setcred(PAM_REINITIALIZE_CREDS) should be called with
> >(euid==0 || uid==0) and gid/egid/groups setup to be the PAM_USER's.
> 
> That depends and unfortunately the whole issue of what the uids should
> be in effect for the application calling any pam_* function is not
> specified.
> 
> For Kerberos it will work just fine if called as the PAM_USER but for
> Secure RPC creds that get established in pam_unix on Solaris there are
> some times that the euid needs to be root.  Also for doing getspnam
> lookups to statisfy pam_authenticate when using /etc/shadow.
I agree that pam_setcred() should be called as root (if the caller app
has such privs) for all pam_setcred() operations, save, except,
possibly, PAM_RENEW_CREDS (well, from pam_krb5's point of view
anyways).
> >But none of this is documented!
> 
> Agreed the docs do not specify the level of privilege required by
> the application for calling pam_* functions.
> 
> In someways I think it should be upto the modules to document what they
> need but I also think this could break the abstraction that PAM is supposed
> to provide.
I think different modules will have different needs here, but one might
not want to use pam_unix with a web server, say, so that one might not
need to have the web server run as root at all -- whereas pam_unix's
setcred() function must be called with root privs.
> >As for PAM_KRB5, assuming my interpretation of PAM_REINITIALIZE_CREDS
is
> >correct, it should create a root-owned ccache when it's
pam_sm_setcred()
> >is called to PAM_CRED_ESTABLISH and it should create PAM_USER-owned
> >ccache when it's pam_sm_setcred() is called to
PAM_REINITIALIZE_CREDS.
> 
> That is not how pam_krb5 on Solaris is designed to work.
> 
> If you call pam_setcred() with pam_krb5 on the stack it assumes that
> you have already called pam_authenticate to get the kerberos password
> and do the kerberos authentication.  That is fine for the case that
> started this disucssion since pam_authenticate had been called since
> password authentication was used.
I've written parts of a PAM_KRB5 (based on Frank Cusack's original)
which behaves slightly differently: its auth method saves the user's
Kerberos creds in a memory ccache and stuffs that into the pam handle as
pam data, and its setcred method actually creates the file ccache (and
destroys the memory ccache).
> It will always create a cred cache file owned by PAM_USER, the only
> way you could get the effect you describe above is if you called
> pam_setcred with PAM_USER as root, changed PAM_USER using pam_set_item
> to be <user> - but this isn't what OpenSSH does (and it is wrong
anyway).
This is silly -- why create a user-owned ccache *before* the account
management part of PAM has been called and suceeded??

In fact, it seems clear to me that no user-owned ccache should be
created outside pam_krb5:pam_sm_setcred().
> I'm not sure the call to pam_setcred with PAM_REINITIALIZE_CREDS is
> actually required in session.c.  Why was it put there ?  Is there a
> particular pam module that causes a problem ?
See above about apps that don't fork() a process that runs as the
PAM_USER.
> --
> Darren J Moffat

Nico
--

Visit our website at http://www.ubswarburg.com

This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free 
as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses.  The sender therefore 
does not accept liability for any errors or omissions in the contents 
of this message which arise as a result of e-mail transmission.  If 
verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities or 
related financial instruments.

On Wed, 5 Sep 2001, Darren Moffat wrote:
> >Neither the Sun PAM documentation nor the Linux-PAM documentation
> >describe the semantics of PAM_REINITIALIZE_CREDS in any useful detail.
> I would agree it is vague, but then that is also a problem with the XSSO
> document (http://www.opengroup.org/onlinepubs/008329799/)
> >Could we please have a clarification on the semantics of
> >PAM_CRED_ESTABLISH vs. the semantics of PAM_REINITIALIZE_CREDS?
> My interpretation is:
> You call PAM_ESTABLISH_CRED to create them
> You call PAM_REINITIALIZE_CRED to update creds that can expire over time,
> for example a kerberos ticket.
Coming at this purely from a literalist POV, the terminology
'REINITIALIZE_CRED' implies to me that the credentials will be returned
to an
/initial/ state, i.e., this is somehow analogous to calling
setcred(PAM_DELETE_CRED) followed by setcred(PAM_ESTABLISH_CRED).

Practically speaking, I don't see where anything further than ESTABLISH,
REFRESH, and DELETE is required; either REINITIALIZE is equivalent to one of
the first three, in which case it should be deprecated to reduce confusion, or
it has a meaning outside of the first three, in which case it should be
clearly determined what that meaning is before people try to make use of it in
code.
> >My guess, given what OpenSSH does with PAM: PAM_CRED_ESTABLISH means
> >"make it so we can use your module's credentials as root"
whereas
> >PAM_REINITIALIZE_CREDS means "make it so we can use your
module's
> >credentials as pam_get_item(PAM_USER)."
> That is wrong and is one thing the XSSO doc is clear on:
> "The pam_setcred() function is used to establish, modify, or delete
the
> credentials of the current user associated with the authentication handle,
> pamh. "
Agreed; it's counter-intuitive that a simple application which needs the
credentials for only a short period of time should need to do anything more
than setcred(ESTABLISH) at the beginning and setcred(DELETE) when the
credentials are no longer needed.
> >But none of this is documented!
> Agreed the docs do not specify the level of privilege required by
> the application for calling pam_* functions.
> In someways I think it should be upto the modules to document what they
> need but I also think this could break the abstraction that PAM is supposed
> to provide.
I think it's important for abstraction that this be specified.  This lack of
specification has more than once caused problems for both module writers and
application writers.
> It will always create a cred cache file owned by PAM_USER, the only
> way you could get the effect you describe above is if you called
> pam_setcred with PAM_USER as root, changed PAM_USER using pam_set_item
> to be <user> - but this isn't what OpenSSH does (and it is wrong
anyway).
Does Solaris pam_krb5 fail gracefully if the calling application cannot
setuid(PAM_USER)?  As Nico rightly points out, PAM is not unique to
applications that establish local Unix security contexts as the given user.

Steve Langasek
postmodern programmer