| Subject: | qualify_shortname default can be harmful in LAN setups |
| Date: | Thu, 09 Jul 2020 16:31:04 -0400 |
| From: | ghudson@mit.edu |
| To: | rt@krbdev.mit.edu |
https://bugzilla.redhat.com/show_bug.cgi?id=1852041 describes a regression when Fedora changed the default of dns_canonicalize_hostname from "true" to "fallback" in their 1.18 package. The user has a LAN setup using single-component hostnames resolved via /etc/hosts (with no presence in the DNS), and has set rdns=false. This setup worked with dns_canonicalize_hostname=true because we don't qualify DNS-canonicalized results, but with dns_canonicalize_hostname=fallback, the single-component hostnames were qualified with the DNS search domain, which was some useless domain supplied by the ISP during DHCP. This caused sshd to stop accepting tickets.
This is an immediate issue for Red Hat, and a time bomb for upstream as we are slated to change the dns_canonicalize_hostname default to "fallback" in 1.19. Red Hat's response so far has been to change the qualify_shortname default to "", but I think this change alone will cause problems in different setups. For instance, https://mailman.mit.edu/pipermail/kerberos/2017-October/021816.html describe's a user experiencing a kprop failure after setting dns_canonicalize_hostname=false.
Whatever we do needs to account for the following use cases for krb5_sname_to_principal():
* TGS request service names (the most prominent use case, and the one we paid the most attention to when implementing dns_canonicalize_hostname=fallback). For this use case qualify_shortname is mostly a user convenience, perhaps not a necessity.
* Acceptor names for server applications. Probably the most common scenario is when the application calls gethostname() and then imports servicename+"@"+hostname (e.g. "host@small-gods" for sshd on my machine). Here we want the local FQDN, but don't specifically know that, and we probably received only the local hostname without domain. (Applications can get better behavior by importing just the service name, which causes the hostname part to be wildcarded, but I don't think many server application code bases have gotten that message.)
* Non-GSS applications using a keytab to authenticate using a service principal name as the client. Within the tree, this case includes kprop, kpropd when acting as an iprop client, kadmin -k (with no -p option), and kinit -k (with no principal name argument).
* ksu looks for a ticket to {sn2princ with "host" and null hostname} as an alternative to a TGT, although this may currently be broken (see ticket 8619).
* KDB creation, where we create kadmin/hostname and kiprop/hostname principals. There is a certain amount of slack here if this goes wrong; kadmin will fall back to kadmin/admin, and the administrator can simply create the kiprop principal for the master KDC when they create ones for the replicas (as they had to do before ticket 7979).
This is an immediate issue for Red Hat, and a time bomb for upstream as we are slated to change the dns_canonicalize_hostname default to "fallback" in 1.19. Red Hat's response so far has been to change the qualify_shortname default to "", but I think this change alone will cause problems in different setups. For instance, https://mailman.mit.edu/pipermail/kerberos/2017-October/021816.html describe's a user experiencing a kprop failure after setting dns_canonicalize_hostname=false.
Whatever we do needs to account for the following use cases for krb5_sname_to_principal():
* TGS request service names (the most prominent use case, and the one we paid the most attention to when implementing dns_canonicalize_hostname=fallback). For this use case qualify_shortname is mostly a user convenience, perhaps not a necessity.
* Acceptor names for server applications. Probably the most common scenario is when the application calls gethostname() and then imports servicename+"@"+hostname (e.g. "host@small-gods" for sshd on my machine). Here we want the local FQDN, but don't specifically know that, and we probably received only the local hostname without domain. (Applications can get better behavior by importing just the service name, which causes the hostname part to be wildcarded, but I don't think many server application code bases have gotten that message.)
* Non-GSS applications using a keytab to authenticate using a service principal name as the client. Within the tree, this case includes kprop, kpropd when acting as an iprop client, kadmin -k (with no -p option), and kinit -k (with no principal name argument).
* ksu looks for a ticket to {sn2princ with "host" and null hostname} as an alternative to a TGT, although this may currently be broken (see ticket 8619).
* KDB creation, where we create kadmin/hostname and kiprop/hostname principals. There is a certain amount of slack here if this goes wrong; kadmin will fall back to kadmin/admin, and the administrator can simply create the kiprop principal for the master KDC when they create ones for the replicas (as they had to do before ticket 7979).