[Dovecot] GSSAPI cross-realm fixed
Attached is a patch which in my environment (Linux/Heimdal 1.2.1) fixes cross-realm GSSAPI authentication.
Changes it makes: this doesn't appear to be always the case for the authz_name.
- When using krb5_kuserok, do not call gss_compare_name to check that authn_name and authz_name are the same. Instead, make TWO calls to krb5_kuserok, one for each ID. If both IDs are acceptable, allow the login.
- Disable checking that the name is a GSS_KRB5_PRINCIPAL_NAME, as
If I create a .k5login listing both username@REALM1 and username@REALM2, and make that file follow the appropriate security restrictions (world read, user only write permissions), this lets me use GSSAPI logins with principals from either REALM1 or REALM2.
This leaves untouched the behavior in the case where krb5_kuserok is not available.
Bryan Jacobs
On Tue, 2009-03-03 at 13:56 -0500, Bryan Jacobs wrote:
Changes it makes:
- When using krb5_kuserok, do not call gss_compare_name to check that authn_name and authz_name are the same. Instead, make TWO calls to krb5_kuserok, one for each ID. If both IDs are acceptable, allow the login.
Sounds good.
- Disable checking that the name is a GSS_KRB5_PRINCIPAL_NAME, as this doesn't appear to be always the case for the authz_name.
Is there any downside to this check? Can something bad happen if it's not a principal name? I left the check there now for authn_name.
Committed: http://hg.dovecot.org/dovecot-1.2/rev/ff6378d7b209
And then I noticed that the last equal_authn_authz check most likely shouldn't have been changed, so reversed it:
On Tue, 2009-03-03 at 13:56 -0500, Bryan Jacobs wrote:
Attached is a patch which in my environment (Linux/Heimdal 1.2.1) fixes cross-realm GSSAPI authentication.
Changes it makes:
- When using krb5_kuserok, do not call gss_compare_name to check that authn_name and authz_name are the same. Instead, make TWO calls to krb5_kuserok, one for each ID. If both IDs are acceptable, allow the login.
I'm just wondering. Is the authz_name check really necessary? Simplified, the code is basically:
krb5_parse_name(ctx, username, &princ); ok = krb5_kuserok(ctx, princ, username);
Are there really situations where the above code produces ok=FALSE?
Also do you have any ideas why after your patch it fails here: http://dovecot.org/list/dovecot/2009-June/040672.html
Maybe instead of always using krb5_userok() it's used only when authn_name != authz_name?
On Tue, 07 Jul 2009 20:27:57 -0400 Timo Sirainen <tss@iki.fi> wrote:
On Tue, 2009-03-03 at 13:56 -0500, Bryan Jacobs wrote:
Attached is a patch which in my environment (Linux/Heimdal 1.2.1) fixes cross-realm GSSAPI authentication.
Changes it makes: that authn_name and authz_name are the same. Instead, make TWO
- When using krb5_kuserok, do not call gss_compare_name to check
calls to krb5_kuserok, one for each ID. If both IDs are acceptable, allow the login.
I'm just wondering. Is the authz_name check really necessary? Simplified, the code is basically:
krb5_parse_name(ctx, username, &princ); ok = krb5_kuserok(ctx, princ, username);
Are there really situations where the above code produces ok=FALSE?
Also do you have any ideas why after your patch it fails here: http://dovecot.org/list/dovecot/2009-June/040672.html
Maybe instead of always using krb5_userok() it's used only when authn_name != authz_name?
I haven't looked at the source code of krb5_kuserok so I can't say for sure. The issue is that one user can AUTHeNticate and then request AUTHoriZation for a different mailbox (as in, foo@bar.com could be OK for the mailbox foo@baz.com). Your idea of using krb5_kuserok when authn_name != authz_name sounds very good to me - a principal should always be allowed to act in its own name. Perhaps lha should be consulted first, though.
I don't know why the case you cite fails - they ARE using MIT Kerberos (Heimdal klist output looks different from what they pasted), so it could be that krb5_kuserok functions differently there.
Bryan Jacobs
participants (2)
-
Bryan Jacobs
-
Timo Sirainen