pam_faillock settings are impractical

[trevor-vaughan]

Description of problem:

The pam_faillock setting of unlock_time=0 for both users and root is impractical.

By setting this value, users are almost guaranteed to be permanently locked out of their system. This allows attackers to DOS systems at large.

The settings for users should be set to something more practical particularly if users are applying the rest of the settings as well.

I would suggest users have a 1 hour lock time and root to have a 15 minute lock time (root shouldn't be able to login remotely anyway). If an attacker can brute force a password with that window then the password was excessively weak. Additionally, this information is easy to detect in logs.

SCAP Security Guide Version:

da57b9e50cfd6630116f169355aa14a4f5f54adf

[yuumasato]

For the STIG profiles, this can be discussed with DISA.

[trevor-vaughan]

@yuumasato Is this something that this group is willing to do? My attempts at making these types of arguments upstream have generally been met with "we know better than you and we're not changing" (paraphrased).

Also, IIRC, the STIGs are proposed by the vendor (but DISA might do whatever they like).

[yuumasato]

@yuumasato Is this something that this group is willing to do?

Sure, we've been discussing other issues DISA already. CCing @carlosmmatos and @ggbecker for awareness, I should've pinged them in the previous comment.

My attempts at making these types of arguments upstream have generally been met with "we know better than you and we're not changing" (paraphrased).

@trevor-vaughan My apologies if we (or I) sound like that, it is not the intention. Your feedback is very much welcome and provides very good insight on use cases in the field. About changing or not the profile, I'm getting mixed signals from the community. Updating the upstream profile before DISA releases an update containing it caused discussions in the past (wether it should follow the STIG to the letter or not).

Also, IIRC, the STIGs are proposed by the vendor (but DISA might do whatever they like).

That is my understanding as well. Carlos and Becker can provide more details about the process.

[carlosmmatos]

@trevor-vaughan I can bring this up to DISA on your behalf if you would like. Also, I don't believe that only the vendor is allowed to make recommendations to the STIG, they do have the same ticketing queue that we get put into when we submit changes or suggestions.

and yes --- DISA be doing whatever they like lol.. we're just trying to do our best to keep our lines open with them. They have been pretty good for the past year or so.

[marcusburghardt]

Since it is totally fine to bring this topic to the authorities responsible for the Benchmarks, it is not ensured the suggestion will be accepted by them. I saw the CIS is more flexible about this pam_faillock.so parameters while the STIG is more restrictive. This variation is expected among other benchmarks too. I don't think there is right or wrong here, but a best combination of controls and their respective settings for each case.

If you follow a benchmark, you should go with their requirements. However, it is always possible to create you tailored file based on the preferred benchmark. The project offers these capabilities to create new policies based on existing ones. For example, all these mentioned parameters can be changed via variables.

Tailoring Documentation: https://static.open-scap.org/openscap-1.3/oscap_user_manual.html#_tailoring

STIG references: https://www.stigviewer.com/stig/red_hat_enterprise_linux_8/2021-12-03/finding/V-230335 https://www.stigviewer.com/stig/red_hat_enterprise_linux_8/2021-12-03/finding/V-230337

I also recommend to bring this topic to discussion in the CIS community: https://workbench.cisecurity.org/