On Plasma, the password prompt still works even during lock, and doesn't accept valid passwords about pam-authramp HOT 14 CLOSED

Apparently this is a related open issue since 2017. There was a patch rejected a few years ago too which never got reopened. I might take my own shot at this in the near future.

sddm/sddm#782

I am honestly baffled by the fact SDDM does not support PAM fully.

from pam-authramp.

@34N0 SDDM had a development gap for years. It's still in the process of being folded in to KDE, so once that completes, it might be worth asking KDE if they'd consider this change.

from pam-authramp.

Thank you, I'll test this later today. If this is only regarding the user experience, have you ever tested the user experience with pam_faillock in the stable secureblue build? You can edit the settings in /etc/security/faillock.conf. The experience might be equally bad and then its an SDDM issue!

from pam-authramp.

But if it locks out the user forever its a serious bug which evaded testing somehow!

from pam-authramp.

@34N0 There's something else at play here. Either SDDM or the existing secureblue config is broken:

# Deny access if the number of consecutive authentication failures
# for this user during the recent interval exceeds n tries.
# The default is 3.
deny = 3
#
# The length of the interval during which the consecutive
# authentication failures must happen for the user account
# lock out is <replaceable>n</replaceable> seconds.
# The default is 900 (15 minutes).
# fail_interval = 900
#
# The access will be re-enabled after n seconds after the lock out.
# The value 0 has the same meaning as value `never` - the access
# will not be re-enabled without resetting the faillock
# entries by the `faillock` command.
# The default is 600 (10 minutes).
unlock_time = 300
#

With this config and with pam_faillock, I'm never locked out at all. I can enter a valid password afterwards and I'm allowed in.

from pam-authramp.

@34N0 There's something else at play here. Either SDDM or the existing secureblue config is broken:

# Deny access if the number of consecutive authentication failures
# for this user during the recent interval exceeds n tries.
# The default is 3.
deny = 3
#
# The length of the interval during which the consecutive
# authentication failures must happen for the user account
# lock out is <replaceable>n</replaceable> seconds.
# The default is 900 (15 minutes).
# fail_interval = 900
#
# The access will be re-enabled after n seconds after the lock out.
# The value 0 has the same meaning as value `never` - the access
# will not be re-enabled without resetting the faillock
# entries by the `faillock` command.
# The default is 600 (10 minutes).
unlock_time = 300
#

With this config and with pam_faillock, I'm never locked out at all. I can enter a valid password afterwards and I'm allowed in.

I am unable to reproduce this. I am successfully getting locked out by faillock. But the user experience is equally bad with SDDM repeating "Authentication failed" and never informing the user of a lockout. There is a security setting in faillock called "silent" which would cause this behavior but it isn't enabled in secureblue. It seems like SDDM treats all pam failures as the same and prints its own error message "Authentication failed".

from pam-authramp.

In my testing there isn't currently any difference in user experience than the official pam_faillock module on SDDM. How do we resolve this issue? I think we have to create an issue with SDDM. But what until then?

from pam-authramp.

But if it locks out the user forever its a serious bug which evaded testing somehow!

This is was not an issue in my testing

from pam-authramp.

Since we're seeing different behavior, let me do more testing. Also, is there already an SDDM bug created? I would create one but I feel like you have a better understanding of the interaction between pam and DMs in order to capture that in the report 😄

from pam-authramp.

Those are my testing results for reference. I rebased to each image from a fresh silverblue vm.

from pam-authramp.

Since we're seeing different behavior, let me do more testing. Also, is there already an SDDM bug created? I would create one but I feel like you have a better understanding of the interaction between pam and DMs in order to capture that in the report 😄

Yes i'll create the BUG report myself 😄

from pam-authramp.

@34N0 Yikes. That makes me consider replacing SDDM with GDM for all of secureblue including the kinoite images.

from pam-authramp.

@34N0 Yikes. That makes me consider replacing SDDM with GDM for all of secureblue including the kinoite images.

This might be the way to go for now. But from a raw security perspective there isn't a downside to not showing the messages produced by either faillock or authramp. In faillock there is even a silent setting as a security feature which disables user messages. It's just really bad UX and in both our implementations it could lead to users lock themselves out out of their system for a long time / forever.

from pam-authramp.

The SDDM development seems to have different priorities, since there are some pull requests open for over five years. sddm/sddm#776 is actually relevant for this issue but needs rebasing and renewed patches. There is also enough discussions about this in the SDDM repository.

Closing as this is an SDDM issue.

from pam-authramp.