[SRU]pam_tally2 can cause accounts to be locked by correct password. pam_faillock use is the recommended fix

Status changed to 'Confirmed' because the bug affects multiple users.

The debdiffs in comment #1 currently create a multiarch manpage collision because of a pam packaging particularity. (See bug 1558597 for an example)

I will update the debdiffs to correct the issue and will post them here once done.

I have uploaded packages for processing by the SRU team.

Ok, so this adds quite a big piece of new code, so normally I would be a bit worried about the maintainability of this. Seeing that Marc is the sponsor here, I will quietly assume that the maintainability of the new functionality is fine from the security team's POV and that this will not be an additional burden.

Hello Richard, or anyone else affected,

Accepted pam into hirsute-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/pam/1.3.1-5ubuntu6.21.04.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-hirsute to verification-done-hirsute. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-hirsute. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

Hello Richard, or anyone else affected,

Accepted pam into groovy-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/pam/1.3.1-5ubuntu6.20.10.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-groovy to verification-done-groovy. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-groovy. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

Hello Richard, or anyone else affected,

Accepted pam into focal-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/pam/1.3.1-5ubuntu4.2 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-focal to verification-done-focal. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-focal. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

Hello Richard, or anyone else affected,

Accepted pam into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/pam/1.1.8-3.6ubuntu2.18.04.3 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-bionic. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

All autopkgtests for the newly accepted pam (1.1.8-3.6ubuntu2.18.04.3) for bionic have finished running.
The following regressions have been reported in tests triggered by the package:

lxc/3.0.3-0ubuntu1~18.04.1 (amd64)
openssh/1:7.6p1-4ubuntu0.3 (i386, armhf, arm64, s390x, amd64, ppc64el)
postgresql-10/10.16-0ubuntu0.18.04.1 (armhf)

Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-migration/bionic/update_excuses.html#pam

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

All autopkgtests for the newly accepted pam (1.3.1-5ubuntu6.20.10.1) for groovy have finished running.
The following regressions have been reported in tests triggered by the package:

update-motd/3.6-0ubuntu7 (armhf, arm64, s390x, amd64, ppc64el)

Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-migration/groovy/update_excuses.html#pam

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

All autopkgtests for the newly accepted pam (1.3.1-5ubuntu4.2) for focal have finished running.
The following regressions have been reported in tests triggered by the package:

update-motd/3.6-0ubuntu6.1 (armhf, amd64, s390x, arm64, ppc64el)
kopanocore/8.7.0-7ubuntu1 (amd64)

Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-migration/focal/update_excuses.html#pam

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

All autopkgtests for the newly accepted pam (1.3.1-5ubuntu6.21.04.1) for hirsute have finished running.
The following regressions have been reported in tests triggered by the package:

update-motd/3.7 (amd64, arm64, armhf, s390x, ppc64el)
systemd/247.3-3ubuntu3 (armhf)

Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-migration/hirsute/update_excuses.html#pam

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

Tested pam_faillock module for pam on bionic.

Test consisted on setting up pam_faillock with the following configuration, as described in the man page:

/etc/security/faillock.conf file example:
deny=4
unlock_time=1200
silent

/etc/pam.d/config file example:
auth required pam_faillock.so preauth
# optionally use requisite above if you do not want to prompt for the password
# on locked accounts
auth sufficient pam_unix.so
auth [default=die] pam_faillock.so authfail
auth required pam_deny.so
account required pam_faillock.so
# if you drop the above call to pam_faillock.so the lock will be done also
# on non-consecutive authentication failures
account required pam_unix.so

A new user 'joas' was created and its password set. Then, initially, 4 logins were made through ssh and terminal, using the correct password. All were successful.

User 'joas' was, then, logged out and 4 attempts to login with incorrect password were made. Since pam_faillock module was set to lock on the 4th incorrect attempt, another try was done, this time with the correct password.

After confirming that the 'joas' account was locked, by trying, with the correct password, additional times, the superuser account was used to display the account stats ('faillock --user joas') and then used to unlock the 'joas' account ('faillock --user joas --reset').

Then, again 4 logins were made using the correct password, in order to check it was successfully authenticating.

Another test consisted on typing the wrong password 3 times, then typing the correct one, to make sure the PAM module was properly resetting the counter.

Additional tests done on bionic: after changing the parameters set in /etc/security/faillock.conf to:
deny=2
unlock_time=20

By trying to authenticate with the wrong password 2 times, it was verified that the account was locked for the amount of time set to the unlock_time parameter (20s).

By following the same test procedure done in #18 and #19, the Focal build of pam_faillock was successfully validated.

By following the same test procedure done in #18 and #19, the Groovy build of pam_faillock was successfully validated.

By following the same test procedure done in #18 and #19, the Hirsute build of pam_faillock was successfully validated.

Performing verification for Bionic

I enabled -proposed and installed libpam-modules libpam-modules-bin libpam-runtime libpam0g version 1.1.8-3.6ubuntu2.18.04.3

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 00:57:10 RHOST 192.168.122.1 V
2021-05-19 00:57:12 RHOST 192.168.122.1 V
2021-05-19 00:57:16 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 Bionic.

Performing verification for Focal

I enabled -proposed and installed libpam-modules libpam-modules-bin libpam-runtime libpam0g version 1.3.1-5ubuntu4.2

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 00:31:08 RHOST 192.168.122.1 V
2021-05-19 00:31:13 RHOST 192.168.122.1 V
2021-05-19 00:31:17 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 Focal.

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.

Performing verification for Groovy

I enabled -proposed and installed libpam-modules libpam-modules-bin libpam-runtime libpam0g version 1.3.1-5ubuntu6.20.10.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 02:08:53 RHOST 192.168.122.1 V
2021-05-19 02:08:58 RHOST 192.168.122.1 V
2021-05-19 02:09:02 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 Groovy.

Autopkgtests in comments #14 to #17 passed on retries except for openssh which appears to be failing because of a date issue, which is unrelated to the pam SRU.

This bug was fixed in the package pam - 1.3.1-5ubuntu7

---------------
pam (1.3.1-5ubuntu7) impish; urgency=medium

  * Backport pam_faillock module from pam 1.4.0 (LP: #1927796)
    - debian/patches-applied/add_pam_faillock.patch: add module.
    - debian/patches-applied/pam_faillock_create_directory: create dir
      before creating file in modules/pam_faillock/faillock.c.
    - debian/rules: set execute permissions on pam_faillock test.
    - debian/libpam-modules-bin.install: install faillock binary and man
      page.

 -- Richard Maciel Costa <email address hidden> Thu, 08 Apr 2021 07:06:27 -0400

The verification of the Stable Release Update for pam has completed successfully and the package is now being released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

This bug was fixed in the package pam - 1.3.1-5ubuntu6.21.04.1

---------------
pam (1.3.1-5ubuntu6.21.04.1) hirsute; urgency=medium

  * Backport pam_faillock module from pam 1.4.0 (LP: #1927796)
    - debian/patches-applied/add_pam_faillock.patch: add module.
    - debian/patches-applied/pam_faillock_create_directory: create dir
      before creating file in modules/pam_faillock/faillock.c.
    - debian/rules: set execute permissions on pam_faillock test.
    - debian/libpam-modules-bin.install: install faillock binary and man
      page.

 -- Richard Maciel Costa <email address hidden> Thu, 08 Apr 2021 07:06:27 -0400

This bug was fixed in the package pam - 1.3.1-5ubuntu6.20.10.1

---------------
pam (1.3.1-5ubuntu6.20.10.1) groovy; urgency=medium

  * Backport pam_faillock module from pam 1.4.0 (LP: #1927796)
    - debian/patches-applied/add_pam_faillock.patch: add module.
    - debian/patches-applied/pam_faillock_create_directory: create dir
      before creating file in modules/pam_faillock/faillock.c.
    - debian/rules: set execute permissions on pam_faillock test.
    - debian/libpam-modules-bin.install: install faillock binary and man
      page.

 -- Richard Maciel Costa <email address hidden> Thu, 08 Apr 2021 07:06:27 -0400

This bug was fixed in the package pam - 1.3.1-5ubuntu4.2

---------------
pam (1.3.1-5ubuntu4.2) focal; urgency=medium

  * Backport pam_faillock module from pam 1.4.0 (LP: #1927796)
    - debian/patches-applied/add_pam_faillock.patch: add module.
    - debian/patches-applied/pam_faillock_create_directory: create dir
      before creating file in modules/pam_faillock/faillock.c.
    - debian/rules: set execute permissions on pam_faillock test.
    - debian/libpam-modules-bin.install: install faillock binary and man
      page.

 -- Marc Deslauriers <email address hidden> Thu, 08 Apr 2021 07:06:27 -0400

Hey Marc! What about the postgresql-10/armhf autopkgtest failure for bionic?

Oh, I seem to have overlooked that one. We are hitting the exact same issue with the new postgresql releases, so it's unrelated to the pam SRU:

https://bugs.launchpad.net/ubuntu/+source/postgresql-12/+bug/1928773/comments/2

This bug was fixed in the package pam - 1.1.8-3.6ubuntu2.18.04.3

---------------
pam (1.1.8-3.6ubuntu2.18.04.3) bionic; urgency=medium

  * Backport pam_faillock module from pam 1.4.0 (LP: #1927796)
    - debian/patches-applied/add_pam_faillock.patch: add module.
    - debian/patches-applied/pam_faillock_create_directory: create dir
      before creating file in modules/pam_faillock/faillock.c.
    - debian/rules: set execute permissions on pam_faillock test.
    - debian/libpam-modules-bin.install: install faillock binary and man
      page.

 -- Marc Deslauriers <email address hidden> Thu, 08 Apr 2021 07:27:58 -0400