Fix grub2 enable fips mode rule

[ggbecker]

Description:

The problem was that it may happen that bash remediation phase when doing a fresh installation, some functions may require installing package, but it can happen that the machine is not registered to any repository yet, so the package installation should happen during the package installation phase via anaconda.

• Add dracut-fips-aesni to anaconda remediation for grub2_enable_fips_mode rule.
• Fix log of disable_prelink to detect the presence of prelink package as we changed the bash code to be a macro and it is not a function anymore, so we cannot use neither return statement nor exit, now it skips correctly when the package is not installed.

Rationale:

• grub2_enable_fips_mode passes during fresh installation when using oscap-anaconda-addon profiles.

• Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1754532

[redhatrises]

dracut-fips-aesni was purposefully not added to anaconda remediations. The reason is that you cannot guarantee that you are running or using aesni enabled processors. We would need to add some sort of code to OAA to handle if aesni processors are detected.

[ggbecker]

dracut-fips-aesni was purposefully not added to anaconda remediations. The reason is that you cannot guarantee that you are running or using aesni enabled processors. We would need to add some sort of code to OAA to handle if aesni processors are detected.

I understand. But is it harmful to install the package even if the processor doesn't support the hardware acceleration? Otherwise we won't have this rule green during installation on a machine which is not subscribed during installation phase.

[ggbecker]

* Fix log of disable_prelink to detect the presence of prelink package as we changed the bash code to be a macro and it is not a function anymore, so we cannot use neither `return` statement nor `exit`, now it skips correctly when the package is not installed.

Even if installing the package dracut-fips-aesni through anaconda without proper handling of processor capabilities is not desired, the above is still valid.

[jan-cerny]

Related to #4300 and #3221

@ggbecker We don't know if adding the dracut-fips-aesni package breaks the operating system installation on processors which don't have this technology.

[ggbecker]

I've consulted dracut subject matter experts from: https://github.com/dracutdevs/dracut and they say it is not harmful to install dracut-fips-aesni as kernel will just ignore the modules:

quoting:

it only includes aesni-intel ghash_clmulni_intel kernel modules to the initrd if they are available on the system

I've tested on other architectures such as ppc64,s390x,etc and the package is present on those archs as well and can be installed without any problem.

rpm -qa dracut-fips-aesni
dracut-fips-aesni-033-568.el7.ppc64

[matejak]

I am merging this PR, as it makes the OSPP/STIG profile one rule greener.
As @redhatrises pointed out, the Anaconda remediation could be smarter, but thanks to the great job of @ggbecker with consulting SMEs and testing, we have confidence that the PR doesn't introduce any adverse effects to remediated systems.