test: run oscap checks on images with oscap customizations (HMS-3710)

[achilleas-k]

Add oscap test configs for RHEL 8 and RHEL 9 with the appropriate datastream option enabled.
These replicate the test configs from the oscap test in osbuild-composer [1].

To fully replace the test in osbuild-composer, this PR also adds support for running the boot test script with the config file as argument. When an oscap config is detected, it runs some extra checks on the score of the system.

NOTE: This is a bit quick and dirty but should soon be replaced with a more comprehensive test of all customizations on images during boot

[1] https://github.com/osbuild/osbuild-composer/blob/073e304978acade8bfa059f00a005402aa037c99/test/cases/oscap.sh

[achilleas-k]

RHEL 8.10 boot test failing with:

systemd-remount-fs[563]: mount: /dev/shm: mount point not mounted or bad option.

which makes the systemd-remount-fs.service fail.
Looking into it.

[achilleas-k]

Comparing the oscap version of the image with the base one, /etc/fstab gets an extra line:

tmpfs /dev/shm tmpfs defaults,nosuid,relatime,mode=755,inode64,nodev,noexec 0 0

which I assume is what causes the issue. Is this a bug in the oscap profile, adding an fstab option that the OS doesn't support, or did I configure it wrong?
I copied the blueprint from the test in osbuild-composer, but we don't check for the system status there so this might have always been happening.

@kingsleyzissou do you know anything about this (from your oscap experience)?

[kingsleyzissou]

which I assume is what causes the issue. Is this a bug in the oscap profile, adding an fstab option that the OS doesn't support, or did I configure it wrong?

So this is technically a required mountpoint in the rhel-8 datastream for the cis profile. So maybe it's adding this as a remediation and breaking the build. It might be an outdated datastream, because I think they may have removed this. I'm double checking

[kingsleyzissou]

I have a strong suspicion that we are using an outdated datastream file from an older scap-security-guides package.

[achilleas-k]

I have a strong suspicion that we are using an outdated datastream file from an older scap-security-guides package.

Interesting. Could it be an 8.10 issue since it's not released yet? I'm playing with the fstab on a live system and trying to get it to work but even with no options (just defaults) systemd-remount-fs.service fails.
Manually mounting it works only if I remove the inode64 option.

Not sure if any of this helps.

[kingsleyzissou]

Interesting. Could it be an 8.10 issue since it's not released yet?

It's just a hunch. But up until last year the blueprints generated by the oscap tool were also trying to configure filesystem options for /dev/shm which was causing builds to fail. I think they revised the datastream since then and that has been removed.

But I haven't seen an entry being added to the /etc/fstab before. That's interesting. We can maybe reach out to the openscap team about this @evgenyz.

Edit: another thought is it could also be something from some of the offline improvements that have been made, but Evgeny would have to confirm if they've made any changes to the mountpoint options on their end.

[achilleas-k]

@kingsleyzissou Unselecting content_rule_mount_option_dev_shm_nosuid, content_rule_mount_option_dev_shm_noexec, and content_rule_mount_option_dev_shm_nodev didn't help.

[achilleas-k]

Disabling the test on RHEL 8.10 for now.

[kingsleyzissou]

🙏

[evgenyz]

That's very strange. I don't think we force inode64 anywhere. As to the record itself: it should not be a problem, as /etc/fstab is the recommended way (acc. to systemd docs) for mount units options customization.

[evgenyz]

Remediation log could be helpful (it is stored in /root/).

[kingsleyzissou]

@evgenyz it's really weird, if I disabled partition_for_dev_shm things work and no entry is added into the /etc/fstab.
But when I check the remediation logs:
FIX FOR THIS RULE 'xccdf_org.ssgproject.content_rule_partition_for_dev_shm' IS MISSING!