Powered by Plus3 IT Systems

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].

Finding Summary

Finding Identifiers

Prevent System Daemons From Using Kerberos For Authentication

V-230238

RHEL-08-010161

Users Must Provide A Password For Privilege Escalation

V-230271

RHEL-08-010380

A Separate Filesystem Must Be Used For the /tmp Directory

V-230295

RHEL-08-010543

The OS must mount /tmp with the nodev option

V-230511

RHEL-08-040123

The OS must mount /tmp with the nosuid option

V-230512

RHEL-08-040124

The OS must mount /tmp with the noexec option

V-230514

RHEL-08-040125

The OS Must Ensure Session Control Is Automatically Started At Shell Initialization

V-230349

RHEL-08-020041

User Account Passwords Must Be Restricted To A 60-Day Maximum Lifetime

V-230367

RHEL-08-020210

OS Must Prohibit Password Reuse For A Minimum Of Five Generations

V-230368

RHEL-08-020220

The Installed Operating System Is Not Vendor Supported

V-230221

RHEL-08-010000

All remote access methods must be monitored

V-230228

RHEL-08-010070

All Content In A User’s Home Directory Must Be Group-Owned By The Primary User

V-244532

RHEL-08-010741

“Only Authorized Local User Accounts Exist on Operating System” is always flagged

V-230379

RHEL-08-020320

All Interactive User Home Directory Files Must Be Mode 0750 Or Less Permissive

V-244531

RHEL-08-010731

Add nosuid Option to /boot

V-230300

RHEL-08-010571

Configure Multiple DNS Servers in /etc/resolv.conf

V-230316

RHEL-08-010680

Enable Certmap in SSSD

V-230355

RHEL-08-020090

Verify that Shared Library Directories Have Root Ownership

V-251709

RHEL-08-010351

Oracle Linux 8 STIGs Specify Conflicting ClientAliveCountMax values

V-248552

OL08-00-010200

Record Events When Privileged Executables Are Run

V-248722

OL08-00-030000

EL 8 systems less than v8.4 must configure the password complexity module in the system-auth allow three retries or less

V-251714

RHEL-08-020102

EL 8 must enable the hardware random number generator entropy gatherer service

V-230285

RHEL-08-010471

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 the systemd RPM

  • /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-managed systemd RPM’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-client

  • redhat-release-server

  • redhat-release-workstation

  • redhat-release-computenode

  • redhat-release-virtualization-host

  • oraclelinux-release

  • sled-release

  • sles-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 --version
    
  • The 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

“Only Authorized Local User Accounts Exist on Operating System” is always flagged

Expected Finding:

Per the STIG notes:

Automatic remediation of this control is not available due to the unique requirements of each system.

While-automation could be authored that would leverage a site- or host-specific allowed-users list to disable or delete forbidden accounts, there exists an extremely-high likelihood that scanners used against such configuration-controlled operating environments would not contain the scanning logic necessary to validate compliance. As such – and with or without user-controlling automation-content – STIG scanners would still flag systems that are technically compliant.

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).

Verify that Shared Library Directories Have Root Ownership

Expected Finding:

Some applications and/or enterprise-integration tools may install private shared-libraries that are user- or group- owned by the installed-application. The scanner may identify these as insecure/improperly-owned, regardless of permission-setting on higherl-level directories.

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.rules

  • grep -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.