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

>> >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.
Oops.  I meant PAM_REFRESH_CRED
>PAM_RENEW_CREDS is there for credential renewal (i.e., ticket renewal,
>in the Kerberos case). That's clear from its name.
It is called PAM_REFRESH_CRED.
>PAM_REINITIALIZE_CREDS is, well, completely undocumented (I'll recheck
>the XSSO docs). The OpenSSH interpretation is clear.
Agreed and it is very ambiquous.  I think it is quite easy to make
the assumption that ESTABLISH and REINITIALIZE care synonymous but both
are different from REFRESH.
>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?
I can see that from a PAM view point but it won't really work from
a Kerberos view point (it isn't how kerberos was designed to work).
>> "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.
I guess it does at the PAM level but at the level of Kerberos the creds
are always placed in a cred file owned by that user since their is no
concept of acting onbehalf of another.
>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).
The Solaris one does that as well, the ccache file is created as
	/tmp/krb5cc_<uid> with permissions 600 and owner <uid>
>> 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??
Because you are supposed to call pam functions in this order:

pam_start(pamh,...);
pam_authenticate(pamh, ...);
pam_acct_mgmt(pamh, 
pam_setcred(pamh, PAM_ESTABLISH_CRED)
...
pam_setcred(pamh, PAM_DELETE_CRED);
pam_end(pamh);


This is quite clear from the Solaris man page for pam_setcred(3pam)

"    The pam_setcred() function is used to establish, modify,  or
     delete  user  credentials.  It is typically called after the
     user has been authenticated and after  a  session  has  been
     opened.   See  pam_authenticate(3PAM),  pam_acct_mgmt(3PAM),
     and pam_open_session(3PAM).
"     

>In fact, it seems clear to me that no user-owned ccache should be
>created outside pam_krb5:pam_sm_setcred().
In Solaris it isn't.
>> 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.
I don't believe that is well defined for Kerberos and it isn't how
pam_krb5 in Solaris is designed to work.

--
Darren J Moffat

On Wed, Sep 05, 2001 at 02:03:23PM -0700, Darren Moffat
wrote:
> >> >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.
> 
> Oops.  I meant PAM_REFRESH_CRED
> 
> >PAM_RENEW_CREDS is there for credential renewal (i.e., ticket renewal,
> >in the Kerberos case). That's clear from its name.
> 
> It is called PAM_REFRESH_CRED.
Yes, sorry.
> >PAM_REINITIALIZE_CREDS is, well, completely undocumented (I'll
recheck
> >the XSSO docs). The OpenSSH interpretation is clear.
> 
> Agreed and it is very ambiquous.  I think it is quite easy to make
> the assumption that ESTABLISH and REINITIALIZE care synonymous but both
> are different from REFRESH.
Again, Sun treats REINITIALIZE as a synonym of REFRESH.
> >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?
> 
> I can see that from a PAM view point but it won't really work from
> a Kerberos view point (it isn't how kerberos was designed to work).
Sure it can work from the Kerberos pov.

Like this: take an app that doesn't fork, but which authenticates
multiple users, and does not "become" them, and which impersonates
each
of those users, at times, using the per-user ccache -- as long as the
app can read each per-user ccache and as long as it keeps track of whose
is whose it can do this.


> >> "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.
> 
> I guess it does at the PAM level but at the level of Kerberos the creds
> are always placed in a cred file owned by that user since their is no
> concept of acting onbehalf of another.
Wrong. See above. Applications can impersonate Kerberos principals,
provided they have the creds for those principals.
> >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).
> 
> The Solaris one does that as well, the ccache file is created as
> 	/tmp/krb5cc_<uid> with permissions 600 and owner <uid>
I'll double check.
> >> 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??
> 
> Because you are supposed to call pam functions in this order:
> 
> pam_start(pamh,...);
> pam_authenticate(pamh, ...);
> pam_acct_mgmt(pamh, 
> pam_setcred(pamh, PAM_ESTABLISH_CRED)
> ...
> pam_setcred(pamh, PAM_DELETE_CRED);
> pam_end(pamh);
Clearly -- no disagreement there. I'm asking why create the user-owned
ccache in pam_authenticate() (which is what you said Sun's pam_krb5
does).
> >In fact, it seems clear to me that no user-owned ccache should be
> >created outside pam_krb5:pam_sm_setcred().
> 
> In Solaris it isn't.
You seem to be mis-interpreting the man page bit you quoted --
pam_krb5:pam_sm_authenticate() should not create the file ccache (an
internal memory ccache is needed though to communicate the creds to the
pam_krb5:pam_sm_setcred() function (via pam data)).
> >> 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.
> 
> I don't believe that is well defined for Kerberos and it isn't how
> pam_krb5 in Solaris is designed to work.
Sure it is. An app can use multiple ccaches and creds no problem. As
long as it keeps them straight.
> --
> 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.