RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1834716 - Remediating rules using service_disabled template during kickstart installation does not work as expected
Summary: Remediating rules using service_disabled template during kickstart installati...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: oscap-anaconda-addon
Version: 8.0
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: rc
: 8.0
Assignee: Matěj Týč
QA Contact: Release Test Team
Jan Fiala
URL:
Whiteboard:
Depends On: 2041781
Blocks: 1999587
TreeView+ depends on / blocked
 
Reported: 2020-05-12 09:38 UTC by Matěj Týč
Modified: 2024-01-31 14:04 UTC (History)
10 users (show)

Fixed In Version: oscap-anaconda-addon-1.2.1-6.el8
Doc Type: Known Issue
Doc Text:
.Remediating service-related rules during kickstart installations might fail During a kickstart installation, the OpenSCAP utility sometimes incorrectly shows that a service `enable` or `disable` state remediation is not needed. Consequently, OpenSCAP might set the services on the installed system to a non-compliant state. As a workaround, you can scan and remediate the system after the kickstart installation. This will fix the service-related issues.
Clone Of: 1828871
: 1999587 (view as bug list)
Environment:
Last Closed: 2022-07-25 07:28:05 UTC
Type: Bug
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker RTT-4329 0 None None None 2022-03-18 16:42:45 UTC
Red Hat Issue Tracker RTT-4330 0 None None None 2022-03-18 16:42:50 UTC
Red Hat Issue Tracker RTT-4357 0 None None None 2022-04-01 12:52:15 UTC

Description Matěj Týč 2020-05-12 09:38:01 UTC 
+++ This bug was initially created as a clone of Bug #1828871 +++

Description of problem:
After rhel7  server with GUI installaltion performed with CIS Kickstart some rules related to service_disabled are shown as passing during remediation stage. However, after the system restarts and a scan is performed, they show as failed.
Version-Release number of selected component (if applicable):
upstream commit 9e403dd

How reproducible:
always

Steps to Reproduce:
1. Perform installation of rhel7 from CIS kickstart, selecting sever with GUI. As shown in this test case:
https://tcms.engineering.redhat.com/case/606896/
Save the report created during remediation.
3. Restart the system and scan it.

Actual results:
Notice that there are failing rules:
xccdf_org.ssgproject.content_rule_service_rhnsd_disabled
xccdf_org.ssgproject.content_rule_service_cups_disabled
xccdf_org.ssgproject.content_rule_service_avahi-daemon_disabled
Check rules in the report created in step 1. Notice that they are shown as passing.

Expected results:
Rules are remediated after installation (step 1) and therefore shown as passing after the final scan (step 2).

Additional info:
I suspect that there might be problem with the fact that during remediation after installation the reemdiation is not performed while Systed on the target system is running. Therefore services might seem to the scanner as if they are disabled. However, after reboot they become enabled.

--- Additional comment from Matěj Týč on 2020-05-11 09:53:54 UTC ---

The issue is caused by the scanner scanning the installing system, not the installed one when it comes to systemd.
The installing system executes a chroot, so the scanner performs an offline scan, but as the scanner uses DBUS to talk to systemd, it talks to the systemd process of the installing system, and therefore gets misleading information.
This is not a typical offline vs offline scan situation, as a chrooted system has all attributes of an online system, except that the runtime component comes from the chrooting system.
As a result, this issue has to be fixed rather on the OAA/content side (e.g. "always do those services-related remediations") than on the OpenSCAP side.
Comment 7 RHEL Program Management 2021-11-12 07:27:09 UTC 
After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.
Comment 9 Matěj Týč 2022-03-07 14:42:33 UTC 
Addressed in https://github.com/OpenSCAP/oscap-anaconda-addon/pull/190
Comment 10 Jan Stodola 2022-03-08 14:47:28 UTC 
Mateji,
I built updates.img using https://github.com/OpenSCAP/oscap-anaconda-addon/blob/rhel8-branch/create_update_image.sh, applied the image during the installation and selected the ANSSI-BP-028 (minimal) profile during manual installation.
During the first boot there was the following error and the system restarted:

....
[  OK  ] Reached target Offline System Update (Pre).
         Starting Scan and remediate the ope…dance with the selected profile...
         Starting Update the operating system whilst offline...
[  OK  ] Started Update the operating system whilst offline.
OpenSCAP is checking the system for compliance using
ANSSI-BP-028 (minimal)

Evaluating...
[ ***  ] A start job is running for Scan and…e selected profile (7s / no limit)OpenSCAP has failed to evaluate or remediate the system, please check the journal for the details.
The system will now restart...
[  OK  ] Started D-Bus System Message Bus.
[  OK  ] Created slice User and Session Slice.
....

I used RHEL-8.6.0-20220305.2. Could you please check where the problem is?
Comment 11 Matěj Týč 2022-03-08 15:31:14 UTC 
Your output suggests that the firstboot remediation was indeed executed as requested, but not everything went according to the expectations.
This raises the first concern - it is not an issue when e.g. one doesn't pass, but the message is unsettling, and the whole start-scan-restart sequence can surprise and disturb customers.

The concrete cause of problems has to be investigated on a case-by-case basis, but as a rule of thumb, the /root/openscap_data/eval_remediate_report.html contains a human-readable output of the last finished scan.
Comment 16 Alois Mahdal 2022-04-22 07:00:00 UTC 
Pre-verified using development compose (testing compose was not found):

    http://download.eng.bos.redhat.com/rhel-8/development/RHEL-8/RHEL-8.7.0-20220421.d.0/compose

Cases executed:

    ARCH     MODE        remediation=
    ===================================
    x86_64   kickstart   (default)
    x86_64   kickstart   both
    x86_64   kickstart   firstboot
    x86_64   manual      ~
    x86_64   kickstart   none
    x86_64   kickstart   post
    aarch64  kickstart   (default)
    aarch64  kickstart   none
    aarch64  kickstart   post
    ppc64    manual      ~

All cases behaved as expected.
Comment 21 Jan Stodola 2022-04-27 14:04:46 UTC 
Thanks for the bug text, it looks fine.

Checked that oscap-anaconda-addon-1.2.1-6.el8 is in nightly compose RHEL-8.7.0-20220424.1.

Moving to VERIFIED.
Comment 24 Matěj Týč 2022-06-20 14:53:59 UTC 
As there will be no firstboot, this issue remains to be solved again. The KI doc text is accurate.
Comment 31 RHEL Program Management 2022-07-25 07:28:05 UTC 
After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.
Note You need to log in before you can comment on or make changes to this bug.