Comment 2 for bug 1852470

Thomas Schweikle <email address hidden> writes:

> default libpam-krb5-config does not request tgt for local users if
> kerberos is available. But it should if a remote user matches the local
> one.

> auth [success=3 default=ignore] pam_krb5.so minimum_uid=1000
> auth [success=2 default=ignore] pam_unix.so nullok_secure try_first_pass
> auth [success=1 default=ignore] pam_sss.so use_first_pass
> auth requisite pam_deny.so
> auth required pam_permit.so
> auth optional pam_cap.so

> right after logging in I'd suspected 'klist' to exaust:
> #klist
> Ticket cache: KEYRING:persistent:1000:1000
> Default principal: user@REALM

You can't use persistent keyrings with pam-krb5 because they're tied to
UID, and at the time that pam_setcred runs, the authenticating process is
generally still running as root. Your credentials are therefore stored in
a persistent keyring in the wrong UID space and aren't visible to the
correct user UID.

I don't see an obvious way to be able to support this without doing
setuid() inside pam-krb5, which is a serious abstraction violation and
potentially breaks unrelated software. There would need to be some way
for root to address the keyring namespace of the target user, and I don't
know of one (although if you do, please let me know and I can try to find
time to implement such a thing).

The path of least resistance to use persistent keyrings right now would be
to let pam_krb5 use a traditional ticket cache in /tmp and then copy that
ticket cache into the keyring and delete it after the PAM stack has
completed. However, I don't know if that achieves your other security
goals in using persistent keyrings.

It should be possible to use session keyrings instead, although you'll
need a pam_keyinit with https://github.com/linux-pam/linux-pam/issues/149
fixed first.

--
Russ Allbery (<email address hidden>) <https://www.eyrie.org/~eagle/>