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 1648162 - Installing RHEL with "Server with GUI" and using DISA STIG causes system to fail to launch X window system
Summary: Installing RHEL with "Server with GUI" and using DISA STIG causes system to f...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: oscap-anaconda-addon
Version: 7.6
Hardware: All
OS: Linux
high
medium
Target Milestone: rc
: ---
Assignee: Matěj Týč
QA Contact: Release Test Team
Jan Fiala
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-11-09 00:59 UTC by Ryan Mullett
Modified: 2023-12-15 16:13 UTC (History)
18 users (show)

Fixed In Version:
Doc Type: Known Issue
Doc Text:
.Systems installed as `Server with GUI` with the DISA STIG profile or with the CIS profile do not start properly The DISA STIG profile and the CIS profile require the removal of the `xorg-x11-server-common` (X Windows) package but does not require the change of the default target. As a consequence, the system is configured to run the GUI but the X Windows package is missing. As a result, the system does not start properly. To work around this problem, do not use the DISA STIG profile and the CIS profile with the `Server with GUI` software selection or customize the profile by removing the `package_xorg-x11-server-common_removed` rule.
Clone Of:
Environment:
Last Closed: 2020-05-21 12:12:04 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
Latest upstream version release of DISA STIG for RHEL7 that resolves issue. (770.93 KB, application/zip)
2020-04-28 20:40 UTC, Brandon Clark 		no flags Details
View All


Links
System ID Private Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 3755211 0 None None None 2018-12-13 23:31:10 UTC

Description Ryan Mullett 2018-11-09 00:59:20 UTC 
Description of problem:
- Choosing Server with GUI and the DISA STIG security profile causes the system to hang during boot
- The same is true if you install Server with GUI and then remediate using openscap with DISA STIG profile and then reboot
- Main issue appears to be the following rule that ensures xorg-x11-server-common is not installed on the system

        <ns0:definition class="compliance" id="oval:ssg-package_xorg-x11-server-common_removed:def:1" version="1">
          <ns0:metadata>
            <ns0:title>Package xorg-x11-server-common Removed</ns0:title>
            <ns0:affected family="unix">
              <ns0:platform>Red Hat Enterprise Linux 7</ns0:platform>
            </ns0:affected>
            <ns0:description>The RPM package xorg-x11-server-common should be removed.</ns0:description>
            <reference ref_id="CCE-27218-7" source="CCE"/>
            <reference ref_id="package_xorg-x11-server-common_removed" source="ssg"/>
          </ns0:metadata>
          <ns0:criteria>
            <ns0:criterion comment="package xorg-x11-server-common is removed" test_ref="oval:ssg-test_package_xorg-x11-server-common_removed:tst:1"/>
          </ns0:criteria>
        </ns0:definition>


Version-Release number of selected component (if applicable):


How reproducible:
- Always

Steps to Reproduce:
1. Install RHEL 7.6 with DISA STIG and "Server with GUI" packages

OR

1. Install RHEL 7.6 with "Server with GUI"
2. Install openscap and scap-security-guide
3. Remediate using openscap with DISA STIG profile

Actual results:
- System will hang on black screen during boot
- When system stops at boot hitting ctrl+alt+F2 will take you to another tty with a full login prompt

Expected results:
- Some alert that remediation will not allow GUI to run would likely be ideal (during the installer or during remediation). The installer notification could be similar to those for if you pick the DISA STIG and don't have proper partitioning which does not allow you to continue installation in the Anaconda environment.

Additional info:
- For people who may not be aware of what is included in DISA STIG this is an issue. They will install the system and then reboot only to realize that the system does not drop you to a terminal or change the default systemd target. There is no notification of what happened, so without having the knowledge to know that you can change to another tty you will think that your system is unresponsive.
- Unsure if this issue should be opened against scap-security-guide, but since the issue appears both during the anaconda environment as well as after installation
Comment 2 Watson Yuuma Sato 2018-11-16 14:31:05 UTC 
Hello, 

Regarding the remediation, we can change the default systemd target when removing package xorg-x11-server-common. This would require changes in bash remediation and in the OVAL check.

Regarding notification to user,
Oscap addon will print an info message for every package that a policy would like to remove.
It is possible to make oscap addon print an extra warning message for specific packages, with clear message of consequences of removal of this specific package.
But I don't agree with not allowing installation, having a server with GUI hardened with DISA STIG policy is a valid use case.
Comment 3 Ryan Mullett 2018-11-16 17:10:14 UTC 
(In reply to Watson Yuuma Sato from comment #2)
> Hello, 
> 
> Regarding the remediation, we can change the default systemd target when
> removing package xorg-x11-server-common. This would require changes in bash
> remediation and in the OVAL check.
> 
> Regarding notification to user,
> Oscap addon will print an info message for every package that a policy would
> like to remove.
> It is possible to make oscap addon print an extra warning message for
> specific packages, with clear message of consequences of removal of this
> specific package.
> But I don't agree with not allowing installation, having a server with GUI
> hardened with DISA STIG policy is a valid use case.

That is fine with me. I agree that it is a valid use case, and we certainly see users who use their systems in that way. The recommendations you make seem that they would be acceptable workarounds. 

My only concern would be that we will have users who will expect that their system is going to come up with GUI, but the default target has been changed. Hopefully the clear message with consequences of removal can address that in a way that will be highly visible to users who would run into this issue.
Comment 8 Watson Yuuma Sato 2020-01-23 14:03:20 UTC 
Hello,

To fix this bug the target of the system should be changed, so that the system doesn't hang, like mentioned in comment 1.
And instead of updating oscap-anaconda-addon to warn about implications of packages removed,
would a warning in the profile description suffice?
Comment 9 Joe Wright 2020-01-27 15:23:53 UTC 
IMO we probably need to do both because we cant make any assumptions as to when the profile will be applied
Comment 10 Brandon Clark 2020-04-28 20:38:24 UTC 
A customer has recently mentioned that a new version of the upstream DISA STIG for RHEL 7 was released on April 23rd, Version 2 Release 7. I am attaching this STIG to the listing.
Comment 11 Brandon Clark 2020-04-28 20:40:21 UTC 
Created attachment 1682621 [details]
Latest upstream version release of DISA STIG for RHEL7 that resolves issue.
Comment 12 Matěj Týč 2020-04-30 15:09:28 UTC 
Fixed upstream:
default boot rule improvement: https://github.com/ComplianceAsCode/content/pull/5625
selection of thereof in STIG: https://github.com/ComplianceAsCode/content/pull/5659
Comment 14 ralford 2020-05-11 20:06:37 UTC 
The behavior is very expected. Installing the GUIs introduce a lot of different types of vulnerabilities which is why the STIG removes it. 
However, GUI installation and operation can be required based on certain operational requirements. Customers need to use and follow the appropriate SCAP tools to enable GUI usage.
This means that customers need to tailor the GUI profile to remove the rule that uninstalls the GUI. Tailoring is meant to handle different operational requirements that government
customers have which means adding/removing rules based on their requirements. There is an expectation that the customer reviews the DISA STIG and does not blindly apply the STIG.
DISA expects this as well. We (Red Hat) cannot add/remove rules to the STIG without DISA approval.

Please update https://access.redhat.com/solutions/3755211 to show customers how to tailor a profile to remove the xorg-x11-server-common rule as this is the appropriate action to take.

In addition, we will make a request to DISA to add a new rule to change the runlevel target from a graphical.target to the multi-user.target.
This request will take time and may or may not be agreed to by DISA in the next STIG release.
Comment 15 Ryan Mullett 2020-05-11 20:22:53 UTC 
(In reply to ralford from comment #14)
> The behavior is very expected. Installing the GUIs introduce a lot of
> different types of vulnerabilities which is why the STIG removes it. 
> However, GUI installation and operation can be required based on certain
> operational requirements. Customers need to use and follow the appropriate
> SCAP tools to enable GUI usage.
> This means that customers need to tailor the GUI profile to remove the rule
> that uninstalls the GUI. Tailoring is meant to handle different operational
> requirements that government
> customers have which means adding/removing rules based on their
> requirements. There is an expectation that the customer reviews the DISA
> STIG and does not blindly apply the STIG.
> DISA expects this as well. We (Red Hat) cannot add/remove rules to the STIG
> without DISA approval.
> 
> Please update https://access.redhat.com/solutions/3755211 to show customers
> how to tailor a profile to remove the xorg-x11-server-common rule as this is
> the appropriate action to take.
> 
> In addition, we will make a request to DISA to add a new rule to change the
> runlevel target from a graphical.target to the multi-user.target.
> This request will take time and may or may not be agreed to by DISA in the
> next STIG release.

I certainly agree that it's expected behavior that they are not compatible. That is not the issue at hand here.

The expectation from the installation side, and one that our users share is that when you complete an installation you have a functional system.

There's already precedent for other warnings during installation if you enable DISA STIG that prevent you from installing. For example, if your partitions are not configured as required for DISA STIG it will not even allow you off of the "select a security profile" screen. You must go back and configure the required partitions before being allowed to select that profile. 

A tailoring profile is fine as a workaround, but that's not really a permanent solution. It doesn't at all address users who desire to do an installation through the anaconda GUI. Those users will still end up with a system that boots to a black screen without warning.  It will only address users who are already doing a more advanced kickstart installation.

Changing default from graphical.target to multi-user.target is fine as well, but we would still need some warning, because users will still expect that when they pick a GUI they will end up with a GUI unless we alert them otherwise.
Comment 16 ralford 2020-05-12 00:12:52 UTC 
(In reply to Ryan Mullett from comment #15)
> (In reply to ralford from comment #14)
> > The behavior is very expected. Installing the GUIs introduce a lot of
> > different types of vulnerabilities which is why the STIG removes it. 
> > However, GUI installation and operation can be required based on certain
> > operational requirements. Customers need to use and follow the appropriate
> > SCAP tools to enable GUI usage.
> > This means that customers need to tailor the GUI profile to remove the rule
> > that uninstalls the GUI. Tailoring is meant to handle different operational
> > requirements that government
> > customers have which means adding/removing rules based on their
> > requirements. There is an expectation that the customer reviews the DISA
> > STIG and does not blindly apply the STIG.
> > DISA expects this as well. We (Red Hat) cannot add/remove rules to the STIG
> > without DISA approval.
> > 
> > Please update https://access.redhat.com/solutions/3755211 to show customers
> > how to tailor a profile to remove the xorg-x11-server-common rule as this is
> > the appropriate action to take.
> > 
> > In addition, we will make a request to DISA to add a new rule to change the
> > runlevel target from a graphical.target to the multi-user.target.
> > This request will take time and may or may not be agreed to by DISA in the
> > next STIG release.
> 
> I certainly agree that it's expected behavior that they are not compatible.
> That is not the issue at hand here.
> 
> The expectation from the installation side, and one that our users share is
> that when you complete an installation you have a functional system.
> 
> There's already precedent for other warnings during installation if you
> enable DISA STIG that prevent you from installing. For example, if your
> partitions are not configured as required for DISA STIG it will not even
> allow you off of the "select a security profile" screen. You must go back
> and configure the required partitions before being allowed to select that
> profile. 
> 
> A tailoring profile is fine as a workaround, but that's not really a
> permanent solution. It doesn't at all address users who desire to do an
> installation through the anaconda GUI. Those users will still end up with a
> system that boots to a black screen without warning.  It will only address
> users who are already doing a more advanced kickstart installation.
> 
> Changing default from graphical.target to multi-user.target is fine as well,
> but we would still need some warning, because users will still expect that
> when they pick a GUI they will end up with a GUI unless we alert them
> otherwise.

The warning is already provided with the notification of the package that is being removed in the OAA plugin.
An addition warning has been added to the SCAP content itself which won't appear for the users to see during install.
If the desired request is to have OAA prevent install, then the BZ needs to be opened against OAA to prevent
an install from continuing if the GUI is selected, and one of the profiles removes it unless a tailored profile is used. 
Tailoring isn't a workaround. It is the expected process and solution for government users of security profiles.
The DISA STIG will never fully result in a working system and one that fully meets all user requirements.
Comment 17 Ryan Mullett 2020-05-12 22:22:46 UTC 
>If the desired request is to have OAA prevent install, then the BZ needs to be opened against OAA to prevent
>an install from continuing if the GUI is selected, and one of the profiles removes it unless a tailored profile is used. 
>Tailoring isn't a workaround. It is the expected process and solution for government users of security profiles.
>The DISA STIG will never fully result in a working system and one that fully meets all user requirements.

Just to clarify, I am not stating that OAA should prevent install. I am saying that OAA should prevent incompatible options to be selected in conjunction with the selected SCAP profile. If the X server isn't allowed to be installed, fine. But it would be necessary for the OAA side to notify that is the case and prompt the end user to take action instead of just (semi) silently proceeding forwards towards what looks like a broken installation. 

You have to remember in instances like this that we are dealing with the installer. The first interaction that many have with the RHEL OS, so we can't simply guarantee that sane configuration options have been selected.

Since the request to have the installation halt when the user has selected these incompatible options was in my initial description on the bug, and I see there was discussion regarding OAA earlier in this bz I'm going to go ahead and change component to OAA at this time rather than getting a duplicate bz for the same issue and losing all of the context here.
Comment 18 Marek Haicman 2020-05-13 14:37:16 UTC 
Hey :) Adding the support into OAA would be significant change that given we are very deep in the Maintenance Support Phase 2 in the RHEL7 means it is not going to happen. My proposal is to keep it as a known issue of the RHEL7 STIG.

Are you OK with that Ryan?
Comment 19 Ryan Mullett 2020-05-13 22:01:23 UTC 
(In reply to Marek Haicman from comment #18)
> Hey :) Adding the support into OAA would be significant change that given we
> are very deep in the Maintenance Support Phase 2 in the RHEL7 means it is
> not going to happen. My proposal is to keep it as a known issue of the RHEL7
> STIG.
> 
> Are you OK with that Ryan?

That's fine with me. This issue remains on RHEL 8, although in the case of RHEL 8 fails during the installation rather than completing (bz 1787156).
Comment 23 Marek Haicman 2020-05-21 12:12:04 UTC 
As per agreement, I am closing this as WONTFIX. See Comment 18 and Comment 19
Note You need to log in before you can comment on or make changes to this bug.