Arch Linux

pam_faillock.so might also need:
* tmpfiles.d snippet to create /run/faillock/
* https://github.com/linux-pam/linux-pam/commit/395915dae1571e10e2766c999974de864655ea3a
* rework /etc/pam.d/system-auth so pam_faillock.so records authentication failures.

Possibly drop its use in the default pamstack?
Edit:
A news item may be warranted by the removal of pam_tally, pam_tally2 and pam_cracklib which if used in a custom pamstack would cause authentication failure, potentially causing a user to be locked out of the system.

Re tally2 and such: This breaks at least pambase-homed right now. This is just an AUR package but it would be nice if this could be worked around somehow. I don't know the best way how to proceed, however. Would it make sense to make pam 1.4.0-2 on a specific version of pambase, namely 20200721.1? This would prevent issues with pam and pambase being out of sync (maybe this is even possible with a 'standard' setup if we have unlucky mirror synchronizations?) pambase-homed already provides pambase=20190105.1 thus preventing an unwanted mismatch.

Looks like pambase just needs :
1) /etc/pam.d/system-login:
change:
auth required pam_faillock.so onerr=succeed file=/var/log/tallylog
to
auth required pam_faillock.so


2) sddm needs to update it's file:
/etc/pam.d/sddm-autologin
change:
auth required pam_tally.so file=/var/log/faillog onerr=succeed
to
auth required pam_faillock.so


Since the security faillock policy is set in /etc/security/faillock.conf, admins can adjust for local needs there.

@GeneC can you produce a failed authentication to be recorded by faillock with those changes?

As per your first comment /run/faillock needs to be created (manually or otherwise). I did not make that change yet.
So, I can get it to record in system journal but nothing is written to /run/faillock/xx.

Do you know what permissions are appropriate for /run/faillock (i.e. what to put in tmpfiles.d/xx)?
man pages for pam_faillock and faillock weren't completely clear to me ... or I need more coffee.

That is an improvement on what I was producing which was no output.

The man page [1] documents much more invasive changes required to the pam stack.

[1] https://linux.die.net/man/8/pam_faillock

Fedora creates /run/faillock with a tmpfiles.d snippet

d /run/faillock 0755 root root -

[1] https://src.fedoraproject.org/rpms/pam/blob/master/f/pamtmp.conf

Well to be clear,- what I did to test was ssh to test machine1 as tweaked the pam file as above, then watched journal.
I then ssh to a second machine2 - now on this computer, as user2 i did: % ssh user1@machine1.
That generated the failure log recorded something like: sshd[x]: pam_unix(sshd:auth): authentication failure;...

This may be different via local login.

I should have been clearer as well. I receive the syslog message from pam_unix.so but I have not produced any output from pam_faillock.so.
What I am suspecting is that in the current configuration pam_faillock.so is behaving the same as pam_allow.so.

I tried this: manually create /run/faillock.
repeat as above - login failure recorded in journal, but now a file is created: /run/faillock/user1

it is an empty file. I was rather expecting something inside the file ... but that's what I get.
My /etc/security/faillock.conf is the default - which has only comments.

Perhaps un-comment the 'audit' item in the conf file?

I can generate a file /run/faillock/username if the login is authenticated.
Edit:
Editing /etc/pam.d/system-login as follows as a test

auth [success=1 default=bad] pam_unix.so
auth [default=die] pam_faillock.so authfail
auth sufficient pam_faillock.so authsucc
#auth include system-auth

authenticated logins generate an empty /run/faillock/username
failed logins generate a /run/faillock/username with a binary record
the details from the record can be read by faillock

without reading more (doc/code) this is just a guess - perhaps that file is used to tag the last login time (successful or not) only - as a way to enforce the time rules for failed logins?

Its pretty clear from the code[1], best I can tell anyway, it does read/write into the file and keeps a tally and details of all attempts. Calling it a day on this for now.

[1] https://github.com/linux-pam/linux-pam/tree/master/modules/pam_faillock

For pam patch from my first comment. Dropped cracklib depends as module is no longer built. Added the tmpfiles snippet to create /run/faillock.
For pambase using the first example in the pam_faillock man page.

Results are now more as I would expect. Still needs much more testing.
Edit:
Moved pam_env.so up to avoid it being skipped.

pambase, based on second example from pam_faillock man page.
pam, removed executable bit from tmpfiles config.

**UPdate* - this may be due to not restarting systemd etc. After rebooting to ensure all services are started fresh - below is a non issue.
Sorry for noise.


-- fixed after reboot

I'm getting additional errors in the log when user logs in
(libpam.so.0 exists and is a link to /usr/lib/libpam.so.0.85.1 but seems to be wrong version - 1.3.2 instead of 1.4.0 )

--
PAM unable to dlopen(/usr/lib/security/pam_unix.so): /usr/lib/libpam.so.0: version `LIBPAM_MODUTIL_1.3.2' not foun
d (required by /usr/lib/security/pam_unix.so)
PAM adding faulty module: /usr/lib/security/pam_unix.so
PAM failed: Module is unknown
user@1000.service: Failed to set up PAM session: Operation not permitted
user@1000.service: Failed at step PAM spawning /usr/lib/systemd/systemd: Operation not permitted

substack and skip based approaches to adding pam_faillock.so and pam_systemd_home.so.

Proposed solution:
https://github.com/loqs/pam/tree/update
https://github.com/loqs/pambase/tree/update-jump or https://github.com/loqs/pambase/tree/update-substack

Added changes to pam-1.4.0-3 and pambase-20200721.1-2.

@loqs Your skip implementation doesn't look sane. You're skipping over pam_systemd_home if pam_unix succeeds.

The user is managed by systemd_home or passwd. The upstream example [1] uses sufficient in auth, account and password, which would return immediately so only unix or systemd_home is required to succeed.
I did not use sufficient as that would skip entries e.g. gdm_password has pam_gnome_keyring.so after system-local-login.

[1] https://www.freedesktop.org/software/systemd/man/pam_systemd_home.html

Yes, thanks. I misunderstood how it works.

AFAICT pambase is fixed with v20200721.1-2 and sddm is fixed with v0.19.0-2 (aka  FS#68520 )

@xexaxo pam_faillock support is fixed  FS#65819  remains an issue for pambase.