AIDE FINT-4402 deficiencies in egrep pattern

[ldilley]

Describe the bug
A Lynis audit reports the following despite explicitly using sha256 and/or sha512 in aide.conf:

* Use SHA256 or SHA512 to create checksums in AIDE [FINT-4402]
      https://cisofy.com/lynis/controls/FINT-4402/

Version

• FreeBSD 13.0-RELEASE-p2 (all platforms affected however)
• Lynis version 3.0.6

Expected behavior
The test for control FINT-4402 should pass/not be flagged as a finding when sha256 and/or sha512 are defined.

Additional context
The issue stems from the egrep pattern employed in include/tests_file_integrity on line 407: https://github.com/CISOfy/lynis/blob/master/include/tests_file_integrity#L407

The space after the equals sign in the pattern ("= .*(sha256|sha512)")) is not required and causes a false positive during conditions when the spacing is not present in an AIDE configuration rule.

The following variations in aide.conf are syntactically sane according to aide --config-check:

1. Checksums = rmd160+haval+gost+crc32+tiger+sha256+sha512 (works as expected)
2. Checksums=rmd160+haval+gost+crc32+tiger+sha256+sha512 (legal AIDE configuration syntax, but Lynis currently ignores it)

I propose modifying the egrep pattern to be something like: "^\s*\w+\s*=.*[^-](sha256|sha512)"

The above new pattern would have the following improvements:

1. Lines with and without leading/trailing space are properly detected.
2. Conditions when sha256 and sha512 are excluded (-) are handled appropriately (for example: Checksums=rmd160+haval+gost+crc32+tiger-sha256-sha512). Currently, Lynis detects excluded sha256/sha512 as false negatives (which is a bug).
3. The name of a template (left side of equals sign) must be present.

There is another limitation with the current detection method in Lynis. Just because a template is defined in aide.conf does not mean that the template is being applied to file and directory rules (another potential false negative). Templates can be defined and unused in other words. Furthermore, sha256/sha512 can be explicitly set for directory/file rules outside of templates. However, detecting the presence of sha256/sha512 for every directory/file rule would be more involved and not necessarily desirable in some cases. Perhaps it is best to add a manual review note for the system maintainer to ensure that the stronger hashing algorithms is/are being included in the appropriate rules. This inclusion might be encouraged for rules covering files that are typically subject to increased scrutiny such as /etc/passwd or those under /sbin.

This is related to #160.