default krb5 configuration does not request tgt for local users

[Thomas Schweikle]

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

Valid starting Expires Service principal
11/13/19 18:45:48 11/14/19 04:45:48 krbtgt/REALM@REALM
 renew until 11/20/19 18:45:43

But it just does:
#klist
klist: Credentials cache keyring 'persistent:1000:1000' not found

The bad thing behind: non of the further actions done while logging in would succeed, because not ticket would be available.

ProblemType: Bug
DistroRelease: Ubuntu 19.10
Package: libpam-krb5 4.8-2
ProcVersionSignature: Ubuntu 5.3.0-22.24-generic 5.3.7
Uname: Linux 5.3.0-22-generic x86_64
ApportVersion: 2.20.11-0ubuntu8.2
Architecture: amd64
CurrentDesktop: XFCE
Date: Wed Nov 13 18:36:27 2019
InstallationDate: Installed on 2019-09-09 (65 days ago)
InstallationMedia: Xubuntu 19.04 "Disco Dingo" - Release amd64 (20190416)
SourcePackage: libpam-krb5
UpgradeStatus: No upgrade log present (probably fresh install)

[Russ Allbery (rra-debian)]

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

[Thomas Schweikle (tps)]

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

[Russ Allbery (rra-debian)]

Thomas Schweikle <email address hidden> writes:

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

This would break other software that only calls pam_setcred and then
expects to have a ticket cache. Quite a lot of software that expects to
have a ticket cache after authentication never calls pam_open_session.

Worse, some software calls *all* of the PAM stack as root, including
open_session, before changing UIDs. So there is no point in the PAM stack
where you are guaranteed to be running as the target user.

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

So far as I can tell, there is no way for a single process to have access
to both root's persistent keyring and a user's persistent keyring at the
same time, so I believe this is not possible to do. But if you know of a
way to do this, please do let me know.

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

That would be great -- I have no idea how to do that, though. Do you have
any pointers?

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