Bug 19103 - Plasma screen locker does not let non-local users unlock screen (PAM issue?)
Summary: Plasma screen locker does not let non-local users unlock screen (PAM issue?)
Status: NEW
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: Cauldron
Hardware: All Linux
: release_blocker critical
Target Milestone: ---
Assignee: KDE maintainers
QA Contact:
URL:
Whiteboard:
Keywords: UPSTREAM
Depends on:
Blocks: 17523
  Show dependency treegraph
 
Reported: 2016-07-29 18:33 CEST by David Walser
Modified: 2017-06-22 16:03 CEST (History)
7 users (show)

See Also:
Source RPM: plasma-workspace-5.7.2-3.mga6.src.rpm
CVE:
Status comment: possibly fixed by pam_mount-2.16-2.mga6


Attachments
ltrace -f /usr/libexec/kcheckpass on Cauldron (1.54 KB, text/plain)
2016-08-12 18:33 CEST, David Walser
Details
ltrace -f -o kcheckpass.out /usr/lib64/kde4/libexec/kcheckpass on Mageia 5 (2.64 KB, text/plain)
2016-08-12 18:35 CEST, David Walser
Details

Description David Walser 2016-07-29 18:33:06 CEST
In Plasma's default configuration, it automatically locks the screen after some inactivity.  For a local user, I was able to unlock the screen.  For a user in Active Directory, which I'm able to use via sssd, unlocking the screen fails.
Comment 1 Nicolas Lécureuil 2016-08-05 23:41:25 CEST
Please report this bug upstream
Comment 2 David Walser 2016-08-09 21:38:16 CEST
Appears to be:
https://bugs.kde.org/show_bug.cgi?id=281802
Comment 3 David Walser 2016-08-10 14:40:12 CEST
It doesn't sound like upstream is going to be of any help here.  Our PAM configurations haven't changed, but they say their code hasn't changed.
Comment 4 David Walser 2016-08-12 18:31:36 CEST
I suppose upstream could be right, this might be a PAM issue and not with kcheckpass itself.  Running kcheckpass with ltrace -f, I notice a start difference between Mageia 5 and Cauldron.  I'll attach logs.
Comment 5 David Walser 2016-08-12 18:33:39 CEST
Created attachment 8337 [details]
ltrace -f /usr/libexec/kcheckpass on Cauldron

I edited the log to show my password as "password"
Comment 6 David Walser 2016-08-12 18:35:54 CEST
Created attachment 8338 [details]
ltrace -f -o kcheckpass.out /usr/lib64/kde4/libexec/kcheckpass on Mageia 5
Comment 7 Philippe Makowski 2016-08-13 15:28:27 CEST
(In reply to David Walser from comment #4)
> I suppose upstream could be right, this might be a PAM issue and not with
> kcheckpass itself.  Running kcheckpass with ltrace -f, I notice a start
> difference between Mageia 5 and Cauldron.  I'll attach logs.

you should see the problem with journalctl SYSLOG_FACILITY=10
in fact we need pam 1.3.0-5 in core/release
Comment 8 Anne Nicolas 2016-08-27 16:06:00 CEST
Any new information David on that one ?
Comment 9 David Walser 2016-08-27 16:14:09 CEST
No.  I believe this is a PAM issue.
Comment 10 Bruno Cornec 2016-10-17 11:37:15 CEST
Is it still happening now that pam-1.3.0-5 is in mga6 ?
Comment 11 David Walser 2016-10-17 12:28:44 CEST
PAM 1.3.0 was already in Cauldron when this was happening.  We just didn't immediately realize that since Sophie was using an outdated mirror.
Comment 12 Nicolas Lécureuil 2016-11-06 15:43:20 CET
any news on this ?
Comment 13 David Walser 2016-11-06 15:45:05 CET
Someone needs to set up a test environment for this.  I don't have access to the resources anymore, but this is an important bug.
Comment 14 Samuel Verschelde 2016-12-03 21:59:36 CET
It has been said in today's meeting that Nicolas will try to reproduce with David's help.
Comment 15 Nicolas Lécureuil 2017-01-03 17:29:51 CET
a coworker did the test and it worked, not with mga tools to configure the authentification but by configuration by hand.
Comment 16 Rémi Verschelde 2017-03-06 10:37:24 CET
How should we debug this further and hopefully find a fix? Should it stay as blocker for Mageia 6, or will it have to do with an errata entry and high priority for Mageia 7?
Comment 17 David Walser 2017-03-06 12:09:14 CET
Since it will make Plasma completely unusable in affected environments, it really needs to be fixed, but one challenge is that I found this bug two jobs ago and am no longer in an environment where I can easily set up a reproducer for this.  The first step is for someone to do so, so it can at least be tested and maybe debugged.  If it can't be reproduced, then I guess we'll just have to hope for the best...
Comment 18 Samuel Verschelde 2017-03-06 16:07:14 CET
QA testers, could any of you try to reproduce this bug which is currently set as release_blocker, so that we can decide about it?
Comment 19 Nicolas Lécureuil 2017-03-06 16:29:55 CET
i would need a procedure to reproduce, i have some windows here, i can install some windows server, etc if needed but i don't know how to reproduce
Comment 20 Nicolas Lécureuil 2017-03-22 15:40:21 CET
i still need infos to reproduce
Comment 21 David Walser 2017-03-22 23:05:03 CET
I know, I'm hoping to get to my Mageia bugs this weekend.
Comment 22 Nicolas Lécureuil 2017-03-27 16:03:41 CEST
some news ?
Comment 23 David Walser 2017-03-28 03:01:50 CEST
Actually, maybe I do have some news.  Having built a pam_mount package for RHEL at work based on the Mageia package, I have run into similar problems, and have figured out that it is due to pam_mount.conf.xml not being world readable.  Strangely, this did not cause a problem with KDE 4 on Mageia 5, but it does on RHEL 7.  As I was using pam_mount at my old job, it may have been the real cause.  Other than that, the configuration at the old job was sssd authenticating against Active Directory.  I will try to give more details on both aspects of that configuration soon.
Comment 24 David Walser 2017-03-29 15:39:23 CEST
OK, if your domain is example.com, you need to have...

in /etc/resolv.conf:
search example.com

in /etc/krb5.conf:
[libdefaults]
 default_realm = EXAMPLE.COM
 dns_lookup_realm = true
 dns_lookup_kdc = true
 forwardable = true
 proxiable = true

in /etc/samba/smb.conf:
[global]
   workgroup = EXAMPLE
   realm = EXAMPLE.COM
   kerberos method = secrets and keytab
   security = ads

in /etc/nsswitch.conf:
passwd: files sss
shadow: files sss
group:  files sss

in /etc/sssd/sssd.conf:
domains = example.com
[nss]
fallback_homedir = /home/%u
default_shell = /bin/bash
[domain/example.com]
description = AD domain
enumerate = false
cache_credentials = true
case_sensitive = false
min_id = 1000
id_provider = ad
ldap_schema = ad
dyndns_update = false

With a CIFS file server called "backup" and a share called "stuff", in /etc/security/pam_mount.conf.xml:
<volume sgrp="domain users" fstype="cifs" options="sec=krb5,cruid=%(USERUID)"
        server="backup" path="stuff" mountpoint="~/stuff" />

in /etc/pam.d/system-auth:
# following line above pam_tcb.so auth line
auth required pam_mount.so disable_interactive
# following line below pam_tcb.so auth line
auth sufficient pam_sss.so use_first_pass
# following line below pam_tcb.so account line
account [default=bad success=ok user_unknown=ignore] pam_sss.so
# *NOTE* change account pam_deny.so line to pam_permit.so instead
# following line below pam_tcb.so password line
password sufficient pam_sss.so use_authtok
# following line above all session lines
session required pam_mkhomedir.so umask=0026 skel=/etc/skel/ silent
# following lines below all session lines
session optional pam_sss.so
session optional pam_mount.so disable_interactive

If you have a domain administrator account (or one with permissions to join machines to the domain) called admin, do:
# kinit admin
# net ads join -k
Comment 25 Rémi Verschelde 2017-05-06 18:46:16 CEST
Might be related to bug 18986?
Comment 26 David Walser 2017-05-06 20:14:23 CEST
(In reply to Rémi Verschelde from comment #25)
> Might be related to bug 18986?

I doubt it.
Comment 27 David Walser 2017-05-06 20:14:46 CEST
(In reply to David Walser from comment #26)
> (In reply to Rémi Verschelde from comment #25)
> > Might be related to bug 18986?
> 
> I doubt it.

In fact, no it isn't.  I had removed kwallet from my PAM configuration already when I discovered this bug.
Comment 28 w unruh 2017-05-06 22:30:22 CEST
Could there be some commonality in that pam has problems handing over the password to kwalletd in the one case and to kscreenlocker in this case?

Is it just Mageia that is having the problem or is the same problem occuring in the latest (plasma5) versions of other operating systems?
Comment 29 David Walser 2017-05-25 16:30:06 CEST
I have uploaded my fixed pam_mount which might fix this.  If you do get around to trying to reproduce this, please try a chmod 600 /etc/security/pam_mount.conf.xml to see if it triggers the issue again.
Comment 30 Chris Denice 2017-05-25 16:40:11 CEST
Hi David,
I think world readable pam_mount is a security issue. If you mount encrypted partitions with pam_mount, it contains a lot of inflation about cipher, location of encrypted password files etc... I would not recommend to do so...

Cheers,
Chris.
Comment 31 David Walser 2017-05-25 16:42:06 CEST
Sorry, it's really not an option any more for it not to be world-readable.  Both KDE and GNOME's screen locker's will not work if it isn't readable.
Comment 32 Chris Denice 2017-05-25 17:03:00 CEST
So, for a lock screen of KDE and Gnome we allow ourselves a security breach?
Noted :)

Please, add a big warning in the errata if there are no other solutions. Maybe there is a way to have an "include" command in pam_mount to include sensitive files?
Comment 33 David Walser 2017-05-25 17:24:58 CEST
It's not a security breach, first of all.  Second of all, not being able to unlock your screen means the whole thing is basically not functional.

Having mount information world-readable should be no different than /etc/fstab or local auto-mounter maps.  If you're putting sensitive information in there, that's a configuration issue on your part, not a packaging issue.  There doesn't need to be a warning.  If you're putting sensitive information in there, you know you're doing it and need to protect it accordingly.  There shouldn't be a need for that, however.  If pam_mount is mounting something with encryption, it should be using the same password for the encryption as the login password for the user, so that pam_mount can use that password without you having to hard-code it in the configuration.  Linux.com did a series of articles over the past year about recommended security practices for kernel developers.  They specifically mentioned that using different passwords for hard disk encryption and logging in offers no additional security.

If you think an include mechanism would help you (it sounds like a decent idea to me), and it would work with the screen lockers to do so, I encourage you to implement it.  Don't count on upstream doing anything at this point from what I've seen.
Comment 34 Chris Denice 2017-05-25 18:25:59 CEST
I think it is a security issue and that's the way pam_mount works. The file you put world readable HAS to contain sensitive information. I don't mean the password, but information that you would have like to remain private. For this reason, pam_mount defaults this file to be not world readable.

From man pam_mount.conf:

 <volume  path="/home/%(USER).img" mountpoint="~" cipher="aes-cbc-essiv:sha256" fskey‐cipher="aes-256-cbc" fskeyhash="sha1" fskeypath="/home/%(USER).key" />

Any user will have access to the kind of cipher, hash and the path of your encrypted key.

Now, I still believe that if the KDE and GNOME lockscreens locks due to this, that's clearly a KDE and GNOME bug right? Not pam_mount. The way we fix it is not the way to go, and if we go this way, yes, you should add an errata.
Comment 35 David Walser 2017-05-25 22:01:13 CEST
It most certainly does not need to contain sensitive information and I don't see any in your example, nor would there be for typical cifs mounts and the like.  Again, if you have something sensitive, that's particular to your configuration, not a general issue that would affect all use cases.

I certainly don't disagree that it doesn't make much sense that the screen lockers behave this way, especially as KDE in Mageia 5 didn't, but they do in Mageia 6 and RHEL as well.  Right now, this is the only fix.  If you feel that an entry in the release notes or something is appropriate, feel free to add it.  If you want to file bugs with GNOME and KDE, that's fine as well.  Note that I don't see Fedora forcing the permissions to 600 either.
Comment 36 Nicolas Lécureuil 2017-06-22 16:03:42 CEST
can someone test this ?

Note You need to log in before you can comment on or make changes to this bug.