Please report this bug upstream

Keywords: (none) => UPSTREAM

Appears to be:
https://bugs.kde.org/show_bug.cgi?id=281802

See Also: (none) => https://bugs.kde.org/show_bug.cgi?id=281802

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.

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.

Created attachment 8337 [details]
ltrace -f /usr/libexec/kcheckpass on Cauldron

I edited the log to show my password as "password"

Created attachment 8338 [details]
ltrace -f -o kcheckpass.out /usr/lib64/kde4/libexec/kcheckpass on Mageia 5

(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

CC: (none) => makowski.mageia

Any new information David on that one ?

CC: (none) => ennael1

No.  I believe this is a PAM issue.

Is it still happening now that pam-1.3.0-5 is in mga6 ?

CC: (none) => bruno

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.

any news on this ?

CC: (none) => mageia

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.

It has been said in today's meeting that Nicolas will try to reproduce with David's help.

a coworker did the test and it worked, not with mga tools to configure the authentification but by configuration by hand.

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?

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

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?

CC: (none) => qa-bugs

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

i still need infos to reproduce

I know, I'm hoping to get to my Mageia bugs this weekend.

some news ?

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.

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

Might be related to bug 18986?

See Also: (none) => https://bugs.mageia.org/show_bug.cgi?id=18986

(In reply to Rémi Verschelde from comment #25)
> Might be related to bug 18986?

I doubt it.

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

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?

CC: (none) => unruh

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.

Status comment: Nicolas Lécureuil will try to reproduce with David Walser's help. => possibly fixed by pam_mount-2.16-2.mga6

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.

CC: (none) => eatdirt

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.

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?

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.

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.

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.

can someone test this ?

As it involves setting up remote access, it's not something that's going to
normally affect running a live iso.

On an installed system, it can be fixed by an update after release, so changing
importance from a release blocker to high.

CC: (none) => davidwhodgins
Priority: release_blocker => High

If we don't care about this bug enough to test or fix it, I'll just assume that I already did and close it.  It can be re-opened if someone discovers that the bug still exists.

Resolution: (none) => FIXED
Status: NEW => RESOLVED