Enable CUI profile testing on RHEL-10 - #664
Conversation
|
LGTM on first glance, it just needs the Plus rebases of all other upstream PRs (as this test would be failing there). |
|
Also, before this is merged, we should run a |
Okay, I will run that soon. |
fc690bd to
ae560e0
Compare
ComplianceAsCode/content now derives the cui (NIST 800-171) profile from the nist_800_171 control file for RHEL 8, 9, and 10 alike, so RHEL-10 has a cui profile too. Remove the "there is no CUI profile on RHEL-10+" adjust blocks that disabled cui testing there, so it runs uniformly across RHEL 8, 9, and 10.
- Disable CUI with GUI for anaconda/kickstart install-time hardening, as the CUI profile removes GUI-incompatible packages (like OSPP), which aborts the non-interactive installation. - Waive image-builder CUI errors: osbuild-composer does not yet have the CUI profile in its allow list (unsupported profile xccdf_org.ssgproject.content_profile_cui). - Waive anaconda/cui socket_systemd-journal-remote_disabled, the same known anaconda limitation already waived for the cis profile.
Mirror the CIS handling: the plain cis profile is disabled with GUI in all with-gui plans, and CUI (which is essentially CIS Level 2 Server and now also removes X Windows packages) is likewise incompatible with a GUI install. Disable /cui unconditionally in oscap/with-gui and ansible/with-gui, matching the anaconda and kickstart with-gui plans.
The fips tag makes the guest get installed with the fips=1 kernel argument (see hardening/*/test.py). CUI's content was never made FIPS-aware: unlike ospp/stig (which explicitly select a fips_*-prefixed crypto-policy variable), cui reuses cis's configure_custom_crypto_policy_cis rule, which sets a non-FIPS 'DEFAULT:NO-SHA1:...' base policy regardless. Installing a cui guest with fips=1 while its own remediation then applies a non-FIPS crypto policy leaves the system in an inconsistent state (kernel/OpenSSL enforcing FIPS-validated crypto, userspace crypto-policy saying otherwise), which is the leading suspect for the intermittent 'scp: Connection closed' failures seen after remediation on RHEL 9 x86_64 hardening tests. cis, which is not fips-tagged, never hits this. Since cui was never designed to run under FIPS mode (its crypto-policy handling is identical to cis), stop installing it with fips=1, matching how cis itself is tested.
ae560e0 to
ecdfb68
Compare
|
/packit test -i productization --env TESTS=/cui$ |
|
The CI failure is because there's currently no way to specify both CaC/content and Contest PRs, so upstream master was used: https://artifacts.dev.testing-farm.io/e5636026-e456-4ced-b3d2-bd4a82e5beec/ edit: actually, I lied. /packit test -i productization --env TESTS=/cui$ --env CONTENT_PR=15062 --env PLAN=/plans/weekly |
|
/packit test -i productization --env TESTS=/cui$ --env CONTENT_PR=15062 --env PLAN=/plans/weekly |
|
The CentOS Stream tests failed: https://artifacts.dev.testing-farm.io/1e4272f0-c106-4a80-9ad7-af6172ebc753/ but I've seen these failures before too, so they were not introduced by this PR. |
2 participants
Description
Enables the
/cuiprofile test cases on RHEL-10 (and CentOS Stream 10) across the hardening and scanning plans.The NIST 800-171 (CUI) profile is now available on RHEL-10 via ComplianceAsCode/content#15062. This PR removes the "there is no CUI profile on RHEL-10+"
adjust+blocks that previously disabled the/cuitest cases on those distros, so CUI is now exercised on all supported RHEL versions.Changes
.fmffiles updated, removing the RHEL-10+ CUI exclusions acrosshardening/andscanning/plans.adjust+block held only the RHEL-10 exclusion, the block was removed; where it also carried other conditions (GUI incompatibility on RHEL-8,rng-tools/rhc-worker-playbookrequires, FIPS tags), those were preserved.Dependency
Requires the RHEL-10 CUI profile from ComplianceAsCode/content#15062. RHEL-8/9 already ship the CUI profile and run unchanged.