Performing verification for Hirsute I enabled -proposed and installed libpam-modules libpam-modules-bin libpam-runtime libpam0g version 1.3.1-5ubuntu6.21.04.1
>From there, I set the pam_faillock configuration in: /etc/security/faillock.conf: deny = 3 unlock_time = 120 and also: /etc/pam.d/common-auth: # here are the per-package modules (the "Primary" block) auth requisite pam_faillock.so preauth auth [success=1 default=ignore] pam_unix.so nullok_secure auth [default=die] pam_faillock.so authfail auth sufficient pam_faillock.so authsucc # here's the fallback if no module succeeds auth requisite pam_deny.so # prime the stack with a positive return value if there isn't one already; # this avoids us returning an error just because nothing sets a success code # since the modules above will each just jump around auth required pam_permit.so # and here are more per-package modules (the "Additional" block) auth optional pam_cap.so # end of pam-auth-update config >From there, I created a new user "dave", and rebooted the system. I connected via ssh with the "dave" user and used the wrong password 5 times. I then tried with the correct password and found the account to be locked. I waited 2 minutes, and tried again with the correct password, and I was logged in. When the account was locked, I logged in as the "ubuntu" user and ran: $ sudo faillock --user dave dave: When Type Source Valid 2021-05-19 01:50:25 RHOST 192.168.122.1 V 2021-05-19 01:50:28 RHOST 192.168.122.1 V 2021-05-19 01:50:31 RHOST 192.168.122.1 V And I could see the times that "dave" was locked. I also tested resetting via: $ sudo faillock --user dave --reset and "dave" was allowed to log in again. My tests agree with what Richard sees. Marking as verified for Hirsute. ** Tags removed: verification-needed-hirsute ** Tags added: verification-done-hirsute -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pam in Ubuntu. https://bugs.launchpad.net/bugs/1927796 Title: [SRU]pam_tally2 can cause accounts to be locked by correct password. pam_faillock use is the recommended fix Status in pam package in Ubuntu: Fix Committed Status in pam source package in Bionic: Fix Committed Status in pam source package in Focal: Fix Committed Status in pam source package in Groovy: Fix Committed Status in pam source package in Hirsute: Fix Committed Status in pam source package in Impish: Fix Committed Bug description: [IMPACT] There is a known issue in pam_tally2 which may cause an account to be lock down even with correct password, in a busy node environment where simultaneous logins takes place (https://github.com/linux-pam/linux-pam/issues/71). There are already two customer cases from Canonical clients complaining about this behavior (00297697 and 00303806). Also, potentially, this will cause further problems in the future, since both STIG benchmarks and CIS benchmarks rely on pam_tally2 to lock accounts when wrong passwords are used. And both benchmarks - but specially STIG - requires use of a lot of audit rules, which can lead to the busy node environment. The issue impacts all pam_tally2 versions distributed in all currently supported Ubuntu versions and also the next unreleased one. Note that, according to https://github.com/linux-pam/linux-pam/issues/71, there is no plan to fix this issue! [FIX] This fix proposes to add pam_faillock module to the PAM package, so users of pam_tally2 having issues can migrate to pam_faillock. We also plan to modify the current STIG benchmarks to rely on pam_faillock instead of pam_tally2, but in order to do so, we need the pam_faillock module to be available. Note that we don't propose to remove pam_tally2, since not every user of this module is affected. [TEST] Tested on a VM installed with Focal server iso and on another with Bionic server iso. Enabled pam_faillock module as recommeded by its man page. Then tried to log over ssh with an incorrect password, until the account got locked. Waited for the configured grace time to unlock and logged in using the correct password. Note that, since the pam_tally2 issue is caused by a racing condition, with a hard to recreate environment (we could not even reproduce it with pam_tally2), we could not reproduce the conditions to test pam_faillock with. [REGRESSION POTENTIAL] The regression potential for this is small, since we're not removing the old pam_tally2 module, just adding another one. So anyone still using pam_tally2 will be able to do so. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pam/+bug/1927796/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
