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

[Thomas Schweikle]

On Wed, Nov 13, 2019 at 10:50 PM Russ Allbery <rra at debian.org> wrote:

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

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

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