FS#67644 - [pam][pambase] Locked out after one wrong password attempt
Attached to Project:
Arch Linux
Opened by Robert Balent (RobertBalent) - Thursday, 20 August 2020, 07:24 GMT
Last edited by Levente Polyak (anthraxx) - Saturday, 22 January 2022, 02:51 GMT
Opened by Robert Balent (RobertBalent) - Thursday, 20 August 2020, 07:24 GMT
Last edited by Levente Polyak (anthraxx) - Saturday, 22 January 2022, 02:51 GMT
|
|
Details
Description:
After latest pam update I'm being locked out of the account after only one wrong password attempt. It shows that I reached limit of 3 wrong password attempts and that I should wait 10 minutes. I didn't modified any configuration and I never enabled account lock after wrong passwords. This seems to be related to fprint package. I have fprintd daemon disabled and don't have any fingerprints configured. But it seems like it's started anyway? After uninstalling it, I'm being locked out of the account after 3 wrong password attempts. So there are 2 issues: 1. Why is this behavior enabled at all? I never enabled it. 2. Why I'm locked out after 1 wrong password attempt when fprint is installed? Environment: I'm using Gnome and default Gnome login screen. Package versions: pam 1.4.0-3 pambase 20200721.1-2 fprintd-1.90.1-1 libfprint-1.90.2-1 gdm 3.36.3-6 systemd 246.2-1 Log file attached. 
journal.txt
(7.4 KiB)
|
This task depends upon
Closed by Levente Polyak (anthraxx)
Saturday, 22 January 2022, 02:51 GMT
Reason for closing: Won't implement
Saturday, 22 January 2022, 02:51 GMT
Reason for closing: Won't implement
I’d say that, when being on a personal PC and not a professional server, there is no need to set a limit to how many wrong attempts can be done before locking completely a user session. It’s the first time I have been locked out of my own PC, and I am not very happy about it.
EDIT: fprint is not installed on my system. I only have pam and pambase, which I have both updated today.
EDIT 2: last pam update added a new file: etc/security/faillock.conf. The 3 wrong attemps limits is stored there (3 is the default, even if the matching line is commented out), but I don’t know how to set it to “no limit at all”.
Please let that know in the forum, because I am not able to sign in there (the last question fails continuously, despite I am giving the awaited answer).
Not sure who and why did they do such a terrible change? Did they ask Linux users before doing such change?
it would be interesting to see if other linux distros (ubuntu, fedora) will follow or not this default setting when they will switch to pam 1.4.0.
PS: could you report this to the forum again, Robert? Because despite of what V1del thinks, there clearly was a link between pam’s bug and (my, at least) Qt5 bug. And set this “deny” parameter to 0 in /etc/security/faillock.conf fixed everything. It could be good to know, don’t you think? Thank you.
It's just very confusing for this to happen without notice.
edit: rephrased
So, I updated pam and pambase on my other Arch PC, I have edited “/etc/security/faillock.conf” to set “deny = 0”, and… I did not work, this time. XScreenSaver showed me a big “Authentication failed!” after I have tested if everything was OK (it wasn’t). After a reboot, VLC (Qt5 app) is not using the good theme (Fusion, the default Qt5 theme, instead of gtk2, as defined in the “QT_QPA_PLATFORMTHEME=qt5ct” variable in “/etc/environment”), except if I run it from a Terminal.
Both PC configurations are the same, pam-related files are identical on both machines, so I don’t know what to do to fix that…
So, if Debian does some breaking changes, won't that affect Debian based distros too?
# The default is 900 (15 minutes).
# fail_interval = 900
So any 3 wrong passwords in a 15 minute period of time will lock the box according to the faillock.conf. So if you accidentally type a wrong password on login. Type a wrong password with sudo 10 minutes later. and then 4 minutes after than type a wrong password with sudo again -- you are locked -- even though you never had 3 failed passwords at any one prompt. This may be a bit too rigorous for home user use.
It looks like if you are a member of some group, you can stop it from locking by treating that group the same as root with:
# admin_group = <admin_group_name>
The 3 in 15 minutes by default will catch a lot of people. There should be a way to limit it to 3 in 15 minutes at a single prompt. That would be much better than any 3 fails in 15 minutes.
There were also limitations in when pam_tally2 could record failures, the tallylog was only acessible by root so none root authenticating services such as screenlockers would error attempting to access the file and failures would never be recorded.
It could also be an issue in the pambase changes or an issue in the pam_faillock module itself.
pam_faillock is not a drop in replacement for pam_tally / pam_tally2. pam_tally / pam_tally2 used a single call [2] while pam_faillock takes at least two [3]
this was one of the reasons for the pambase 20200721.1-2 changes that accompanied the pam 1.4.0-3 update.
Has anyone experienced the issue when there has been no GUI active or at least no GUI with a login or authentication prompt?
[1] https://github.com/linux-pam/linux-pam/releases/tag/v1.4.0
[2] https://man7.org/linux/man-pages/man8/pam_tally2.8.html
[3] https://linux.die.net/man/8/pam_faillock
HID events are also triggered by other devices like wireless headphones (in my case), which often emit spurious events/keypresses.
In my case, xscreensaver was activated multiple times by the HID input from the headphones and caused a 10 minute lockdown of my machine, which I had to fix with a reboot from a VTY.
This caused a small amount of lost data because the computer was logging measurements while I was away.
I have also wondered if it might have something to do with suspending my laptop whilst sudo is prompting for a password. Or perhaps whilst yay is running with the sudoloop option, and is waiting for (non-password) input. Haven't figured it out, but will be setting deny=0 until such a time this no longer occurs with defaults.
On my laptop it happened after suspend and I'm pretty sure I didn't type the password 3 times wrong withing 15 minutes.
On my servers I see this issues too, and I believe it is somehow related to the cockpit ssh bridge. But it doesn't make sense as my user password is accepted during the login to the cockpit dashboard and would be correctly forwarded to the other cockpit machines.
This seems like a pretty bad default.
Archlinux is the exact opposite of what you are talking about.
Though, why wasn't a change like this posted in the news? I was surprised also. I guess I could see why....
So let me quote the link you've posted:
"It is targeted at the proficient GNU/Linux user, or anyone with a do-it-yourself attitude who is willing to read the documentation, and solve their own problems. All users are encouraged to participate and contribute to the distribution. Reporting and helping fix bugs is highly valued and patches improving packages or the core projects are very appreciated"
It's an insane default for a Linux system and is very unexpected to happen on any distribution.
Also not requiring systemd_home by default anymore either (search the BBS for why that is a good idea I guess).
pam_faillock also has an undocumented built-in delay, so passing nodelay to pam_unix doesn't work anymore (nor editing /etc/login.defs).
pam_faillock is obviously not ready for default deployment, IMHO, there's way too many issues and undocumented and unexpected behavior.
Is the issue you are referring to with systemd-home the journal message? If so the module can be added to Noextract, pam will then skip it.
Or you could open a feature request against the systemd package asking for the module to be split out.
It it is some other issue please provide a link or preferably use
FS#65819.Does anyone have a reproducible case for the lock out after single attempt? If so please report it upstream.
Like many other people in this thread I believe this is not a good default behaviour, hence I am asking for it to change. It would be a bit better if sudo did not increment the counter, at least.
Please do, this has severely tripped me up on several machines. The main problem is that there is no indication as to what is going on, login is simply not working as if the wrong password was entered.
I have a feeling that solving this would go a long way to preventing the problems people are seeing here. I'm fairly sure this is the only reason I keep getting unexpectedly locked out.
I would like the default configuration to disable the lockout or at least significantly increase the number of attempts.
I guess 10 attempts would be more reasonable. It is easy to reach three attempts via fat finger, caps lock, forgot which pw is used on the given machine or for various other reasons.
The other big issue is the lack of feedback, for me as a user it is a silent lockout. I do not know whether that is solvable by Arch though.
deny = 0 should definitely be the default on arch at least
or does it have to do with the fact that I autologin?
If a particular installation is deemed to be a workstation and meant to be setup "less paranoia" then its upstream provides a sufficiently easy way to do so plus we provide specific instructions in the wiki how it can be adjusted to meet personal needs.