bug: krb5_get_host_realm() no longer uses DNS

Nicolas Williams Nicolas.Williams at oracle.com
Wed May 19 18:20:47 EDT 2010


On Wed, May 19, 2010 at 05:58:41PM -0400, Greg Hudson wrote:
> The design of referrals support assumes that referrals from the local
> realm are less reliable than explicit local configuration, and more
> reliable than DNS-based or heuristic mechanisms.  Per that design, the
> following changes are intentional:
> 
> * krb5_get_host_realm() returns the referral (empty) realm if there is
> no explicit local configuration.

This _could_ look in the keytab...  If there's keys for the hostname in
one realm, that must be it (or if there's keys for the thing in multiple
realms, then pick the first, or last).  It could also use validate the
keytab entries found by attempting to get a TGT.  This would only work
for privileged apps or unpriv apps with keytabs, but there could be a
service whose job it is to record the host's realm in /var/run where
unpriv apps could get at it.

> * krb5_sname_to_principal() uses the referral realm if there is no
> explicit location configuration for the host.

Note that this implicitly uses a ccache.  This is annoying.  It'd be
nice if there was a way to explicitly pass in a credential (TGT) or,
rather, ccache to use for canonicalization.  (The same applies to
gss_canonicalize_name(); we really need gss_canonicalize_name_with_cred()
and the krb5 API equivalent, possibly as a function to set the default
cred/ccache in a krb5_context to use for operations that use an implied
cred/ccache).

> > To be clear: I have thousands of hosts in a single DNS domain, which
> > are in varying realms.  I do not have the option of renaming all the
> > hosts to align with their realm membership, and static configuration
> > is impractical; the DNS is necessary.
> 
> You appear to know your options reasonably well; for what it's worth, I
> would recommend either:
> 
> 1. Setting GSSAPIStrictAcceptorCheck false on your servers, and not
> worrying too much about the potential for a client to use the "wrong"
> service to authenticate to sshd.

+1.  It's not likely that you'll have multiple sshd services running
where the name of the service is security significant to the client such
that the client could be misled to connect to the wrong one.  Though,
technically speaking, misdirection is a potential problem resulting from
not checking that the acceptor principal matches the expected name.

> 2. Configuring each server to know what realm it's in (via the default
> realm setting in krb5.conf).  Based on your statements, this is more
> configuration complexity than you want in your environment, but it's
> more secure than having your servers perform a spoofable DNS TXT query
> to find out where the live.

+1.  One could certainly write a boot script that determines the realm
and updates krb5.conf at boot time...

Nico
-- 



More information about the Kerberos mailing list