reinit_creds (was Re: OpenSSHd barfs upon reauthentication: PAM, Solaris 8)

[Nicolas Williams]

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.