Hide Forgot
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
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.
(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.
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?
IMO we probably need to do both because we cant make any assumptions as to when the profile will be applied
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.
Created attachment 1682621 [details] Latest upstream version release of DISA STIG for RHEL7 that resolves issue.
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
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.
(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.
(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.
>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.
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?
(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).
As per agreement, I am closing this as WONTFIX. See Comment 18 and Comment 19