Bug 1114258 - Latest update of kcheckpass breaks custom PAM configuration
Latest update of kcheckpass breaks custom PAM configuration
Status: RESOLVED FIXED
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: KDE Workspace (Plasma)
Current
Other Other
: P5 - None : Normal (vote)
: ---
Assigned To: E-Mail List
E-mail List
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2018-10-31 23:24 UTC by Björn Voigt
Modified: 2018-11-01 21:49 UTC (History)
1 user (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Björn Voigt 2018-10-31 23:24:40 UTC
Since the latest kscreenlocker changes to resolve bug #931296 manual changes of /etc/pam.d/kscreenlocker get lost after each kscreenlocker update.

It is not important, which manual changes are made. I show my changes as an example. My desktop is secured with a Yubikey as a second factor:

$ cat /etc/pam.d/kscreenlocker
#%PAM-1.0
auth     requisite      pam_yubico.so <some additional parameters>
auth     include        common-auth
account  include        common-account
password include        common-password
session  required       pam_loginuid.so
session  include        common-session

If I update kscreenlocker my manual configuration are reset and I get:

$ cat /etc/pam.d/kscreenlocker
#%PAM-1.0
auth     include        common-auth
account  include        common-account
password include        common-password
session  required       pam_loginuid.so
session  include        common-session

No other PAM service shows this problem.
Comment 1 Wolfgang Bauer 2018-11-01 19:38:01 UTC
(In reply to Björn Voigt from comment #0)
> Since the latest kscreenlocker changes to resolve bug #931296 manual changes
> of /etc/pam.d/kscreenlocker get lost after each kscreenlocker update.

That was bug#1108329 though, that added /etc/pam.d/kscreenlocker to the package.
As mentioned we'd need to mark the file as %config(noreplace) so that changes don't get overwritten when installing updates.

I have a question though:
Why do you need to modify the file in the first place?
It includes the "common" config (common-auth, common-account, common-password, common-session), wouldn't it work to just change those instead?
Comment 2 Wolfgang Bauer 2018-11-01 20:33:21 UTC
The fix is on the way to Tumblweed, so the next update should be "safe".
https://build.opensuse.org/request/show/645942
Comment 3 Björn Voigt 2018-11-01 21:49:31 UTC
(In reply to Wolfgang Bauer from comment #1)
> I have a question though:
> Why do you need to modify the file in the first place?
> It includes the "common" config (common-auth, common-account,
> common-password, common-session), wouldn't it work to just change those
> instead?

We use Yubikey keys to secure laptops, desktops, network services like VPNs with a second factor additional to the username/password authentication. A Yubikey is a multi-function device (OTP generator, smart card device, U2F device etc.) with some open source libraries and tools, e.g. pam_yubico, pam_u2f, yubioath-desktop etc. Not all Yubico PAM modules are compatible with all PAM services.

We use pam_yubico in OTP mode on always connected computers for desktop login and in challenge-response mode for devices like laptops for desktop login.

Authentication in OTP mode works like this e.g. in Kscreenlocker:

* screen is locked
* user types in his password (and does not type Enter)
* user taps on the Yubikey button (the device generates 44 character long random sequence - it is not really random, it is based on a builtin secret - and types Enter)
* PAM module pam_yubico strips the last 44 characters from password and sends it to a Yubico authentication server in the cloud
* if the response is "ALLOW", then the normal pam_unix library (or any other PAM library) checks the password (the entered password without the last 44 characters)
* if the password is OK, the user has unlocked the display

It works the same way with "login", "sddm" and optionally with some other PAM services. (SDDM has a bug with nearly expired passwords - see https://bugzilla.opensuse.org/show_bug.cgi?id=969813. And it is not nice, the Kscreenlocker does not use the PAM configuration of SDDM or any other display manager.) 

Unfortunately some (PAM) services are not compatible with OTP. The best example is an IMAP server. If the mail client queries the IMAP server every 5 minutes, the user can not be forced to tap the Yubikey key every 5 minutes. So IMAP and many other services have to be secured in a different way, this means with a different PAM configuration.

See "man pam_yubico" or https://github.com/Yubico/yubico-pam