Fix STIG playbook: PAM faillock guard, FIPS module config, IMA hash

[dcasota]

Problem

Upstream commit 85c56e7 (Patch2, Release 2.1-6) fixed the STIG hardening playbook for Ansible 2.20 boolean conditionals and audit 4.x tool renames, but left three gaps:

1. PHTN-50-000192 PAM stack corruption: The regex_search() in the PAM faillock cleanup set_fact still returns None under Ansible 2.20. The comparison preauthsearch == "" evaluates to False when preauthsearch is None, causing the cleanup step to be skipped while the add step still runs, producing duplicate pam_faillock.so entries in /etc/pam.d/system-auth.

2. Missing ima_hash=sha256: IMA defaults to SHA1 which is disabled under FIPS, causing ima: Can not allocate sha1 (reason: -2) during boot.

3. Missing fipsmodule.cnf: When the FIPS provider is installed but /etc/ssl/fipsmodule.cnf is absent, OpenSSL cannot initialize FIPS mode and pam_unix.so fails to verify passwords.

Fix

Patch: fix-stig-playbook-fips-pam.patch (Patch3, Release 2.1-7) -- all changes are backward-compatible with Ansible 2.14+:

1. Add | default('')to PHTN-50-000192 when: conditions (no-op when value is already a string on older Ansible)
2. Add ima_hash=sha256 kernel parameter when fips=1 is active
3. Generate /etc/ssl/fipsmodule.cnf via openssl fipsinstall when the FIPS provider is present but config is missing

Compatibility

Fix	Photon 5.0 (Ansible 2.20)	Photon 5.0 pinned91 / 6.0 (Ansible 2.14+)
| default('')	Prevents None comparison error	No-op (value already a string)
ima_hash=sha256	Fixes IMA allocation failure under FIPS	Same fix needed if FIPS enabled
fipsmodule.cnf generation	Fixes OpenSSL FIPS init	Same fix needed if FIPS enabled

Testing

Tested on VMware Workstation (UEFI, TPM 2.0, VM encryption):

Build	IMA hash	fipsmodule.cnf	PAM faillock
5.0 pinned91	sha256 allocated, no error	Generated	Correct (2 entries)
5.0 normal (>= 92)	sha256 allocated (sha1 non-fatal kernel error persists)	Generated	Correct (2 entries)
6.0	sha256 allocated (sha1 non-fatal kernel error persists)	Generated	Correct (2 entries)

Known Issue: IMA SHA1 allocation under FIPS

The ima_hash=sha256 parameter redirects IMA file measurements to SHA256, but the kernel still attempts SHA1 for the PCR bank (ima: Can not allocate sha1 (reason: -2)). This is non-fatal. A full fix requires CONFIG_IMA_DEFAULT_HASH_SHA256 in the kernel, as tracked in Ubuntu Bug #2041735.

[dcasota]

Extended this PR to also cover the pinned-91 spec.

The original PR only touched SPECS/stig-hardening/ (subrelease >= 92, Ansible 2.20). The pinned-91 variant SPECS/91/stig-hardening/ packages the same source tarball and would still hit the same FIPS-side bugs (IMA sha1 allocation failure, missing /etc/ssl/fipsmodule.cnf) when booting with fips=1. The PR's own test matrix already includes the 5.0 pinned91 row, so the fix is already validated there — it was just not wired into the pinned-91 spec.

New commit (3b1971ae, "stig-hardening: also apply fips-pam patch to SPECS/91"):

• SPECS/91/stig-hardening/stig-hardening.spec: Release: 5.1 -> 5.2, adds Patch2: fix-stig-playbook-fips-pam.patch, changelog entry.
• SPECS/91/stig-hardening/fix-stig-playbook-fips-pam.patch: byte-identical to the >=92 copy.

Why the same patch file is safe in both locations:

• Both specs apply Patch0 and Patch1 to the same stig-hardening-ph5-2.1.tar.gz.
• The >=92 spec additionally applies Patch2: fix-photon.yml-for-latest-audit-and-ansible.patch, but that patch only touches the telnet regex_search block (~line 628) and the auditd binary list (~line 915, removes autrace) — disjoint from this patch's hunks (~305 / ~1183 / ~1320 / ~1375).
• The | default('') hunks (3 and 4) are no-ops on Ansible 2.14+ (regex_search returns "" on no-match), so they're safe to ship on the pinned-91 path even though only >=92's Ansible 2.20 actually needs them.

mergeable: true, mergeable_state: clean against current 5.0.

[dcasota]

Superseded by #1669.

This PR targets SPECS/91/stig-hardening/, which no longer exists on 5.0 — merging it would recreate a directory that was removed. It also proposes stig-hardening 2.1-7 while 5.0 is already at 2.1-8, and upstream already has its own 2.1-7 changelog entry, so it would move the release backwards and duplicate an entry.

Its substantive change is not lost: fix-stig-playbook-fips-pam.patch in #1669 is byte-identical to the one here (sha256 4d6096fefdf55d49), and #1669 carries it for the paths that do exist (SPECS/ and SPECS/90/) with the release continuing cleanly from 2.1-8.