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. |
|
Adds waivers for the two remaining issues that do not behave well on containers (image mode). Please see the commit message for details. The conclusion was basically that those rules cannot be remediated in the built image. There were certain conditions on why the error manifested only on RHEL9, it should be described in the commit message as well. |
5162bcc to
f926b0e
Compare
… CUI Both rules fail on /hardening/container/old-new/cui, the Image Mode Day-2 upgrade scenario, for reasons rooted in how bootc handles state across a "bootc switch": - aide_build_database: old CUI doesn't select this rule, so the AIDE db is never seeded into /var on the old image. /var is never re-provisioned by "bootc switch", so the db built into the new image never reaches the guest. Deterministic. - ensure_pam_wheel_group_empty: old CUI doesn't select this rule, so the empty-wheel fix baked into the new image's /etc/group can be dropped by ostree's /etc 3-way merge on switch if the live copy looks locally modified. Confirmed flaky. Moved into a new conf/waivers/test_specific file, dedicated to waivers rooted in test methodology rather than in content/product defects, with a header explaining the general old-new/bootc-switch mechanism.
f926b0e to
116531e
Compare
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.