Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/index.php/Reporting_Bug_Guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#67347 - [pambase][pam] pam_faillock options

Attached to Project: Arch Linux
Opened by loqs (loqs) - Tuesday, 21 July 2020, 15:15 GMT
Last edited by Andreas Radke (AndyRTR) - Tuesday, 30 March 2021, 12:41 GMT
Task Type Bug Report
Category Packages: Testing
Status Closed
Assigned To David Runge (dvzrv)
Levente Polyak (anthraxx)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 12
Private No

Details

Description:
pam_faillock.so does not support onerr or file options.
It uses dir with default /var/run/faillock containing one file per username.
The deny option is not specified and is commented out in /etc/security/faillock.conf so I believe accounts except root will be locked after three failed attempts in 15 minutes with access re-enabled after 10 minutes. Should such a change warrant a news item?
etc/security/faillock.conf is not in the backup array of pam

Additional info:
* pambase 20200721.1-1
* pam 1.4.0-2
This task depends upon

Closed by  Andreas Radke (AndyRTR)
Tuesday, 30 March 2021, 12:41 GMT
Reason for closing:  Fixed
Comment by loqs (loqs) - Tuesday, 21 July 2020, 16:39 GMT
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.
Comment by Leonard König (LeonardK) - Wednesday, 22 July 2020, 20:48 GMT
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.
Comment by Gene (GeneC) - Friday, 24 July 2020, 20:01 GMT
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.





Comment by loqs (loqs) - Friday, 24 July 2020, 20:13 GMT
@GeneC can you produce a failed authentication to be recorded by faillock with those changes?
Comment by Gene (GeneC) - Friday, 24 July 2020, 20:27 GMT
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.
Comment by Gene (GeneC) - Friday, 24 July 2020, 20:33 GMT
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.

Comment by loqs (loqs) - Friday, 24 July 2020, 20:33 GMT
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
Comment by loqs (loqs) - Friday, 24 July 2020, 20:38 GMT
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
Comment by Gene (GeneC) - Friday, 24 July 2020, 20:39 GMT
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.
Comment by loqs (loqs) - Friday, 24 July 2020, 20:47 GMT
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.
Comment by Gene (GeneC) - Friday, 24 July 2020, 20:52 GMT
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?
Comment by loqs (loqs) - Friday, 24 July 2020, 21:14 GMT
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
Comment by Gene (GeneC) - Friday, 24 July 2020, 21:17 GMT
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?
Comment by Gene (GeneC) - Friday, 24 July 2020, 21:47 GMT
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
Comment by loqs (loqs) - Friday, 24 July 2020, 23:17 GMT
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.
Comment by loqs (loqs) - Saturday, 25 July 2020, 03:39 GMT
pambase, based on second example from pam_faillock man page.
pam, removed executable bit from tmpfiles config.
Comment by Gene (GeneC) - Sunday, 26 July 2020, 16:23 GMT
**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
Comment by loqs (loqs) - Tuesday, 04 August 2020, 20:07 GMT
substack and skip based approaches to adding pam_faillock.so and pam_systemd_home.so.
Comment by loqs (loqs) - Sunday, 09 August 2020, 14:35 GMT Comment by Tobias Powalowski (tpowa) - Wednesday, 12 August 2020, 19:41 GMT
Added changes to pam-1.4.0-3 and pambase-20200721.1-2.
Comment by Jan Alexander Steffens (heftig) - Wednesday, 12 August 2020, 20:09 GMT
@loqs Your skip implementation doesn't look sane. You're skipping over pam_systemd_home if pam_unix succeeds.
Comment by loqs (loqs) - Wednesday, 12 August 2020, 20:32 GMT
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
Comment by Jan Alexander Steffens (heftig) - Wednesday, 12 August 2020, 20:45 GMT
Yes, thanks. I misunderstood how it works.
Comment by Emil (xexaxo) - Tuesday, 09 February 2021, 15:02 GMT
AFAICT pambase is fixed with v20200721.1-2 and sddm is fixed with v0.19.0-2 (aka  FS#68520 )
Comment by loqs (loqs) - Tuesday, 09 February 2021, 15:20 GMT
@xexaxo pam_faillock support is fixed FS#65819 remains an issue for pambase.

Loading...