Rule service_rpcbind_disabled is failing after CIS workstation L2 kickstart installation

[vojtapolasek]

Description of problem:

After you perform an installation of RHEL 8 with kickstart for CIS workstation level 2, the rule service_rpcbind_disabled fails during the oscap scan.

SCAP Security Guide Version:

stabilization-v0.1.69 branch as of 2023-07-20

Operating System Version:

RHEL 8

Steps to Reproduce:

1. perform kickstart installation with kickstart for CIS workstation level 2, choose the "system with GUI" when installing
2. examine test results provided after the installation

Actual Results:

rule service_rpcbind_disabled is reported as "fail"

Expected Results:

rule service_rpcbind_disabled is reported as "pass"

Additional Information/Debugging Steps:

[marcusburghardt]

I don't remember where, but I think this was already discussed in the past. Maybe it is related to a dependency relationship with another package or service?

[vojtapolasek]

@marcusburghardt you are probably right: #10143 might be good to read.

[marcusburghardt]

Maybe it was "not applicable" during the installation phase. Then fails right after the install. I wonder if it would be properly fixed if a second round of scan / remediation happens after reboot.

[marcusburghardt]

For some reason, the nfs-utils package was included in this rule by this commit: 9676acc
I already proposed a fix for this: #10907

This rule replaced the package_rpcbind_removed rule in CIS profiles for RHEL about six months ago.

However, regardless of the fix I will propose, the rule seems to be working as expected:

• During the installation, the rpcbind package is installed to satisfy the nfs-utils dependency.
• Right after the installation, the rpcbind service is not started but is enabled:

systemctl status rpcbind
● rpcbind.service - RPC Bind
   Loaded: loaded (/usr/lib/systemd/system/rpcbind.service; enabled; vendor preset: enabled)
   Active: inactive (dead)
     Docs: man:rpcbind(8)

• It makes the rule to fail after the installation.
• But after the remediation the service is properly disabled.

It seems another case of rule dependencies which can be solved with a second round of scan/remediation, like reported in this issue: OpenSCAP/openscap#1880

@mildas and @vojtapolasek , could you confirm this case, please?

[marcusburghardt]

Still present in last productization review.

[vojtapolasek]

I can confirm that the problem can be solved by one more remediation after the installation.

[marcusburghardt]

Great. So we can update the waivers and close this issue. I will work on this. Thanks for the confirmation @vojtapolasek

[vojtapolasek]

RHSecurityCompliance/contest#55

[vojtapolasek]

It manifested also during the latest stabilization with kickstart installation of cis_ws_l1 and cis_ws_l2.

[marcusburghardt]

RHSecurityCompliance/contest#55 was merged yesterday. It should be good for the next round of tests.

[marcusburghardt]

It is no longer present in last productization tests. FYI @mildas @comps