Add arg_minimal_value variable to grub2_bootloader_argument template

[macko1]

Fixes #13923

Implementation

1. new variable arg_minimal_value
2. update templates shared/templates/grub2_bootloader_argument/
   2a. update template.py
   • minor code cleanup + implementation of arg_minimal_value
     2b. update oval.template
   • biggest changes -> I wanted to make strictly additive changes so the original tests wouldn't break.
   • lots of comments, which can be removed or trimmed in the end, but I think they'll help a lot during review
   • originally arg_value is tested by regex for exact string match, arg_minimal_value tests integer >= comparison
     2c. update bash.template, ansible.template, kickstart.template, blueprint.template
   • basically just adding arg_minimal_value to the selection for setting ARG_NAME_VALUE
3. update docs
4. implementation in linux_os/guide/auditing/grub2_audit_backlog_limit_argument/rule.yml

HTT

1. ./build_product rhel9
2. Test in VM, stock UBI don't ship with gutbby or grub2-common so automatus will fail

./automatus.py rule --libvirt qemu:///session <vm> --datastream ../build/ssg-rhel9-ds.xml grub2_audit_backlog_limit_argument

[openshift-ci]

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

[github-actions]

This datastream diff is auto generated by the check Compare DS/Generate Diff

Click here to see the full diff

OVAL for rule 'xccdf_org.ssgproject.content_rule_grub2_audit_backlog_limit_argument' differs.
--- oval:ssg-grub2_audit_backlog_limit_argument:def:1
+++ oval:ssg-grub2_audit_backlog_limit_argument:def:1
@@ -1,11 +1,11 @@
 criteria OR
 criteria AND
-criterion oval:ssg-test_grub2_audit_backlog_limit_entries_expanded_or_referenced:tst:1
 criteria OR
 criterion oval:ssg-test_grub2_audit_backlog_limit_at_least_one_entry_referenced:tst:1
 criteria OR
 criterion oval:ssg-test_grub2_audit_backlog_limit_argument_grub_env:tst:1
 criterion oval:ssg-test_grub2_audit_backlog_limit_argument_grub_env_uefi:tst:1
+criterion oval:ssg-test_grub2_audit_backlog_limit_entries_minimal_value:tst:1
 criteria OR
 criteria OR
 criterion oval:ssg-test_grub2_audit_backlog_limit_argument:tst:1

ansible remediation for rule 'xccdf_org.ssgproject.content_rule_grub2_audit_backlog_limit_argument' differs.
--- xccdf_org.ssgproject.content_rule_grub2_audit_backlog_limit_argument
+++ xccdf_org.ssgproject.content_rule_grub2_audit_backlog_limit_argument
@@ -67,9 +67,9 @@
   when:
   - '"kernel-core" in ansible_facts.packages'
   - '"grub2-common" in ansible_facts.packages'
-  - (grubby_info.stdout is not search('audit_backlog_limit=' ~ var_audit_backlog_limit))
-    or ((etc_default_grub['content'] | b64decode) is not search('audit_backlog_limit='
-    ~ var_audit_backlog_limit))
+  - (grubby_info.stdout is not search('audit_backlog_limit={{ var_audit_backlog_limit
+    }}')) or ((etc_default_grub['content'] | b64decode) is not search('audit_backlog_limit={{
+    var_audit_backlog_limit }}'))
   tags:
   - CCE-80943-4
   - DISA-STIG-RHEL-08-030602

[github-actions]

Change in Ansible shell module found.

Please consider using more suitable Ansible module than shell if possible.

[vojtapolasek]

Hello @macko1 and thank you.
I have two remarks. First is technical, could you please split the PR into multiple commits? For example, one for documentation, one modifying tests... it makes reviewing easier.
Then I have a remark regarding the main purpose of the PR. As I understand it, your PR makes it possible to define the Grub2 value in three ways:

• arg_value - checks equality of the value against hardcoded value
• arg_variable - checks equality with a value represented by an XCCDF variable
• newly defined arg_minimal_value - checks if the value is greater or equal to a hardcoded value
  If I understand it correctly, then I think this is not an optimal implementation.
  Because what if in the future you would like to check if a value is greater or equal to something defined with XCCDF variable? It would require another round of reimplementation.
  I think it would be better to add a different parameter, which would signify the operation between the checked value and the hardcoded / variable provided value. In this way, we could check for equality, greater than, lesser than... whatever is supported.
  I had only a quick glance into templates, but it seems we already support this for example in the accounts_password template or pam_options template. Do you think this concept could be used in this case as well?