Regression between Rocky 9.1 and 9.2 with using of tailoring-path

[mddeff]

We use the Anaconda OSCAP plugin for hardening our Rocky 9 systems. We recently took Rocky 9.2 for a spin and ran into some issues.

How we have it implemented in our kickstart:

%pre --interpreter=/bin/bash
mkdir -p /tmp/openscap_data
cat > /tmp/openscap_data/ssg-rhel9-custom-el9_nogui_exceptions.xml << EOF
#XML tailoring content here
EOF
%end
%addon com_redhat_oscap
    content-type = scap-security-guide
    datastream-id = scap_org.open-scap_datastream_from_xccdf_ssg-rhel9-xccdf-1.2.xml
    xccdf-id = scap_org.open-scap_cref_ssg-rhel9-xccdf-1.2.xml
    profile = xccdf_org.custom_profile_el9_stig
    tailoring-path = ssg-rhel9-custom-el9_nogui_exceptions.xml
%end

For R9.1: successfully kicks and applies hardening with the tailoring file
R9.2: Fails with the errors. Specifically in syslog coming off of the anaconda environment:

org_fedora_oscap.content_handling.ContentHandlingError: Expected a file /tmp/openscap_data/ssg-rhel9-custom-el9_nogui_exceptions.xml to be part of the supplied content, but it was not the case, got only ['/usr/share/xml/scap/ssg/content//ssg-rl9-ds.xml']

We see a similar error in the Anaconda TUI in the console of the target system.

Now, this may be a hack/cheating, but it seemed to work with OAA included in the Rocky/RHEL 9.1 installer, but is no longer working in 9.2.

We verified that the tailoring file is in fact in /tmp/openscap_data and based on time stamps, is getting there before the addon looks for it.

Relevant anaconda versions
Rocky 9.1: 34.25.1.14
Rocky 9.2: 34.25.2.10

Not quite sure how to pull the plugin versions, but can run those commands if provided.
Possibly related to #40 and #199 ?

We're a little different from 199 in that we're pulling policy from the SSG but tailoring from file.

Any thoughts?

[alexhaydock]

Unhelpful addition, but I can confirm I'm seeing the exact same issue on both Alma 9.2 and RHEL 9.2, so I do think this is an upstream change related to this addon and nothing Rocky specific.

Like you, I'm writing my tailoring content into /tmp/openscap_data/<filename>.xml with a heredoc and then specifying the tailoring-path when calling this addon.

I notice that there were a bunch of changes in #237 to how content gets parsed including a bunch of changes to how the addon handles tailoring files, so I wonder if the regression is somewhere in that PR.

Edit: Added clarification that this is definitely specifically 9.2 I'm seeing the issue on as well.

[mddeff]

@alexhaydock Actually quite helpful, glad to hear its not just my environment!

[mddeff]

In the mean time, trying to do a workaround in %post by just running oscap manually but running into some issues (right now just running it on a fresh install):

oscap xccdf eval --profile xccdf_org.ssgproject.content_profile_stig --results-arf /tmp/arf.xml --report/tmp/report.html --datastrream-id scap_org.open-scap_datastream_from_xccdf_ssg-rhel9.xccdf.xml /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml

And it starts with the error:

WARNING: Datastream component 'scap_org.open-scap_cref_security-data-oval-com.redhat.rhsa-RHEL9.xml' points out to the remote 'https://www.redhat.com/security/data/oval/com.redhat.rhsa-RHEL9.xml'. Use '--fetch-remote-resources' option to download it.
WARNING: Skipping 'https://www.redhat.com/security/data/oval/com.redhat.rhsa-RHEL9.xml' file which is referenced from datastream
WARNING: Skipping ./security-data-oval-com.redhat.rhsa-RHEL9.xml file which is referenced from XCCDF content

This is on an airgapped system, but if regular oscap is erroring out, how did the anaconda plugin ever work? Is there something I'm missing?

Even when I try to download the content to a local directory and use the --local-files option as called out in a RedHat solution, I still get everything defined as "not-applicable" and no rules are actually evaluated.

Edit: I needed to reference /usr/share/xml/scap/ssg/content/ssg-rl9-ds.xml, so now they actually get evaluated. Still wondering how OAA is getting that content that I had to manually download from access.redhat.com.

[jan-cerny]

Thanks for opening the issue. It's helpful to see the ways how people use the project in reality. It was never supposed to work this way, so it's a pleasant surprise that it worked before, but consequently, we don't test this scenario. The tailoring file should be put in an RPM or a zip file together with the SCAP data stream.

Regarding the "WARNING:", this is really a warning not an errpr, and affects only rule security_patches_up_to_date. This rule compares the versions of the installed RPM packages with the published vulnerability data, and as that changes over time it needs fresh data downloaded from the internet. By default, the data aren't downloaded and the rule security_patches_up_to_date is skipped. This usually doesn't matter during the installation as it's clear that the installation media contains packages in versions from the time the version was released and you're supposed to install updates after installation anyway. So OAA isn't getting that content.

[mddeff]

@jan-cerny Thank you for the follow up! Is there any documentation that can walk through how one generates the zip/rpm as described in:

The tailoring file should be put in an RPM or a zip file together with the SCAP data stream.

i.e. what that folder structure looks like, where those files should exist, example %addon configurations.

I looked at (what I believe is) the official documentation page, and while it provides a good overview for those curious on the project, it's a bit light on the level of detail necessary for actually implementing OAA (esp. with any tailoring content).

And while the tutorial on how to create your own tailoring content was helpful, it doesn't walk you though in detail on how to use that in OAA.

Thank you for all you and the team do to support this project, it really is apprecaited!

[alexhaydock]

It's helpful to see the ways how people use the project in reality. It was never supposed to work this way, so it's a pleasant surprise that it worked before, but consequently, we don't test this scenario. The tailoring file should be put in an RPM or a zip file together with the SCAP data stream.

Hi @jan-cerny - thanks for the reply 😄

Is there a way that the tailoring file in an rpm/zip can be delivered to a kickstarted host via the OEMDRV method that doesn't require rebuilding the ISO or changing the kernel boot options?

The use-case here for using this methodology in my case is to deploy RHEL (& derivative) hosts without needing to modify & rebuild the upstream ISOs, without needing human interaction during the boot process (i.e. to change GRUB options), and with the ability to deploy on networks without internet access (so no ability to supply a tailoring file hosted on a URL). This is very easy to do by simply booting the unmodified upstream ISO with the kickstart stored on a secondary disk labeled OEMDRV, and with the tailoring file inside the kickstart itself.

If the tailoring file can be included as an RPM/zip file that might work just as well, though I've never really experimented with whether it can be incorporated into the entirely hands-free workflow that doesn't require the rebuilding of the upstream ISO. I wonder if it could be supplied on the OEMDRV drive also?