[39458] in Kerberos
Re: Why do "strict acceptor checking"?
daemon@ATHENA.MIT.EDU (Jeffrey Hutzelman)
Tue Oct 8 13:21:43 2024
MIME-Version: 1.0
In-Reply-To: <202410081605.498G5TLq018593@hedwig.cmf.nrl.navy.mil>
From: Jeffrey Hutzelman <jhutz@cmu.edu>
Date: Tue, 8 Oct 2024 13:20:11 -0400
Message-ID: <CALF+FNzt7ZL_e0o=xLSCjjRX7Vwi7-1EqTro2XhU+sg+0Tm6iQ@mail.gmail.com>
To: Ken Hornstein <kenh@cmf.nrl.navy.mil>
Cc: Simo Sorce <simo@redhat.com>,
Jonathan Calmels via Kerberos <kerberos@mit.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
On Tue, Oct 8, 2024, 12:06 Ken Hornstein via Kerberos <kerberos@mit.edu>
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 Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
