You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Applying xccdf_org.ssgproject.content_profile_stig or xccdf_org.ssgproject.content_profile_stig_gui causes the Anaconda installer in RHEL 8 and 9 to exclude the nfs-utils package, which makes the system unable to mount an NFS share.
Specifying an NFS install source directly results in a misconfiguration message on the security profile tab, completely interrupting the automated installation process:
Defining a repo in the kickstart.cfg in the following manner results in a successful unattended install, but the system wakes up unable to mount NFS shares.
Why is the STIG security profile removing the package? It is not listed anywhere in the RHEL 8 STIG, but I can see clearly in the profile (and in the Anaconda GUI output) where the nfs-utils package is being excluded.
When you search the RHEL 8 V1R11 STIG dated 26 July 2023 for the keyword 'nfs', 4 group IDs pop up. V-230306, V-230307, and V-230308 deal with setting the noexec, nodev, and nosuid fs options in /etc/fstab for persistent NFS mounts. V-230502 concerns disabling the autofs.service, unless a documented need is filed with the ISSO. I was also not able to find a reference to the package in earlier releases of the RHEL 8 STIG. I was likewise unable to find a reference to the package in the V3R12 release of the RHEL 7 STIG.
I realize in connected environments (or places where you have Satellite) this isn't a particularly big deal because you can connect to the Red Hat CDN, a web-based repo, or your Satellite server. In a disconnected environment without these resources (or where something like web-based repo would not be approved), things get hairy right at step 1. I can understand if there was an actual requirement to purge the package, but I am seeing no such requirement levied by DISA.
Is this the appropriate place to report this kind of issue? Our desired outcome would be simply for the nfs-utils package to be removed from the list of excluded packages.
Thanks!
The text was updated successfully, but these errors were encountered:
Applying xccdf_org.ssgproject.content_profile_stig or xccdf_org.ssgproject.content_profile_stig_gui causes the Anaconda installer in RHEL 8 and 9 to exclude the nfs-utils package, which makes the system unable to mount an NFS share.
Specifying an NFS install source directly results in a misconfiguration message on the security profile tab, completely interrupting the automated installation process:
Defining a repo in the kickstart.cfg in the following manner results in a successful unattended install, but the system wakes up unable to mount NFS shares.
Why is the STIG security profile removing the package? It is not listed anywhere in the RHEL 8 STIG, but I can see clearly in the profile (and in the Anaconda GUI output) where the nfs-utils package is being excluded.
When you search the RHEL 8 V1R11 STIG dated 26 July 2023 for the keyword 'nfs', 4 group IDs pop up. V-230306, V-230307, and V-230308 deal with setting the noexec, nodev, and nosuid fs options in /etc/fstab for persistent NFS mounts. V-230502 concerns disabling the autofs.service, unless a documented need is filed with the ISSO. I was also not able to find a reference to the package in earlier releases of the RHEL 8 STIG. I was likewise unable to find a reference to the package in the V3R12 release of the RHEL 7 STIG.
I realize in connected environments (or places where you have Satellite) this isn't a particularly big deal because you can connect to the Red Hat CDN, a web-based repo, or your Satellite server. In a disconnected environment without these resources (or where something like web-based repo would not be approved), things get hairy right at step 1. I can understand if there was an actual requirement to purge the package, but I am seeing no such requirement levied by DISA.
Is this the appropriate place to report this kind of issue? Our desired outcome would be simply for the nfs-utils package to be removed from the list of excluded packages.
Thanks!
The text was updated successfully, but these errors were encountered: