Bug 1787156
| Summary: | When using the "Protection Profile for General Purpose Operating Systems" profile, remove the "Server with GUI" option or add a warning that the install will fail | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 8 | Reporter: | jcastran |
| Component: | oscap-anaconda-addon | Assignee: | Matěj Týč <matyc> |
| Status: | CLOSED ERRATA | QA Contact: | Release Test Team <release-test-team-automation> |
| Severity: | high | Docs Contact: | Jan Fiala <jafiala> |
| Priority: | medium | ||
| Version: | 8.2 | CC: | jafiala, jkonecny, jstodola, jucastro, kwalker, matyc, mhaicman, mjahoda, pzatko, wsato |
| Target Milestone: | rc | ||
| Target Release: | 8.0 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Known Issue | |
| Doc Text: |
.OSPP-based profiles are incompatible with GUI package groups.
`GNOME` packages installed by the _Server with GUI_ package group require the `nfs-utils` package that is not compliant with the Operating System Protection Profile (OSPP). As a consequence, selecting the _Server with GUI_ package group during the installation of a system with OSPP or OSPP-based profiles, for example, Security Technical Implementation Guide (STIG), OpenSCAP displays a warning that the selected package group is not compatible with the security policy. If the OSPP-based profile is applied after the installation, the system is not bootable. To work around this problem, do not install the _Server with GUI_ package group or any other groups that install GUI when using the OSPP profile and OSPP-based profiles. When you use the _Server_ or _Minimal Install_ package groups instead, the system installs without issues and works correctly.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2020-11-04 03:46:16 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | 1839769 | ||
| Bug Blocks: | |||
|
Description
jcastran
2019-12-31 15:56:17 UTC
This seems like an OSCAP Anaconda addon option. Switching to OSCAP for further triage. We made preliminary analysis: As OSCAP Anaconda Addon allows custom content to be used, there is no simple way of testing it before release, and ensuring there's no conflict. Let's assume the environments do not have conflicts within themselves, and that is tested before the release. That means if the conflict arise, it's most likely because of restrictions imposed by the selected Security policy. Therefore there are some approaches how to make this issue less painful for the users: * Document somewhere within OAA, when packages are being removed, that there is a risk the installation will fail due to the conflict. We cannot specify which environments will fail, so the warning would have to be shown every time. ** There might be added an option to mark "risky" packages, or in reverse, mark packages that are not likely to cause conflicts, to make information more targeted * Have environment restrictions part of the profile description (won't cover custom content) * Look into the requirement, and challenge the need to force removal of nfs-utils https://github.com/OpenSCAP/oscap-anaconda-addon/pull/121 Removed the Feature keyword, as this is not a feature, but rather a bugfix. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (oscap-anaconda-addon bug fix and enhancement update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2020:4772 Hi Lucie, just confirmed with @matyc and the doc text is current. Nothing has changed since the doc text was published. |