Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

pam.d: enable pam_faillock as replacement for pam_tally2 #17

Merged
merged 2 commits into from
Mar 23, 2021

Conversation

pothos
Copy link
Member

@pothos pothos commented Mar 17, 2021

In the PAM 1.5 update the deprecated pam_tally2 module had to be
removed. Since pam_faillock should be used as a replacement and it's
included in the image already, set it up by default.
The "faillock" command will show the current state and the password
login prompt is replaced with a message that the account is locked
for X minutes. This only applies to local password login.

With tally there was no limit for wrong password login attempts.
Yes with faillock the default is restricted to three attempts within
15 minutes which lead to a 10 minute account locking. This can be
disturbing for the real user and we can reduce the impact by choosing
a shorter lock duration of one minute and allow up to 5 wrong
passwords per two minutes (i.e., spread over 15 minutes this means
around 35 wrong attempts are possible).

How to use/testing done

Copy the file to /etc/pam.d/system-auth for testing.
Create a test user and set a password: useradd test; passwd test.
Now log in via SSH with a wrong password and get locked for some time.

In the PAM 1.5 update the deprecated pam_tally2 module had to be
removed. Since pam_faillock should be used as a replacement and it's
included in the image already, set it up by default.
The "faillock" command will show the current state and the password
login prompt is replaced with a message that the account is locked
for X minutes. This only applies to local password login.
@pothos pothos requested a review from a team March 17, 2021 13:18
Copy link

@margamanterola margamanterola left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@pothos
Copy link
Member Author

pothos commented Mar 17, 2021

I just noticed that the pam_tally2 behavior without an explicit deny=X is to not deny at all while pam_faillock has deny=3 as implicit default. This is a change in behavior.

With tally there was no limit for wrong password login attempts.
Yes with faillock the default is restricted to three attempts within
15 minutes which lead to a 10 minute account locking. This can be
disturbing for the real user and we can reduce the impact by choosing
a shorter lock duration of one minute and allow up to 5 wrong
passwords per two minutes (i.e., spread over 15 minutes this means
around 35 wrong attempts are possible).
@pothos
Copy link
Member Author

pothos commented Mar 22, 2021

I added a commit to relax the behavior.

@pothos pothos requested a review from a team March 22, 2021 19:04
@margamanterola
Copy link

This still LGTM. I was wondering it was better to set this stuff in the config file instead, but I guess this way it's more obvious.

@pothos pothos merged commit bbe3f25 into flatcar-master Mar 23, 2021
@pothos pothos deleted the kai/pam-faillock branch March 23, 2021 10:11
pothos added a commit to flatcar-archive/coreos-overlay that referenced this pull request Mar 23, 2021
This pulls in
flatcar/baselayout#17
to enable the pam_faillock module as replacement for pam_tally2.
The "faillock" binary can be used to see the login attempts and
account lock status which before was available with the pam_tally
command. While the tally defaults did not temporarily lock the
account on wrong password login attempts, this is done by default
with faillock. However, the default behavior was relaxed to allow
more wrong attempts and have a shorter lock time span.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants