Re: gnome-keyring Using gkr for Kerberos/NTLM single-sign-on handling

[Stef Walter <stefw collabora co uk>]

It seems like we're vigorously in agreement :)

On 04/28/2011 11:35 AM, David Woodhouse wrote:
> On Thu, 2011-04-28 at 09:20 +0200, Stef Walter wrote:
>> The only piece that hasn't really be considered is the interaction with
>> the user's unix login password, more specifically using it as a default
>> to log into remote services (like Kerberos).
>>
>> I don't think that gnome-keyring-daemon should hand out the user's login
>> password like candy to whatever application requests it (eg: this would
>> break sudo).
> 
> I wouldn't say that wasn't considered. Quite the opposite, in fact —
> that consideration is *fundamental* to what we're trying to do.

Yes for sure. I meant: "not yet considered by the ddl online accounts
discussion and David's work".

> The whole *point* in my proposal was that we don't *want* gkr just
> handing out the password.

Absolutely agree. I was thinking out loud. Of course you've thought
about that :)

> If we were prepared to tolerate that, then life would be simple. Modify
> krb5-auth-dialog to ask for the password from gkr, and all the random
> imap/smtp/http/im/etc applications that want to authenticate with NTLM
> can just ask for the password too.
> 
> But we don't *want* gkr giving out the password like candy.

Roger.

> For NTLM, it is the /usr/bin/ntlm_auth helper application that was
> traditionally provided by Samba/winbind. It handles the NTLM
> challenge/response, and the application simply proxies the base64
> messages back and forth between ntlm_auth and the network server.
> http://mxr.mozilla.org/mozilla/source/extensions/auth/nsAuthSambaNTLM.cpp
> 
> We'd be providing an implementation of /usr/bin/ntlm_auth which talks to
> gkr instead of talking to Samba/winbind. In Chris' repository you'll
> find such a tool, which talks to his cut-down dæmon over the UNIX
> socket. That could be changed to use DBus, of course.

Interesting. Obviously I need to look at this closer.

> For Kerberos, the existing API is simply that a valid TGT shall be
> present in the file /tmp/krb5cc_$UID. We just need to keep track of when
> it expires, and either refresh or renew it as appropriate.
> 
> (Strictly speaking, the API that *applications* use is libgssapi, and
> the above paragraph is a description of what *that* expects. But unless
> we're planning to modify the Kerberos libraries to behave differently, I
> suspect that's the interesting part...)

Right.

> For Kerberos, if it is *just* a client-driven "challenge" that triggers
> gkr to refresh the Kerberos ticket, that seems somewhat suboptimal.
> You're talking about having a *separate* dæmon that runs and does
> nothing but sleep until it's time to renew the TGT, then prods gkr to do
> so. Couldn't gkr just do it for itself?

It certainly could. I'd be more in favor of an approach where
gnome-keyring launches a process so that the network communication
doesn't happen in the same process that does password and key storage.
But perhaps gnome-keyring-daemon could launch such a process as needed,
so no biggie there.

The thing that bothers me (and I'm not saying this is necessarily a show
stopper) is that Gnome Keyring is a key and password store. It provides
access to those secrets in various ways. But it hasn't really done any
actual interacting with the user's off machine accounts (whether
Kerberos, Google or what have you).

So before adding this into the daemon, I'd like to see whether the
configuration and ticket renewal parts of it fit better into the new
online accounts system David is working on.

 * The online accounts system also has a daemon.
 * Has logic for expired tokens/tickets, renewal, etc.

David, what do you think? I got the impression that the online accounts
work for more than just web accounts. Is that right?

> On the other hand, perhaps that *does* give us an error handling
> capability; if we do it as a request that's just *triggered* by
> something like krb5-auth-dialog, then krb5-auth-dialog can handle the
> error case where the network password has changed — presumably by
> prompting us for a new password and trying again, then changing the
> local password to match.
> 
> (I suppose that last bit would be "asking gkr to change the local
> password to match", given that krb5-auth-dialog doesn't *know* the old
> password so can't change it...)

Yes that does sound like another good approach.

> We do also want to optionally support a mode of operation where the
> network password is *different* from the local login password, but is
> still 'write-only' in gkr and not handed out like candy.

In order to this I guess we would need ACLs (again) in gnome-keyring.
I've been giving this some thought. It's tough to get it 'perfect', but
this time around (following the example of things like policy-kit) we
may be able to do it well enough.

Cheers,

Stef