Obtaining a TGT without unrestricted access to password.

[David Woodhouse]

On Thu, 2011-06-16 at 08:44 +0200, Guido Günther wrote:
> I'm not sure if this is what David wants to achieve but if so couldn't
> we just move the auth part of krb5-auth-dialog into gkr keeping the
> notification parts and plugins of krb5-auth-dialog separate? We could
> then use krb5_get_init_creds_password with our own prompter and use
> the password if available. 

That is our backup plan, but I share Stef's reticence. We really do want
gnome-keyring to stick to what it does best, and not start getting
involved in remote network operations.

I certainly don't think we'd ever actually do it *in* the gnome-keyring
process. As well-trusted as libkrb5 may be, we just don't want *any*
network code running in the gkr process. Instead, we'd give the password
(or preprocessed password-as-key) out to a separate process. It would
probably be best to do that by spawning a helper that we *know* will
just do what it's supposed to be doing, rather than handing it out on
demand to some existing process that asks for it, and having to invent
some trust model to give us confidence in that.

But really, we don't want to be doing that at all. We *really* want to
use gkr *only* for the crypto operations using the password, invoked
from the appropriate places in libkrb5.

Using a "special" key as in my third approach *ought* to be feasible.
After all, surely a krb5_keyblock can represent a key that is present in
a hardware device and thus has the same restrictions — you can ask for
operations to be performed using it, but you can't just ask for the key?

-- 
dwmw2