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 <[EMAIL PROTECTED]>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
_______________________________________________
OpenAFS-devel mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-devel
