Currently 4.1.1.2 and 4.1.1.3 have numerous problems.
Current solution does not cater for multiple kernels being returned. This can result in an array being returned which the task "when" conditions do not handle correctly.
This will result in the tasks always triggering regardless of current state.
Current check only looks for audit=1 or 0 when it can also be "Off".
Also, current devel (e2738f0) version of code for 4.1.1.3 actually checks the wrong variable which was registered for 4.1.1.2.
Cause
Multiple kernels will return an array rather than a single value.
E.g. the following example for 4.1.1.2
grubby --info=ALL | grep args | sed -n 's/.audit=([[:alnum:]]+)./\1/p'
These are not handled correctly by the current conditions.
Expected behaviour
4.1.1.2 should handle a single value or an array of values from multiple kernels. It should also look for 0 and "off" (case insensitive)
4.1.1.3 should handle a single value or an array of values from multiple kernels.
Both should handle an empty response
Both should be idempotent
Actual behaviour
4.1.1.2 and 4.1.1.3 Will always trigger a change regardless of individual values if multiple kernels returned
4.1.1.3 Checking wrong variable (rhel9cis_4_1_1_2_grubby_curr_value_audit_linux)
Controls affected
This prevents 4.1.1.2 and 4.1.1.3 from being set correctly.
Environment
Branch: devel
Ansible: core 2.15.8
Target host python: 3.9.18
Ansible Server Python: 3.11.7
Additional target host OS: Alma 9
Additional notes
Whilst this fix will improve the current situation markedly it isn't a perfect solution. Note that if one of the Kernel audit backlog options is greater than the default, currently 8192, and one is below the default, all will be set to the default.
Ideally only the entries that are lower will be altered.
This can perhaps be addressed in a future update.
Possible solution
I have a proposed solution for which I will be creating a Pull Request.
Issue
Currently 4.1.1.2 and 4.1.1.3 have numerous problems. Current solution does not cater for multiple kernels being returned. This can result in an array being returned which the task "when" conditions do not handle correctly. This will result in the tasks always triggering regardless of current state. Current check only looks for audit=1 or 0 when it can also be "Off". Also, current devel (e2738f0) version of code for 4.1.1.3 actually checks the wrong variable which was registered for 4.1.1.2.
Cause
Multiple kernels will return an array rather than a single value. E.g. the following example for 4.1.1.2
And similarly for 4.1.1.3
These are not handled correctly by the current conditions.
Expected behaviour
4.1.1.2 should handle a single value or an array of values from multiple kernels. It should also look for 0 and "off" (case insensitive) 4.1.1.3 should handle a single value or an array of values from multiple kernels. Both should handle an empty response Both should be idempotent
Actual behaviour
4.1.1.2 and 4.1.1.3 Will always trigger a change regardless of individual values if multiple kernels returned
4.1.1.3 Checking wrong variable (rhel9cis_4_1_1_2_grubby_curr_value_audit_linux)
Controls affected
This prevents 4.1.1.2 and 4.1.1.3 from being set correctly.
Environment
Additional notes
Whilst this fix will improve the current situation markedly it isn't a perfect solution. Note that if one of the Kernel audit backlog options is greater than the default, currently 8192, and one is below the default, all will be set to the default.
Ideally only the entries that are lower will be altered.
This can perhaps be addressed in a future update.
Possible solution
I have a proposed solution for which I will be creating a Pull Request.