gnome-keyring Obtaining a TGT without unrestricted access to password.

[David Woodhouse <dwmw2 infradead org>]

I'm trying to implement automatic renewal of Kerberos tickets during the
lifetime of a user's session.

The user's password is learned at login time and stored within the
gnome-keyring dæmon.

We also have krb5-auth-dialog running in the background, which will
prompt the user for a password when the TGT needs to be renewed.

You'd think it would be simple to make the latter use the password
that's been stored by the former...  I wish it were so.

The problem is that we don't want the keyring process to actually give
*out* the password. It's happy to perform operations for us *using* the
password, but not just to *give* it to us.

I have three ideas, and I'm not sure how viable any of them are. I'd
very much appreciate some pointers...


My first approach was to look at using plugins. For example, we'd have a
preauth plugin to handle KRB5_PADATA_ENC_TIMESTAMP which would farm it
off to gnome-keyring to perform the actual operation. But that seems to
have failed at the first hurdle because in krb5_do_preauth() we
unconditionally try the built-in handlers *first*, before trying the
modules. And if those match the patype and fail, the module doesn't even
get a look in.


My second thought was that perhaps the keyring could be asked for the
result of str2key on the password. That's not the actual *password*, at
least. But I suspect that even that is still too sensitive to be handing
it out?


The third thought is that I could call krb5int_get_init_creds() with a
get_as_key function that returns a "special" key, where the actual
methods on it are just PKCS#11 calls to the keyring to do the job.
It's complicated by the fact that the method pointers aren't in the
krb5_keyblock but are actually looked up at invocation time with
find_enctype(). But there may be a way to make this work, perhaps?


Any better ideas, or suggestions for which option to pursue?

-- 
dwmw2