[Bug 1852470] Re: default krb5 configuration does not request tgt for local users

[Russ Allbery]

Thomas Schweikle <1852470 at bugs.launchpad.net> 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 at 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 (rra at debian.org)              <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 a member of Ubuntu
Foundations Bugs, which is subscribed to libpam-krb5 in Ubuntu.
https://bugs.launchpad.net/bugs/1852470

Title:
  default krb5 configuration does not request tgt for local users

Status in libpam-krb5 package in Ubuntu:
  New

Bug description:
  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 at REALM

  Valid starting     Expires            Service principal
  11/13/19 18:45:48  11/14/19 04:45:48  krbtgt/REALM at 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)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libpam-krb5/+bug/1852470/+subscriptions