On Wed, Nov 13, 2019 at 10:50 PM Russ Allbery wrote: > Thomas Schweikle 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. > Simple solution: pam_krb5 just only authenticates and some other pam_krb5 module has to address the persistent keyring problem as soon as pam switches UID space to this authenticated user. Maybe this could be addressed calling pam_krb5 twice: once while authenticating, second after having switched UID space. pam itself handles this by handling over tokens from one module to the next. Shall be possible to do it the same way. Or: make root have access to newly created persistent keyrings until it switches UID. Would mean to make it possible to switch a root generated persistant keyring owner to a user, but not vice versa. Could be some real elegant solution, not only for pam and such. > 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). > AFAIK it is possible to create the keyring store as root, then change the UID of the owner, which handles the keyring store over to the user in question. 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 (