-
Notifications
You must be signed in to change notification settings - Fork 686
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
mount_option_boot_nosuid fails to remediate with Ansible #11933
Comments
From the Ansible output above we can see that only one task of the tasks was skipped and that was the one where the mount_info Ansible fact is created manually if it doesn't exist. But as we can see from the task right above the skipped task the mount_info fact exists in this case, and we can see that the task that actually contains the mount module invocation which is the last task in the output has been executed and ended in the changed state. So I think the remediation actually isn't skipped and even could be performed correctly. We need to investigate if there is any interference of other tasks with this rules's tasks or anything happening between the time of remediation and a new scan. |
I thinkt that the Ansible Tasks for the rule mount_option_boot_nosuid are in conflict with Ansible Task remediating rule mount_option_nodev_nonroot_local_partitions which is executed after them. I have done an experiment in which I have removed mount_option_nodev_nonroot_local_partitions from the anssi controls file and rebuild content and executed the given contest test in a lab environment using this command:
In this experiment the rule mount_option_boot_nosuid is passing in the final scan. Could it be that the Ansible Task for mount_option_nodev_nonroot_local_partitions reinserts the originally gathered ansible_facts but the reality changed meanwhile so it reinserts the original options? Look to the beaker output in the original run:
|
This patch changes the Ansible code for rule mount_option_nodev_nonroot_local_partitions so that Ansible id forced to refresh facts about mount points right before running the Ansible Task for this rule. The data in facts that were collected at the beginning of the play can be outdated at point when this Ansible Task is executed if there is some other Ansible Task that changes mount points, for example if the Ansible Tasks for rule mount_option_boot_nosuid is before the Ansible Task for rule mount_option_nodev_nonroot_local_partitions. Fixes: ComplianceAsCode#11933
This patch changes the Ansible code for rule mount_option_nodev_nonroot_local_partitions so that Ansible id forced to refresh facts about mount points right before running the Ansible Task for this rule. The data in facts that were collected at the beginning of the play can be outdated at point when this Ansible Task is executed if there is some other Ansible Task that changes mount points, for example if the Ansible Tasks for rule mount_option_boot_nosuid is before the Ansible Task for rule mount_option_nodev_nonroot_local_partitions. Fixes: ComplianceAsCode#11933
In the latest runs, this still seems to be an issue. |
There is a similar issue with image builder on this rule as well. Is there a possibility they are related? |
I can confirm the issue with the rule appears now in Imagebuilder tests during daily productization. |
I created a different issue to track the problem with Imagebuilder. This issue was originally about Ansible remediation of the rule, Imagebuilder uses Bash remediation. |
Description of problem:
Remdiation of the rule mount_option_boot_nosuid does not happen because it gets skipped due to conditionals. But the scan after the remediation marks this rule as failing. That suggests that the remediation should happen.
Here is the relevant output from the Ansible playbook. This happens on RHEL 9.4 when anssi_bp28_high profile is selected:
SCAP Security Guide Version:
Stabilization-v0.1.73, commit 0b096bc
Operating System Version:
RHEL 8 and 9
Steps to Reproduce:
1.remediate anssi_bp28_high or stig through Ansible playbook
2.perform oscap scan of the same profile
Actual Results:
rule mount_option_boot_nosuid remediation is skipped but in the end the rule is reported as failed
Expected Results:
The remediation is performed correctly and the final scan shows rule as passing.
Additional Information/Debugging Steps:
Note that for ANSSI High profile, the similar thing happens for the rule mount_option_boot_noexec.
The text was updated successfully, but these errors were encountered: