kdump is not disabled via Kickstart remediations on RHEL-10

[comps]

Description of problem:

According to oscap HTML report, kdump.service has ActiveState as failed, not as disabled (?).

This is possibly because RHEL-10 Anaconda forcibly activates kdump even if the (oscap-generated) kickstart has

    # Disable and enable systemd services (required for security compliance)
    services --disabled=debug-shell,autofs,kdump --enabled=pcscd,rsyslog,systemd-journald,firewalld,fapolicyd,chronyd,sshd,usbguard,auditd

Maybe it can be fixed in content, maybe adding

%addon com_redhat_kdump --disable
%end

would fix it (in OpenSCAP code?).

This %addon syntax is compatible with older RHELs too, and should arguably be present in those kickstarts as well.

There was a similar issue in the past with Anaconda: rhinstaller/kdump-anaconda-addon@06ad891 , so this may also be an Anaconda bug - we should probably contact their devel team to figure out a solution.

SCAP Security Guide Version:

master @ 60a184a

Operating System Version:

RHEL-10

Steps to Reproduce:

1. Run custom productization as

   --rhel 10 --arch x86_64 --test /hardening/kickstart/hipaa
   

   (happens on hipaa, stig and stig_gui)

Additional Information/Debugging Steps:

• report.html.gz
• scan-arf.xml.gz

[jan-cerny]

OpenSCAP should be able to generate this section to the generated kickstart when a rule has a kickstart type remediation with the following contents:

kdump disable

[comps]

Well, seeing how these tests failed:

/hardening/kickstart/hipaa/service_kdump_disabled
/hardening/kickstart/stig/service_kdump_disabled
/hardening/kickstart/with-gui/stig_gui/service_kdump_disabled

it seems that service_kdump_disabled doesn't use that feature.