oscap-anaconda-addon
oscap-anaconda-addon copied to clipboard
RHEL 8, Draft 9 DISA STIG (and STIG w/GUI) Profiles remove nfs-utils, breaking nfs-based installs
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:
repo --install --name=AppStream_NFS --baseurl=nfs://hostname:/path/to/rhel9/rhel-9-for-x86_64-appstream-rpms/
repo --install --name=BaseOS_NFS --baseurl=nfs://hostname:/path/to/repos/rhel9/rhel-9-for-x86_64-baseos-rpms/
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.
repo --install --name=AppStream_NFS --baseurl=nfs://hostname:/path/to/rhel9/rhel-9-for-x86_64-appstream-rpms/
repo --install --name=BaseOS_NFS --baseurl=nfs://hostname:/path/to/rhel9/rhel-9-for-x86_64-baseos-rpms/
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!