Recent `bootc` change broke mount option applicability

[comps]

Description of problem:

Recently, the

/hardening/container/bootc-image-builder/*
/hardening/container/anaconda-ostree/*
/hardening/host-os/ansible/*

started failing first on RHEL-10.3 / 9.9, but now I also see the failures on 10.2 / 9.8 using new content.

Specifically, basically all of the mount_option_* rules fail because of what seem like applicability errors introduced by a recent bootc change.

Heavily curated AI analysis follows:

---

What broke

PR #14953 (commit 10c9ba84) changed the platform for the Restrict Partition Mount Options and Disk Partitioning groups from not container and not bootc to not container and not bootc_build, and introduced a new cpe:/a:bootc_build platform in shared/applicability/bootc_build.yml.

The intent was correct: mount option rules should be evaluable on running (booted) bootc systems, not just skipped everywhere bootc is present. However, the new bootc_build Ansible conditional is buggy, and the change also introduced a remediation gap for bootc image builds.

Two problems

1. Ansible bootc_build conditional matches regular hosts (host-os failures)

The three detection engines for bootc_build are inconsistent:

Engine	Checks for /ostree symlink	Correct on regular host with bootc RPM
OVAL	Yes (via parent bootc def: /ostree symlink OR /run/ostree-booted)	Yes — returns False
Bash	Yes ([ -L /ostree ])	Yes — returns False
Ansible	No — only checks "ostree" not in ansible_proc_cmdline	No — returns True

The Ansible conditional in bootc_build.yml:

ansible_conditional: '"kernel-core" in ansible_facts.packages and "bootc" in ansible_facts.packages and not "openshift-kubelet" in ansible_facts.packages and "ostree" not in ansible_proc_cmdline'

On any regular RHEL host where bootc is installed (which is all current RHEL 9 and 10 minor versions): kernel-core installed, bootc installed, no openshift-kubelet, no ostree in /proc/cmdline — all four conditions are true. The Ansible engine concludes this is a bootc_build environment, so not bootc_build is false, and every remediation task gated on this platform is skipped.

The OVAL scan then correctly evaluates the rules as applicable (OVAL's bootc_build returns false because /ostree doesn't exist), finds the mount options were never applied, and reports fail.

Specifically, even options like nodev and nosuid that are already present in the default runtime mount of /dev/shm fail — because the skipped remediation never ran ansible.posix.mount, so no /etc/fstab entry was created, and the OVAL mount_option template requires the option in both /proc/mounts AND /etc/fstab.

2. No remediation path for booted bootc systems (container/bootc-image-builder failures)

The platform change made mount option rules applicable on running bootc systems. But the only remediation opportunity is during the image build, where bootc_build is true — meaning the rules are not applicable and remediation is skipped. After the image boots, bootc_build becomes false (/run/ostree-booted exists), the rules become applicable, but no remediation ever ran.

This is a design gap: the rules are now checkable post-boot (as intended) but there is no mechanism to remediate them during the build or at first boot.

Suggested fix

For problem 1 (Ansible conditional)

Add the missing /ostree symlink check to the Ansible conditional in shared/applicability/bootc_build.yml, making it equivalent to the bash conditional. This requires finding an Ansible-native way to express [ -L /ostree ] as a when: expression — the bash and OVAL definitions both have this check, the Ansible one simply omits it.

This fixes all host-os/ansible failures. The remediation tasks will run, apply mount options, create fstab entries, and the OVAL scan will pass.

For problem 2 (bootc remediation gap)

This is an architectural question for the maintainers. Options include:

• Reverting to not bootc for these groups (re-hides the rules on booted bootc systems)
• Adding bootc-native remediation (e.g. via systemd mount units or tmpfiles.d configs baked into the image)
• Treating these as expected failures on bootc and waiving them in test infrastructure

Affected rules

All rules under:

• linux_os/guide/system/permissions/partitions/ (mount_option_dev_shm_, mount_option_tmp_, mount_option_var_, mount_option_boot_, mount_option_nodev_nonroot_local_partitions, etc.)
• linux_os/guide/system/software/disk_partitioning/ (partition_for_*, systemd_tmp_mount_enabled)

---

SCAP Security Guide Version:

master @ 371e25d

Operating System Version:

RHEL-10 / RHEL-9, maybe older

[comps]

To preemptively answer bootc presence -- yes, the RPM and its CLI binary is meant to be present even on non-bootc systems, exactly so that one can run bootc status to reliably figure out if the system is or is not Image Mode. Checking just ostree doesn't guarantee this.

[jan-cerny]

Originally we decided that the affected rule groups should be evaluated as "not applicable" both during the bootable container image build and on a running bootc system.

• During a build of bootable container image, there are no partitions and no disk layouts, it's a container environment, and in containers the concept of partitions doesn't exist. Also, during the build, we have no information about storage and disks on the target system.
• On a running bootc system, we have no way of remediating the failing rules. The disk partitions were created during the deployment by ostree. We have no way of influencing how ostree will partition them. At the same time many partitions are read-only and their contents is defined by the container image, which (partially) satisfies the security requirements behind the partitioning rules. So we made the rules not applicable on running bootc systems as well.

The decision to make the rules not applicable on running bootc systems is definitely questionable. It was kind of temporary, unclear solution. Our idea was to investigate the security requirements more in detail and then propose a different solution that would fulfill the security needs but wouldn't use partitions as implementation, which would be friendly for the bootc systems. But, the investigation hasn't been done yet and is still in the backlog.

[comps]

One more related rule, not noticed this earlier as it's not a mount option, but a real tmp.mount systemd unit.

TASK [Enable mount tmp] ********************************************************
skipping: [localhost] => {"changed": false, "false_condition": "( not ( \"kernel-core\" in ansible_facts.packages and \"bootc\" in ansible_facts.packages and not \"openshift-kubelet\" in ansible_facts.packages and \"ostree\" not in ansible_proc_cmdline ) and not ( ansible_virtualization_type in [\"docker\", \"lxc\", \"openvz\", \"podman\", \"container\"] ) )", "skip_reason": "Conditional result was False"}

systemd_tmp_mount_enabled

[Mab879]

For now I have proposed we revert the platform changes until we get better fix for this, see #14999.