DISA misalignment with rule mount_option_boot_efi_nosuid

[evgenyz]

Description of problem:

The content is misaligned with an external (third party) content that targets the same policy - typically, this means that a system hardened by our content doesn't pass the scan by the external content.

Details:

This content is not aligned with content from DISA (https://www.stigviewer.com/stig/red_hat_enterprise_linux_9/2024-06-04/finding/V-257862).

The misalignment affects these profiles:

• STIG

The misalignment affects these rules:

• mount_option_boot_efi_nosuid (passes) / SV-257862r958804_rule (not applicable)

The rule in CaC content after (#12958) does not have a platform and check /boot/efi partition if it is mounted or configured in /etc/fstab (following mount_option template logic). It does pass if neither is present in the system.

The rule in DISA content checks for presence of /sys/firmware/efi (as the rule's platform). Which was the previous behaviour of the CaC's rule.

The uefi platform in CaC is (note that Ansible conditional is different from Bash and OVAL, which also checks for /sys/firmware/efi):

name: cpe:/a:uefi
title: System boot mode is UEFI
check_id: system_boot_mode_is_uefi
bash_conditional: '[ -d /sys/firmware/efi ]'
ansible_conditional: '"/boot/efi" in ansible_mounts | map(attribute="mount") | list'

Ideally the rule should be applicable for systems which have /boot/efi either configured and/or present in runtime. More appropriate platform for that would be mount.

We also might want to persuade DISA into changing the platform criteria.

In any case uefi and non-uefi platforms should be fixed to have consistent conditionals. Essentially at this moment these platforms are used only in /linux_os/guide/system/bootloader-grub2/* rules, and it might make sense to reconsider the criteria and the name. Also it make sense to use not uefi platform expression instead of two platform definitions.

Outcome:

• This project's content can be improved:
  • Check needs to be improved.
  • Remediation needs to be improved.
• The external content's check is faulty - the other party needs to be notified, they have work to do.

SCAP Security Guide Version:

74cf6d5

External Content's Version:

RHEL-09-231105

[evgenyz]

The issue is blocked to hide it from the list for the duration of the 0.1.76 stabilization. We can remove the blocked label after the release and work on it.