`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: https://github.com/rhinstaller/kdump-anaconda-addon/commit/06ad89188047cc28fde514ab722a1bf4637b60ad , 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 @ 60a184a0

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.

[jan-cerny]

Yes, it doesn't use it

[jan-cerny]

I have created PR https://github.com/ComplianceAsCode/content/pull/12856 where I will add the %addon com_redhat_kdump --disable to the remediation. However, that won't fix this issue - see the description there.

[jan-cerny]

The PR #12856 has been merged, but the rule still fails - see the description there.

[comps]

So what are the next steps if this is blocked?

Is there an Anaconda installer issue filed to change the behavior of the %addon to disable/mask the service if it doesn't do that?

Or do we "fix" it on the content side by checking service start failure and treating it as valid for "service disabled"?
Or do we add a %post script to mask the service?

[jan-cerny]

Yes, this is blocked by https://github.com/ComplianceAsCode/content/issues/12282.