On Tue, Oct 8, 2024, 12:06 Ken Hornstein via Kerberos <[email protected]> wrote:
> >> I'm completely with you, but clearly plenty of application writers do > not > >> agree with this sentiment! So I'm wondering what I am missing. > > > >There *are* weird cases where the keytab needs to contain multiple keys > >for different principals, but you want to use only one of them for > >*accepting* connections. > > > >These days you can easily have separate keytabs for "client" vs > >"server" keys and programmatically specify which keytab you want via > >gss_acquire_cred_from(), but it hasn't always been like that. In the > >past in some cases your only option was to use a fixed specific file on > >the filesystem not even env vars... > > I'm certainly kind of a grizzled old Kerberos user at this point and > I'm willing to believe that these weird corner cases exist, but part of > me wonders out loud how this attitude got proliferated to so many > applications. Also, I guess I find it personally frustating that a > practice that has caused me a ton of pain over a few decades is justified > by what I would charitably classify as "vague hand-waving". > Me too. We've been recommending calling gss_accept_sec_context with GSS_C_NO_CREDENTIAL for a long time, and almost no one does that. it's very annoying. RFC4752 recommends that SASL implementations use a credential acquired for GSS_C_NO_NAME, which is usually equivalent. It also recommends verifying, after accepting a context, that the service principal used is of the expected type. This mitigates the potential issues if keys for another application are in the same keytab. But, fine, let's talk about a specific example. In the case of sudo, > the local hostname is used to build a "host" principal and passed in as > the server argument to krb5_verify_init_creds(). If you pass in NULL > instead to the server argument, krb5_verify_init_creds() will try > every "host" principal in the local keytab until one succeeds. AFAIK, that's a relatively recent feature in the grand scheme of things. So, software that validates passwords has a reasonably good excuse for assuming that host/$hostname is a valid service principal to use for that purpose and that its key will be readily available. We have sudo configured to use PAM, and use Russ's pam_krb5, which handles this (and has some features we use to support use of /root principals for sudo). Unfortunately, the Cyrus SASL library does not support non-strict mode. That has unfortunate implications for LDAP, IMAP, and SMTP. We developed and submitted a patch for that quite a number of years ago, but it doesn't seem to have gone anywhere. Given > this is just to verify a Kerberos password, I am trying to come up with > any kind of scenario where the default behavior of krb5_verify_init_creds() > would cause a security problem. If there IS no such scenario, I'm > going to try to submit a patch upstream to change this behavior. > well, the keytab could contain a copy of a key that is known to other services or to some user. even a principal intended to be used only as a client could be an issue, if an attacker knows the key and can print valid tickets. So, maybe an option rather than a change to a different non-configurable behavior. If I remember right, the structure of sudo makes adding a new option a little annoying but not actually difficult. -- Jeff > ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
