Proposal: Disable pam_ksu, pam_krb5 by default

[Taylor R Campbell <campbell+netbsd-tech-security%mumble.net@localhost>]

I propose to disable pam_ksu and pam_krb5 by default in /etc/pam.d.

Having them enabled by default causes usability issues such as
https://gnats.NetBSD.org/57470 -- but for them to serve their useful
purposes, you need to do some additional setup to get a keytab from
the Kerberos realm's KDC (Key Distribution Center) anyway.

Disabling them in /etc/pam.d by default won't affect updates to any
existing installations -- unless they apply etc.tgz blindly, without
etcupdate or similar, which would destroy any existing configuration
anyway.

Any objections?



BACKGROUND

- pam_krb5 is a method to verify a password at login prompts that
  abuses the Kerberos single sign-on (SSO) model to see if the
  password works by attempting SSO with the password.

  Note: pam_krb5 is NOT the way to make sshd allow users in a Kerberos
  realm to log in with Kerberos tickets they already acquired --
  that's setting `GSSAPIAuthentication yes' in /etc/ssh/sshd_config.

  There are two purposes for which pam_krb5 is useful:

  1. Locally logging into workstations that are configured as part of
     a Kerberos realm using your Kerberos password.

     This makes the whole experience single sign-on (pam_krb5 then
     saves the credentials it got with the password so you can use
     reuse them in the login session), but only makes sense in
     corporate/university-type deployments where each workstation is
     bestowed a keytab by the KDC for the purpose.

  2. Allowing password fallback for login to sshd and similar on
     servers configured in Kerberos realms, for remote users who know
     they have a password but are not familiar with Kerberos and don't
     know to use kinit(1) to get Kerberos tickets for real Kerberos
     authentication (like `GSSAPIAuthentication yes' in sshd).

  Both use cases require the administrator to set up a keytab from the
  KDC for pam_krb5, on the workstation in case (1) and on the server
  in case (2).

- pam_ksu is a method to decide whether the user calling su(1) is
  allowed to switch to the user they've requested to switch to based
  on the Kerberos principals they're logged in as -- or could log in
  as, with a password prompt that pam_ksu can attempt Kerberos SSO
  with, like pam_krb5.

  This requires an administrator to both:

  . set up a keytab from the KDC, AND
  . set up /root/.k5login to authorize certain principals to su to
    root.

  Otherwise, pam_ksu will always fail -- but at the moment, it will
  first wait for some network access (https://gnats.NetBSD.org/57470).


DISCUSSION

On the one hand, it is kind of nice that things will just start
working kerberosily if the admin sets up a keytab to kerberize a host,
and annoying to have to twiddle more knobs.

On the other hand, even in the Kerberos world, these are kind of niche
use cases -- pam_krb5 as well as the password part of pam_ksu both fly
in the face of how Kerberos is supposed to be a _single_ sign-on
system that doesn't prompt you for passwords left and right.

So I think that it is not too onerous to ask that the administrator
explicitly add pam_krb5 or pam_ksu to the appropriate config files in
/etc/pam.d if they want to serve these use cases.

We may be able to fix the spurious network access in
https://gnats.NetBSD.org/57470 so that just trying to use Kerberos as
client-side SSO for _remote_ logins from (say) a personal laptop
doesn't affect the behaviour of _local_ su(1), but it would also be
nice to rule out all possible such interactions out of the box in the
first place.