Findings Summary-Table¶
A few scans performed against EL8 systems are version-dependent. Watchmaker is designed to ensure that a given EL8 host is running at the latest-available EL8 minor-release version. Some of the version-dependent scans are for versions (well) prior “the latest-available EL8 minor-release version”. The person responding to scan-findings should make sure to notice if the findings-text includes mention of specific EL8 minor-release version or version-ranges and compare that to the EL8 minor-release of the scanned system. If the version/version-range is less than that of the scanned version, the scan result may be immediately flagged as “INVALID FINDING”. Anything that cannot be immediate flagged in this way should be checked against the following table of known findings[1].
Prevent System Daemons From Using Kerberos For Authentication¶
Condtionally-valid Finding:
If an EL8 system is bound to Active Directory – or other Kerberos-enabled centralized authentication-source – or is acting as a Kerberos domain controller (KDC), the presence of an /etc/krb5.keytab file is mandatory.
If the scanned system does not have the krb5-workstation or krb5-server packages installed and any .keytab files are found in the /etc directory, this is a valid finding.
Users Must Provide A Password For Privilege Escalation¶
Condtionally-valid Finding:
If a sudo-enabled user is password-enabled, they should be prompted for that password in order to escalate privileges.
If a sudo-enabled user is not password-enabled (e.g, if the user is used only with key- or token-based authentication), they should not be prompted for any password. Forcing use of passwords for sudo-enabled users that do not have passwords will render those user-accounts unable to escalate privileges. Failure to exempt such users will render “break glass” and similar accounts not usable for their intended function.
A Separate Filesystem Must Be Used For the /tmp Directory¶
Invalid Finding:
When using Amazon Machine Images, Azure VM-templates, or the like, that have been built using the spel automation, the /tmp directory in the resultant EC2 (VM, etc.) is hosted on a psuedo-filesystem of type tmpfs. This is done using the tmp.mount systemd unit. Many security-scanning tools that look for /tmp-related mount-information do not know how to properly scan when tmp is used this way and will, as a result, report a (spurious) finding.
Proof of Correctness:
To validate that the required-setting is actually present, execute:
grep -w /tmp /proc/mounts
If this returns null, the scan-result is valid; otherwise the scan-result is invalid.
The OS must mount /tmp with the nodev option¶
Invalid Finding:
When using Amazon Machine Images, Azure VM-templates, or the like, that have been built using the spel automation, the tmp.mount systemd unit is used to manage mounting of the tmpfs-based /tmp directory. Mount options – such as nodev – are defined through two files:
/usr/lib/systemd/system/tmp.mount: This file contains the vendor-defined defaults and is installed via thesystemdRPM/etc/systemd/system/tmp.mount.d/options.conf: This file is installed via watchmaker’s state-handler,ash-linux.el8.STIGbyID.cat2.RHEL-08-040123. This file overrides the values held in the vendor-managedsystemdRPM’s file
Many security-scanners do not know how to find the mount-options for the /tmp (pseudo) filesystem when it is managed via systemd and uses these files to set the mount options. As a result, such scanners will report a (spurious) finding
Proof of Correctness:
To validate that the required-setting is actually present, execute:
grep -w /tmp /proc/mounts | grep nodev
If this returns null, the scan-result is valid; otherwise the scan-result is invalid.
The OS must mount /tmp with the nosuid option¶
Invalid Finding:
As with the “The OS must mount /tmp with the nodev option” finding, this finding is due to an incompatibility between how the scanner checks for the setting and how the setting is actually implemented.
Proof of Correctness:
To validate that the required-setting is actually present, execute:
grep -w /tmp /proc/mounts | grep nosuid
If this returns null, the scan-result is valid; otherwise the scan-result is invalid.
The OS must mount /tmp with the noexec option¶
Invalid Finding:
As with the “The OS must mount /tmp with the nodev option” finding, this finding is due to an incompatibility between how the scanner checks for the setting and how the setting is actually implemented.
Proof of Correctness:
To validate that the required-setting is actually present, execute:
grep -w /tmp /proc/mounts | grep noexec
If this returns null, the scan-result is valid; otherwise the scan-result is invalid.
The OS Must Ensure Session Control Is Automatically Started At Shell Initialization¶
Invalid Finding:
As implemented, watchmaker places an /etc/profile.d/tmux.sh file that looks like:
# Check if shell is interactive
if [[ $- == *i* ]] && [[ $( rpm --quiet -q tmux )$? -eq 0 ]]
then
parent=$( ps -o ppid= -p $$ )
name=$( ps -o comm= -p $parent )
# Check if controlling-process is target-value
case "$name" in
sshd|login)
exec tmux
;;
esac
fi
This file addresses the concerns of the STIG finding-ID, but does so in a functionally-safer way. The additional ‘safing’ included in the watchmaker-placed script may cause scanners that are too-inflexibly coded to spuriously declare a finding.
User Account Passwords Must Be Restricted To A 60-Day Maximum Lifetime¶
Invalid Finding:
Some, locally-managed user’s accounts are configured only for token-based logins (SSH keys, GSSAPI, etc.). The accounts are typically configured with no passwords. Some of these accounts also serve a “break-glass” function. If passwordless accounts are configured with password-expiry enabled, they may become no longer fit for purpose once they’ve reached their expiry.
Many scanners are not adequately configured to differentiate between passwordless and password-enabled locally-managed accounts. Typically, poorly-configured scanners will execute a compliance-test equivalent to:
awk -F: '$5 > 60 { print $1 " " $5 }' /etc/shadow
awk -F: '$5 <= 0 { print $1 " " $5 }' /etc/shadow
Or, expressed more compactly:
awk -F: '$5 > 60 || $5 <= 0 { print $0 }' /etc/shadow
If so, such scanners will assert a finding that is not actually valid for locked-password accounts.
Proof of Correctness:
To validate that passwordless accounts are properly configured, instead execute:
awk -F: '$2 !~ /^[!*]*/ && ( $5 > 60 || $5 <= 0 ) { print $0 }' /etc/shadow
The above adds the further check of each line of the /etc/shadow file’s second field (hashed password string) for the tokens indicating a locked-password account (! and/or *). Adding this further check should yield a null return
OS Must Prohibit Password Reuse For A Minimum Of Five Generations¶
Invalid Finding:
Red Hat has updated the method for implementing this guidance. The remember token is now configured in the /etc/security/pwhistory.conf configuration file rather than the previously-used /etc/pam.d/* files.
If the scanner is flagging the /etc/pam.d/* files for lacking a remember token, this is a sign that the scanner’s profiles need to be updated.
Proof of Correctness:
To validate that the required remember=5 is present, execute:
$ grep -P '^(#|)remember' /etc/security/pwhistory.conf
The above should return a value similar to:
remember = 5
If the above has a null return, re-execute the ash-linux.el8.STIGbyID.cat2.RHEL-08-pam_pwhistory Saltstack state and re-validate.
The Installed Operating System Is Not Vendor Supported¶
Expected Finding:
This rule effects primarily “free” versions of the Red Hat Enterprise Linux operating system. This result is expected on the CentOS 8 – “Core” or “Stream” – Rocky and Alma linux distributions. Scanners that highlight this finding are looking for the presence of any one of the following RPMs:
redhat-release-clientredhat-release-serverredhat-release-workstationredhat-release-computenoderedhat-release-virtualization-hostoraclelinux-releasesled-releasesles-release
And an /etc/redhat-release file with contents that aligns to one that’s delivered with any of the preceding RPM. The various “free” versions of the Red Hat Enterprise Linux operating system will not have any of the above RPMs present.
If using a vendor-supported Linux and this scan finding occurs, it’s likely that either the release- RPM is missing or damaged, something has unexpectedly altered the target’s /etc/redhat-release file or the scanner is looking for a wildcarded release file under the /etc directory and there’s an unexpected filename found.
All Remote Access Methods Must Be Monitored¶
Invalid Finding:
After execution of hardening-routines, the scanned-for /etc/rsyslog.conf entries are present. Any indications to the contrary are in error.
Proof of Correctness:
To verify that the necessary entries are present, execute:
grep -P '^(?!#)\s*([^\s]+)\s+/var/log/secure' /etc/rsyslog.conf
This will return output similar to the following:
authpriv.* /var/log/secure
daemon.* /var/log/secure
auth.* /var/log/secure
Note: The above modification is made through the watchmaker-bundled Compliance as Code content. If the above entries are missing, ensure that the installed version of watchmaker is up to date, then rerun the el8.VendorSTIG.remediate state.
The version of watchmaker may be checked by doing:
/usr/local/bin/watchmaker --versionThe version of Compliance as Code installed may be checked by doing
# find /srv/watchmaker/salt/formulas/scap-formula/scap/content/guides/openscap -type f | \ xargs grep '\s\s<xccdf.*version\supdate=' | \ sed -e 's/^.*latest">//' -e 's/<.*$//' | \ sort -u
All Content In A User’s Home Directory Must Be Group-Owned By The Primary User¶
Expected Finding:
At initial scan, this finding is typically triggered by the installation of some standard “enterprise” services. Some of these services, due to how they execute, will create some of their files with root as the user- and/or (more importantly for this finding) group-owner.
The oscap content for this finding includes the caveat:
Due to OVAL limitation, this rule can report a false negative in a specific situation where two interactive users swap the group-ownership of folders or files in their respective home directories.
While not a 100% overlap to the reason offered here, the caveat covers a common scenario. Other common scenarios may include:
Unpacking of archive files authored on a different system
Restoration of a user’s
${HOME}from another system to the current (scanned) system
In either of these further cases, such will most typically only show up on lifecycle scans and not provisioning-time scans
All Interactive User Home Directory Files Must Be Mode 0750 Or Less Permissive¶
Expected Finding:
Some scanners will erroneously alert on this for either/both of two reasons:
The scanner is looking for files that have mode-zero for their “all” field regardless of owning-directory’s mode-setting: in this case, the result is technically a correct finding but, from an effective security perspective is non-problematic
The scanner may be confused if the “failed” file’s group-permission is zero: in this case, the result is simply not valid
Add nosuid Option to /boot¶
Invalid Finding:
Some scanners will check to see what the mount-option is for the filesystem containing the /boot directory without first ensuring that /boot directory is actually a standalone filesystem. When /boot is not a standalone filesystem, it gets the same boot-options as the / filesystem and, therefore, cannot have the nosuid mount-option set.
Configure Multiple DNS Servers in /etc/resolv.conf¶
Expected Finding:
When deploying EL8 systems into environments with highly-available DNS servers, the system will typically only have one DNS server configured.
Enable Certmap in SSSD¶
Invalid Finding:
This finding is intended to result in a manual configuration-validation of the target system. Scanners that flag this finding typically include a note like:
Automatic remediation of this control is not available since all of the settings in the certmap need to be customized
Further, configuration of the sssd certmap is typically required only for systems that are configured for direct authentication via client-certificate. This configuration-method is typically done only for systems with locally-attached SmartCard/PIV readers. “Remote” systems (such as those hosted with a CSP like AWS or Azure) typically indirectly authenticate with client-certificates (either through SSH key-forwarding or GSSAPI token-forwarding).
Oracle Linux 8 STIGs Specify Conflicting ClientAliveCountMax values¶
Conflicting Guidance:
As of the time of this section’s writing, there is a disagreement between the DISA STIG’s target-value for the SSH daemon’s ClientAliveCountMax value and that specified via the STIG’s upstream content-project, Compliance As Code. The former specifies that the parameter’s value should be 1; the latter specifies that it should be 0. This project’s hardening implements the former as that is also the value specified by both the DISA STIG’s and Compliance As Code project’s recommended setting for Red Hat Linux 8.
Record Events When Privileged Executables Are Run¶
Invalid Finding:
Some security-scanners misidentify the compliance-state of target-systems for vulnerability-ID, V-248722 (OL08-00-030000). The relevant STIG check-text should be either or both of:
grep execve /etc/audit/audit.rulesgrep -r execve /etc/audit/rules.d
After watchmaker is applied, the former returns:
-a always,exit -F arch=b32 -S execve -C gid!=egid -F key=setgid
-a always,exit -F arch=b64 -S execve -C gid!=egid -F key=setgid
-a always,exit -F arch=b32 -S execve -C uid!=euid -F key=setuid
-a always,exit -F arch=b64 -S execve -C uid!=euid -F key=setuid
While the latter returns:
/etc/audit/rules.d/setuid.rules:-a always,exit -F arch=b32 -S execve -C uid!=euid -F key=setuid
/etc/audit/rules.d/setuid.rules:-a always,exit -F arch=b64 -S execve -C uid!=euid -F key=setuid
/etc/audit/rules.d/setgid.rules:-a always,exit -F arch=b32 -S execve -C gid!=egid -F key=setgid
/etc/audit/rules.d/setgid.rules:-a always,exit -F arch=b64 -S execve -C gid!=egid -F key=setgid
It is the presence of the content in the file in the /etc/audit/rules.d/ directory that results in – by way of the augenrules service – the presence of the correct content in the /etc/audit/audit.rules file.
EL 8 systems less than v8.4 must configure the password complexity module in the system-auth allow three retries or less¶
Invalid Finding:
This finding applies only to Enterprise Linux distros 8.0, 8.1, 8.2 and 8.3. As of the writing of this document all, properly-patched Enterprise Linux deployments are running 8.4 or higher. This finding does not apply to such systems
EL 8 must enable the hardware random number generator entropy gatherer service¶
Invalid Finding:
While this finding states that the rngd systemd unit must be enabled and active. Per the output from the rngd.service systemd unit:
$ systemctl status rngd
* rngd.service - Hardware RNG Entropy Gatherer Daemon
Loaded: loaded (/usr/lib/systemd/system/rngd.service; enabled; vendor preset: enabled)
Active: inactive (dead) since Tue 2023-06-27 15:21:25 UTC; 49s ago
Condition: start condition failed at Tue 2023-06-27 15:21:32 UTC; 42s ago
ConditionKernelCommandLine=!fips=1 was not met
Main PID: 214 (code=exited, status=0/SUCCESS)
The above-captured output’s ConditionKernelCommandLine’s indication that the condition of !fips=1 “was not met” means that this capability is not (currently) compatible with a system running with FIPS mode enabled. Enablement of FIPS mode is specified in another, earlier, higher-priority STIG-finding. As such, this setting will not be enableable while the higher-priority configuration-state is in place.