Accept required and requisite control flag for pam_pwhistory #10175
Conversation
marcusburghardt
added
RHEL9
|
Start a new ephemeral environment with changes proposed in this pull request: Fedora Environment Oracle Linux 8 Environment |
marcusburghardt
force-pushed
the
pwhistory_control
branch
from
d874e80 to
6376ce4
Compare
|
The #10021 is also related to this. |
...counts/accounts-pam/locking_out_password_attempts/var_password_pam_remember_control_flag.var
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
@marcusburghardt I'm okay leaving the consolidation of the variables to unique selector to a future PR.
...ocking_out_password_attempts/accounts_password_pam_pwhistory_remember_password_auth/rule.yml
Outdated
Show resolved
Hide resolved
In RHEL8.8 and RHEL9.2 it was introduced a new authselect feature to enable pam_pwhistory module. Previously, it was enabled by creating a custom authselect profile. Historically, the control flag used to enable pam_pwhistory.so was "required". However, the authselect feature uses "requisite". These two control flags are correct and the differences relies on how the module result will be reported to the user, without affecting the module action. Therefore, the assessment should also pass if required is used.
It was noticed a possible scenario where the feature is introduced in a system with a custom profile based in older authselect versions. In these cases, the remediation can't be safely ensured and the custom profile should be updated by the administrator. Included this information in the rule warning. Co-authored-by: Watson Yuuma Sato <[email protected]>
marcusburghardt
force-pushed
the
pwhistory_control
branch
from
53d8181 to
acfec9a
Compare
There was a problem hiding this comment.
Hello @marcusburghardt and thanks for this fix. I have tested it on 8.7 -> 8.8 as well as on 9.1 -> 9.2 and it works nicely.
Just a small note, see the comment and it is ready to be merged.
marcusburghardt
force-pushed
the
pwhistory_control
branch
from
acfec9a to
f02788a
Compare
|
@marcusburghardt Please note that the profile stability test was passing even before you shuffled the ssh_keys_passphrase_protected lines in the /tests/data/profile_stability/rhel8/stig.profile. The profile stability test is based on set comparison, the order of lines does not matter. I have tested it - I have checked out the master branch before your PR and the profile stability test for RHEL 8 was passing. |
|
Code Climate has analyzed commit f02788a and detected 0 issues on this pull request. The test coverage on the diff in this pull request is 100.0% (50% is the threshold). This pull request will bring the total coverage in the repository to 49.5% (0.0% change). View more on Code Climate. |
Yes @vojtapolasek , I am aware that this ordering does not affect the result of the test, but I still can't be complacent with the issue that caused the line to be reordered in this PR. We should rely on the I believe you missed my last comment in the thread, where I informed that the last commit was already updated and the condition on which I agreed to make this manual change in this PR. In any case, the source of issue will now be resolved by #10182, which should be merged as soon as possible to avoid possible "extra updates" in future PRs related to changes in STIG profiles. |
|
Great. I will merge it as soon as all tests pass.a |
Description:
In RHEL8.8 and RHEL9.2 it was introduced a new
authselectfeature to enablepam_pwhistorymodule.Before the feature, the module was enabled by creating a custom
authselectprofile.Historically, the control flag used to enable
pam_pwhistory.sowasrequired.However, the
authselectfeature usesrequisiteinstead.These two control flags are correct and the differences are only about the module reporting, without affecting its effect.
Therefore, the assessment should pass if either
requiredorrequisiteis used.Rationale:
Thanks to @vojtapolasek researches, it was noticed a possible scenario where the feature is introduced in a system with a custom profile based in older
authselectversions. In these cases, the system would be compliant by using therequiredcontrol flag. However, since the rule is expecting onlyrequisite, it will fail and the remediation would be executed.However, in these cases, the remediation can't be safely ensured because the remediation will try to use the feature but the custom profile is not aware of the feature. The custom profile should be updated or recreated by the administrator.
Review Hints:
This is a corner case difficult to be tested.
Basically, it would be necessary to scan and remediate a system with the
authselectpackage in a old version, like in the current RHEL8.7.Then, the system should be updated to use the new
authselectpackage version, which includes thewith-pwhistoryfeature.Before this patch, the scan with the new
authselectpackage should fail because the control flag is set torequired. Consequently, the remediation will fail due to the above mentioned issue.After this patch, the scan with the new
authselectpackage will pass because bothrequiredandrequisiteare accepted. No remediation will be necessary.