[OpenAFS-devel] Re: [kerberos-discuss] Solaris 10 SSHD, pam_krb5 and xscreensaver
handling of renewed/forwarded ticket
Douglas E. Engert
deengert@anl.gov
Thu, 08 Nov 2007 10:30:24 -0600
Thanks for the response, and so some of my comments below. I am cc'ing
openafs-devel because the way you are using the cache has consequences
for the AFS aklog, as the AFS token is sensitive to the lifetime of the
ticket. and AFS has traditionally used session based credentials, and PAGs.
Shawn M Emery wrote:
> Doug,
>
> Comments in-line:
>
> Douglas E. Engert wrote:
>> 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.
>
> Other krb apps such as ftp, telnet, etc., all overwrite the ccache with
> the delegated credentials regardless if they had already expired or
> not. I agree, we need to be consistent here. How the cache is
> overwritten could be debatable:
>
> 1. Reinit w/only default creds
> Advantage: reduce client load, in regards to enumeration of cache
> Disadvantage: increase network and KDC interaction
> the more logins w/delegation the less efficient
For the current AFS aklog (and any other Kerberos application that
is sensitive to the end time of the ticket) if aklog is run it
may find the previous ticket which may be about to expire. So every
application needs to be looked at, as all traditional applications
have assumed that if the TGT was updated, the rest of the tickets would
be deleted, and new ones would be obtained.
> 2. Rewrite non-default creds
> Advantage: important for high latency networks
Advantage for aklog is it will have to get anew ticket, good
for the lifetime of the new TGT.
> Disadvantage: increase client load
>
With your Advantages/Disadvantages above, you are making assumptions
that vary from site to site and imposing restriction with your current
method of updating the cache. At least consider that maybe a site
might want to accept the increased load if there are other advantages
for the user.
> In any case I've filed a bug on sshd for the delegation issue:
> 6627262 Delegating credentials in ssh should update creds even when
> remote copy is not expired
Thanks.
>
> More comments on the second problem below...
>
>> /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.
>
> The sessions are still valid after the ticket has expired.
>
>>
>> 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
>
> No, actually RPC/RPCSEC_GSS is fairly smart compared to the behavior
> that you describe for AFS. RPC/RPCSEC_GSS will refresh credentials if a
> permission error is at first returned.
So AFS might need the equivelent of the gssd to renew and refresh tokens
or at least aklog might need a flag to always request a new ticket.
(There must be someting lilke this out there, as this is the same problem
that long running cron jobs have...)
>
> More comments below...
>> 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.
>
> I currently have the following CR for pam_krb5, which revisits how
> credentials are handled for applications such as xscreensaver:
>
> 6455225 pam_krb5 should overwrite ccache with new TGT when handling
> pam_setcred (PAM_REFRESH_CRED)
Good. Its the inconsistency of the way the cache is handled that
is a problem.
>
> As I outlined the disadvantages and advantages above, I believe that
> there are more advantages of rewriting non-default credentials than
> reinitializing the cache. The current fix that I have also does not
> rewrite expired non-default creds. Applications should and are smart
> enough to re-fetch non-default creds if they have expired, after all
> after a reinit they would have to re-fetch anyway.
>
The one issue you have not addressed is the use of session based cache
vs using the default uid cache for everything. I am assuming because the
gssd/kernel is expecting only one principal per uid and the cache
is in a file. This is very restrictive.
Other systems can use keyrings or keychains. Even DCE could use session
based credentials:(something like) /opt/declocal/var/security/creds/krb5cc_<number>
where the number was stored in the kernel ucred (Actually it was the same
as an AFS PAG number, as AFS and DFS came from Transarc/IBM.)
Even Windows has the runas command which can use other credentials!
So please consider how you would address the use of multiple credentials
across multiple sessions using the same uid.
> Shawn.
> --
>
>
--
Douglas E. Engert <DEEngert@anl.gov>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444