I have been looking at how sshd and xscreensaver (via pam_krb5) store
credentials and have identified what I consider to be two design problems.
We have been circumventing these for sshd at least since Solaris 10 came out by
using a session based cache and a local pam_krb5_ccache that sets KRB5CCNAME.
I would like to see if we can retire this local pam routine, and
also be compatible with NFSv4.
These problems show up as the endtime of a ticket is reached.
SSHD DOES NOT STORE TGT IF CACHE HAS UNEXPIRED TGT.
Looking at Opensolaris source:
/onnv/onnv-gate/usr/src/cmd/ssh/sshd/gss-serv.c
299 if (authctxt->pw->pw_uid != geteuid()) {
300 temporarily_use_uid(authctxt->pw);
301 ctx->major = gss_store_cred(&ctx->minor,
ctx->deleg_creds,
302 GSS_C_INITIATE, GSS_C_NULL_OID, 0,
303 ctx->default_creds, NULL, NULL);
304 restore_uid();
This passed in the overwrite_cred = 0, to not overwrite an existing cred.
/onnv/onnv-gate/usr/src/lib/gss_mechs/mech_krb5/mech/store_cred.c
185 /*
186 * Handle overwrite_cred option. If overwrite_cred == FALSE
187 * then we must be careful not to overwrite an existing
188 * unexpired credential.
But does not take into account, that the user may be making a new connection
just to get the cred updated! You don't want to wait till it expires...
189 */
190 maj2 = krb5_gss_acquire_cred(&min,
191 (default_cred) ? GSS_C_NO_NAME : in_name,
192 0, desired_mechs, cred_usage,
193 (gss_cred_id_t *)&cur_cred, NULL,
&cur_time_rec);
194
Gets time remaining from existing TGT if any.
195 if (GSS_ERROR(maj2))
196 overwrite_cred = 1; /* nothing to overwrite */
No cache with this name, pam_krb5_ccache takes advantage of this by
pointing sshd at a non existing cache each time...
197
198 if (cur_time_rec > 0 && !overwrite_cred) {
Will not overwrite a cred, even if it only has 1 sec left till it expires!!
199 maj = GSS_S_DUPLICATE_ELEMENT; /* would overwrite */
200 goto cleanup;
201 }
Comments at lines 36-58 go into some discussion about updating the TGT but not
other creds, which is what xscreensaver via pam_krb5 does, but even that
approach
has problems too...
ONLY TGT IS UPDATED IN CACHE
If a TGT is stored into the cache, older tickets are not changed.
xscreensaver via pam_krb5 appears to work like this.
This can lead to an application like ssh or aklog using an an unexpired,
but old ticket that may expire very soon. This really makes a difference
if the endtime in the service ticket is used by the service as an endtime to
discontinue the service.
ssh/sshd does not use the endtime to control the session,(as best as I can
tell) so the ticket has to be valid only to make the connection, not be
valid during the full life of the session.
AFS *DOES* use the endtime and authenticated access to AFS is cut off when
the endtime is reached.
NFSv4 and the gssd? - I have no idea, if the gssd will renew tickets
if they are about to expire, or if NFSv4 uses the endtime at all or
if the client looks at the endtime and tries to renew or use the TGT
to get a new service ticket.
Renewing ticket would have the same problem, just extended a week...
So I think Sun needs to look over what they are trying to do here. They have
taken an approach to the use of Kerberos tickets that is out of the norm,
and have thus introduced some additional problems.
The SSHD needs a way to update the TGT. Either implement what lines 36-58
suggest,
or treat this like a kinit, and clean out the cache and add the new TGT. Or use
some
logic like the new TGT is "better" then the old TGT, so rplace it.
If Sun is willing to only update the TGT and leave all the other older tickets,
which is not in the Kerberos tradition,(but is allowed), there needs to be a
way to get endtime critical tickets updated for an aplication, or the
application
needs to update the. In any case they need a good TGT.
(I am going to look at aklog, and see if it can look at the TGT and ignore
any existing ticket, so it will always get a long lasting token.)
ktkt_warnd might be able to do something here too, but thats not clear.
Attached is a log of some session today between my workstation orleans,
a test machine osiris without the pam_krb5_ccache, and using the uid based cache
and a third machine atalanta. All are Solaris 10. The log shows how
the cache still hav ethe original TGT from the first login, even though
I have done a number of ssh connections to it. The afs and gssklog tickets
are also based on endtime of the early TGT. Only if I was willing to do a kinit
(which defeats the SSO) on osiris, could I get the cache cleared out, and a
new TGT added.
So for now we will continue to use our pam_krb5_ccache gets a new cache for
each ssh session, and an AFS PAG and token, and worry about NFSv4 and Kerberos
for some other day.
--
Douglas E. Engert <DEEngert at anl.gov>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: sun.tickets
URL:
<http://mail.opensolaris.org/pipermail/kerberos-discuss/attachments/20071106/93461fe4/attachment.ksh>
