bin/57470: su hangs on network access via pam_ksu even if it will never succeed

[campbell+netbsd%mumble.net@localhost]

>Number:         57470
>Category:       bin
>Synopsis:       su hangs on network access via pam_ksu even if it will never succeed
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    bin-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Jun 15 13:45:00 +0000 2023
>Originator:     Taylor R Campbell
>Release:        netbsd-9
>Organization:
The KnetBSD Foundation
>Environment:
>Description:
/etc/pam.d/su has pam_ksu enabled by default.

If ~/.krb5/config exists (in the home directory of the user running su, not the user they're switching to), or if /etc/krb5.conf exists, then pam_ksu will get past krb5_init_context.

If there's no /root/.k5login or if the host has no keytab, pam_ksu will never succeed, because it uses krb5_verify_init_creds with the ap_req_nofail option.

But it doesn't discover this until it has done two other things first:

1. Find a default realm.  If it's not specified in the krb5 config, this will happen by default through DNS lookup of _kerberos TXT records based on the system hostname.
2. Find a KDC for the realm.  If it's not specified in the krb5 config, this will happen by default through DNS lookup of _kerberos._tcp/_udp SRV records based on the realm.

I don't think there's any security vulnerability here, or much of a privacy leak, because the next thing it will do is discover that /root/.k5login doesn't exist, and as long as the user's name isn't already root, that puts an end to it.
>How-To-Repeat:
turn off the network

$ touch ~/.krb5/config
$ su
>Fix:
Yes, please!

pam_ksu should:

1. check for /root/.k5login early -- if it's not there, fail
2. check for any keytab early -- if there's no keytab, fail

That way, it is safe to create ~/.krb5/config or /etc/krb5.conf without causing weird unrelated things to fail.