Comment 3 for bug 1852470

On Wed, Nov 13, 2019 at 10:50 PM Russ Allbery <email address hidden> wrote:

> 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.
>

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 (<email address hidden>) <https://www.eyrie.org/~eagle/>
>
>
> ** Bug watch added: github.com/linux-pam/linux-pam/issues #149
> https://github.com/linux-pam/linux-pam/issues/149
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1852470
>
> Title:
> default krb5 configuration does not request tgt for local users
>
> To manage notifications about this bug go to:
>
> https://bugs.launchpad.net/ubuntu/+source/libpam-krb5/+bug/1852470/+subscriptions
>

--
Thomas