Unlocking with greeter fails to properly renew kerberos tickets with pam-krb5

[Brian Knoll]

[Impact]
Aborted PAM authentications may leave artifacts behind. This is due to LightDM not correctly calling pam_end on these.
Authenticating via a LightDM greeter does not refresh PAM credentials.

[Test Case]
1. Lock screen using LightDM greeter
2. Enter password to return to session
Expected result:
Screen is unlocked, credentials are refreshed.
Observed result:
Screen is unlocked, artifacts are left behind from PAM authentication, credentials not refreshed.

[Regression Potential]
Since this change affects the PAM handling other PAM modules might potentially have a change in behaviour. This seems low risk as both changes are correct behaviour over the previously incorrect behaviour.

I am using the pam-krb5 module to log into a Kerberos realm using lightdm. This works the initial time I log in, when I come in through lightdm. However, once I am logged in, and I lock the screen using light-locker, when I unlock the screen I no longer get renewed tickets.

The problem seems to be this:

-rw------- 1 me me 504 Mar 23 08:37 krb5cc_1000_sjkfhagfg
-rw------- 1 root root 504 Mar 23 08:38 krb5cc_pam_lsdkjhfsdk

So what is happening is that on the initial login, I get a valid ticket cache, owned by my logging-in user, and showing my UID in the file name. This ticket works fine. However, once I lock the screen and then unlock it, I get a ticket cache owned by root, with "_pam_" in the filename, and of course I can't use it because I am not logged in as root.

This problem did not occur in 12.04 LTS, probably because it did not use light-locker. The pam-krb5 module works in all other cases in my installations, so I do not believe this is any kind of problem with the pam_krb5 module.

Thanks,
Brian

ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: light-locker 1.2.1-0ubuntu1
ProcVersionSignature: Ubuntu 3.13.0-18.38-generic 3.13.6
Uname: Linux 3.13.0-18-generic x86_64
ApportVersion: 2.13.3-0ubuntu1
Architecture: amd64
Date: Sun Mar 23 08:40:38 2014
InstallationDate: Installed on 2014-03-22 (0 days ago)
InstallationMedia: Ubuntu-Server 14.04 LTS "Trusty Tahr" - Alpha amd64 (20140320)
ProcEnviron:
 TERM=xterm
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: light-locker
UpgradeStatus: No upgrade log present (probably fresh install)

[Brian Knoll (brianknoll)]

Just a comment that I think this should probably have a fairly high priority, as it severely affects the user experience for anyone using Kerberos to authenticate via the libpam-krb5 module against Kerberos or Active Directory, which I expect is a fairly large number of people.

Please let me know what I can do to help, and I will be glad to test things.

Thanks,
Brian

[Sean Davis (bluesabre)]

This may actually be a bug in lightdm. Including it in the bug report.

[Russ Allbery (rra-debian)]

Launchpad Bug Tracker <email address hidden> writes:

> So what is happening is that on the initial login, I get a valid ticket
> cache, owned by my logging-in user, and showing my UID in the file name.
> This ticket works fine. However, once I lock the screen and then unlock
> it, I get a ticket cache owned by root, with "_pam_" in the filename,
> and of course I can't use it because I am not logged in as root.

The _pam_ ticket cache is created during the authenticate step of the PAM
interaction, and is then written to the user's actual ticket cache during
either setcred or open_session. (setcred is the appropriate thing for a
screen saver to call.) It's deleted on pam_end.

This sounds like a screen saver that isn't using PAM properly. It looks
like it's starting a PAM interaction and then only calling authenticate,
never calling setcred, and never ending the PAM interaction, so it leaks a
root-owned ticket cache and never renews your cache.

There used to be widespread problems of this sort due to the number of
people writing screen savers who didn't really understand how PAM worked,
but I thought most of them had been fixed.

You can confirm that it's a problem with this program rather than with
your system configuration by running xscreensaver, locking the screen,
unlocking with your Kerberos password, and seeing if that properly
refreshes your credentials. I know that xscreensaver does PAM properly.

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

[Brian Knoll (brianknoll)]

Thank you, Russ, for the insightful explanation of what is happening here.  I can definitely confirm that xscreensaver does indeed work on my system, as that is what I am using as a workaround to this issue.  It isn't as "polished" as using the lightdm screen saver would be, but it certainly works better as far as the PAM integration is concerned.  So a couple of things come to mind given all that we know so far:

1. The workaround is to use xscreensaver instead, although that is not something all users will be able to handle, especially given the lack of polish and the fact that some additional configuration in the X environment is required to get that to work.  But it does indeed work, as I'm using it over here.

2. Probably more importantly, the PAM handling in light-locker appears to be very broken.  This will probably affect other modules besides pam-krb5, and is a significant issue.

On Sunday, March 23, 2014 1:40 PM, Russ Allbery <email address hidden> wrote:

Launchpad Bug Tracker <email address hidden> writes:

> So what is happening is that on the initial login, I get a valid ticket
> cache, owned by my logging-in user, and showing my UID in the file name.
> This ticket works fine.  However, once I lock the screen and then unlock
> it, I get a ticket cache owned by root, with "_pam_" in the filename,
> and of course I can't use it because I am not logged in as root.

The _pam_ ticket cache is created during the authenticate step of the PAM
interaction, and is then written to the user's actual ticket cache during
either setcred or open_session.  (setcred is the appropriate thing for a
screen saver to call.)  It's deleted on pam_end.

This sounds like a screen saver that isn't using PAM properly.  It looks
like it's starting a PAM interaction and then only calling authenticate,
never calling setcred, and never ending the PAM interaction, so it leaks a
root-owned ticket cache and never renews your cache.

There used to be widespread problems of this sort due to the number of
people writing screen savers who didn't really understand how PAM worked,
but I thought most of them had been fixed.

You can confirm that it's a problem with this program rather than with
your system configuration by running xscreensaver, locking the screen,
unlocking with your Kerberos password, and seeing if that properly
refreshes your credentials.  I know that xscreensaver does PAM properly.

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

--
You received this bug notification because you are subscribed to the bug
report.
https://bugs.launchpad.net/bugs/1296276

Title:
  light-locker fails to properly renew kerberos tickets with pam-krb5

Status in “light-locker” package in Ubuntu:
  New
Status in “lightdm” package in Ubuntu:
  New

Bug description:
  I am using the pam-krb5 module to log into a Kerberos realm using
  lightdm.  This works the initial time I log in, when I come in through
  lightdm.  However, once I am logged in, and I lock the screen using
  light-locker, when I unlock the screen I no longer get renewed
  tickets.

  The problem seems to be this:

  -rw------- 1 me      me    504 Mar 23 08:37 krb5cc_100...

[Robert Ancell (robert-ancell)]

Could you please try lp:~robert-ancell/lightdm/setcred-on-unlock and see if this fixes it?

[Russ Allbery (rra-debian)]

Robert Ancell <email address hidden> writes:

> Could you please try lp:~robert-ancell/lightdm/setcred-on-unlock and see
> if this fixes it?

It will surprise me if this change fixes the issue. pam-krb5 treats
PAM_REFRESH_CRED and PAM_REINITIALIZE_CRED identically.

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

[Russ Allbery (rra-debian)]

I took a closer look at the code. It looks like whatever is going on here
is more complicated than just the screen locker not using PAM properly,
although there is one error here:

    /* If nothing to run just refresh credentials because we successfully authenticated */
    if (command_argc == 0)
    {
        pam_setcred (pam_handle, PAM_REINITIALIZE_CRED);
        return EXIT_SUCCESS;
    }

This needs to check the return status of pam_setcred and report any
errors, and it needs to call pam_end like all of the other exit paths of
this function. The lack of a call to pam_end is why the *_pam_* ticket
cache is being leaked.

However, I suspect the actual problem is that this program is being run as
root and isn't told where the user's ticket cache is. I'm curious if
there's another ticket cache that shows up somewhere (probably
/tmp/krb5cc_0) because the credentials are being written out to the
default ticket cache location for root instead of to the user's session
ticket cache as determined by KRB5CCNAME. The problem, in turn, would be
that this program isn't inheriting the environment of the user's session.
I'm not at all clear on exactly how it's run, but it appears to be run as
root rather than as the user, which may indicate that it's being started
by some other system service rather than by the user.

One thing to try is to add "debug" to the arguments of pam_krb5.so in
/etc/pam.d/common-auth and then look in syslog after unlocking the
screen. That should provide much more detail about exactly what the
Kerberos PAM module is trying to do.

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

[Robert Ancell (robert-ancell)]

LightDM trunk never calls pam_setcred when you unlock using a greeter and this branch does. In a normal login pam_setcred is run as root so I don't think it's root that will be causing the problem (I guess the module drops the privileges on the file after calling pam_setcred).

Thanks for catching the error, fixed.

[Russ Allbery (rra-debian)]

Robert Ancell <email address hidden> writes:

> LightDM trunk never calls pam_setcred when you unlock using a greeter
> and this branch does. In a normal login pam_setcred is run as root so I
> don't think it's root that will be causing the problem (I guess the
> module drops the privileges on the file after calling pam_setcred).

Oh! I'm sorry. I looked at the head commit to the branch, and didn't
realize that it diverged more than that.

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

[Robert Ancell (robert-ancell)]

The merge proposal might be easier to review - https://code.launchpad.net/~robert-ancell/lightdm/setcred-on-unlock/+merge/212337

[Russ Allbery (rra-debian)]

Robert Ancell <email address hidden> writes:

> The merge proposal might be easier to review -
> https://code.launchpad.net/~robert-ancell/lightdm/setcred-on-
> unlock/+merge/212337

Ah, indeed, thank you! That looks very good here if it works. I'm still
worried about whether the right environment will be set for it to find the
user's ticket cache, but hopefully it will just work.

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

[Brian Knoll (brianknoll)]

To move this along, I've built a VM I can test this fix on, but to speed things up, is there a PPA I can use? I don't mind building it but I am concerned about building it differently than the official build, so if there is a PPA I can use I will gladly install this onto my VM and I can tell you fairly quickly whether it solves the problem or not, so we can get this into final if possible.

Thanks for all the help,
Brian

[Robert Ancell (robert-ancell)]

There is no PPA, you can build with:
$ sudo apt-get build-dep lightdm
$ bzr branch lp:~robert-ancell/lightdm/setcred-on-unlock
$ cd setcred-on-unlock
$ bzr-buildpackage

[Robert Ancell (robert-ancell)]

Landed into lp:lightdm, merge proposal for 1.10 (what Ubuntu 14.04 is using) is https://code.launchpad.net/~robert-ancell/lightdm/setcred-on-unlock-1.10/+merge/214660

[Robert Ancell (robert-ancell)]

Note this is not released into trusty and is awaiting confirmation. I've put this into ppa:ubuntu-desktop/ppa (https://launchpad.net/~ubuntu-desktop/+archive/ppa).

[Brian Knoll (brianknoll)]

I applied this to a VM to test, and it does indeed appear to do the right thing. I can confirm that this code does seem to have the intended effect.

[Oliver Brakmann (obrakmann)]

FWIW, I encountered a similar problem, using sssd instead of pam-krb5, though. I can also confirm that the packages from the PPA make lightdm correctly refresh Kerberos credentials and thus fix the issue I had. It would be very welcome indeed if that fix made it into the trusty repository proper. Thanks!

[Launchpad Janitor (janitor)]

This bug was fixed in the package lightdm - 1.11.0-0ubuntu1

---------------
lightdm (1.11.0-0ubuntu1) utopic; urgency=medium

  * New upstream release:
    - When switching to an existing session refresh PAM credentials and end
      session cleanly so no resources leak. (LP: #1296276)
    - Support new standard DesktopNames field in session files
    - Set XDG_SESSION_TYPE and XDG_SESSION_DESKTOP as used by systemd
    - Emit DBus PropertiesChanged when Sessions/Seats properties change. Also
      add SessionAdded/SessionRemoved signals to Seat interface

  [ Harald Sitter ]
  * Add pam_kwallet to pam configs. (LP: #1305307)

  [ Martin Pitt ]
  * Add systemd integration
 -- Robert Ancell <email address hidden> Mon, 28 Apr 2014 10:32:37 +1200

[Brian Murray (brian-murray)]

Hello Brian, or anyone else affected,

Accepted lightdm into trusty-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/lightdm/1.10.1-0ubuntu1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

[Oliver Brakmann (obrakmann)]

Sorry for the delay, I wanted to wait with the testing until my ticket lifetime ran out.

Anyway, I can confirm that using lightdm 1.10.1-0ubuntu1 causes the ticket cache to be automatically refreshed upon unlocking the screen, and there is no need to run kinit manually anymore. Again, I'm using sssd as backend. Tested both within the ticket lifetime as well as after the tickets expired.

I cannot verify if the leaking of the root-owned ticket cache is fixed, as that didn't happen at all with sssd to begin with. Because of that I'm hesitant to change the tag to verification-done already. Maybe Brian will chime in as well to confirm that part. Otherwise I'll change the tag in a few days.

Thanks for the quick response!

[Scott Kitterman (kitterman)]

The verification of the Stable Release Update for lightdm has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regresssions.

[Launchpad Janitor (janitor)]

This bug was fixed in the package lightdm - 1.10.1-0ubuntu1

---------------
lightdm (1.10.1-0ubuntu1) trusty; urgency=medium

  * New upstream release:
    - When switching to an existing session refresh PAM credentials and end
      session cleanly so no resources leak. (LP: #1296276)
    - Update apparmor rules to allow oxide based browsers and Google Chrome to
      run in the guest session.
  * debian/patches/06_apparmor_chromium_updates.patch:
    - Applied upstream
 -- Robert Ancell <email address hidden> Mon, 28 Apr 2014 09:56:14 +1200

[Brian Knoll (brianknoll)]

I just noticed what appears to be another problem:

-rw------- 1 myuser mygroup 504 May 12 21:21 krb5cc_0
-rw------- 1 myuser mygroup 504 May 12 21:16 krb5cc_1000_a8bk3j

While lightdm is renewing the tickets now when unlocking the screen saver, and the ownership of the ticket is correct, the filename still appears to be incorrect. Specifically, the filename appears to be constructed using the user number of the lightdm process, rather than the user number of the user authenticating to the screen saver. The resut is that the ticket is created and stored on disk, accessible to the user but not used unless the user explicitly uses the ticket because the filename does not conform to what is expected. In this instance, for example, both of these tickets were created by my normal user instance. The one ending in "0" is the ticket created when I unlocked the light-locker screen saver.

Thanks to all involved for all of the excellent work so far, but it does look like there is still a little more to do here.

Thanks,
Brian

[Russ Allbery (rra-debian)]

Brian Knoll <email address hidden> writes:

> I just noticed what appears to be another problem:

> -rw------- 1 myuser mygroup 504 May 12 21:21 krb5cc_0
> -rw------- 1 myuser mygroup 504 May 12 21:16 krb5cc_1000_a8bk3j

> While lightdm is renewing the tickets now when unlocking the screen
> saver, and the ownership of the ticket is correct, the filename still
> appears to be incorrect. Specifically, the filename appears to be
> constructed using the user number of the lightdm process, rather than
> the user number of the user authenticating to the screen saver.

This is the library default ticket cache path for root, which is used if
no KRB5CCNAME environment variable is set while renewing ticket caches in
a root-owned process, and neither ccache nor ccache_dir are set in the PAM
configuration. (For creating a new session, the second file name is used,
but when refreshing, one wants to use the same ticket cache that other
user processes will use, which is the default ticket cache path when
KRB5CCNAME is set. So pam-krb5 is trying to match the behavior of other
userspace processes, but since it's running as another user, it doesn't
have enough information to know the correct default ticket cache name.)

What I assume should happen is that lightdm should somehow inherit the
KRB5CCNAME environment variable set for the user session. However, I
don't know enough about the architecture to know how that should be
properly done.

(It's possible that it already does this but there's a setuid program in
the loop, in which case the environment variables are ignored. That would
require a more complex fix. Let me know if that's the case.)

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

[Brian Knoll (brianknoll)]

I set the status back to "new" because that sounded correct given that there is potentially additional work to be evaluated here, but if that's not the right thing to do please let me know for future reference when working with Launchpad tickets. I would normally just file a new ticket, but in this case this is still kind of the same work we're discussing.

Again, thanks very much to all involved for all the excellent support thus far.

[Robert Ancell (robert-ancell)]

Yes, please open a new bug to track this other issue.