Guide to the Secure Configuration of Hummingbird

with profile Red Hat STIG for Red Hat Hummingbird
This is a profile based on what is expected in the Hummingbird STIG. It is not based on the DISA STIG for Hummingbird, because it was not available at time of the release. In addition to being applicable to Red Hat Hummingbird, this configuration baseline is applicable to the operating system tier of Red Hat technologies that are based on Red Hat Hummingbird.
This guide presents a catalog of security-relevant configuration settings for Hummingbird. It is a rendering of content structured in the eXtensible Configuration Checklist Description Format (XCCDF) in order to support security automation. The SCAP content is is available in the scap-security-guide package which is developed at https://www.open-scap.org/security-policies/scap-security-guide.

Providing system administrators with such guidance informs them how to securely configure systems under their control in a variety of network roles. Policy makers and baseline creators can use this catalog of settings, with its associated references to higher-level security control catalogs, in order to assist them in security baseline creation. This guide is a catalog, not a checklist, and satisfaction of every item is not likely to be possible or sensible in many operational scenarios. However, the XCCDF format enables granular selection and adjustment of settings, and their association with OVAL and OCIL content provides an automated checking capability. Transformations of this document, and its associated automated checking content, are capable of providing baselines that meet a diverse set of policy objectives. Some example XCCDF Profiles, which are selections of items that form checklists and can be used as baselines, are available with this guide. They can be processed, in an automated fashion, with tools that support the Security Content Automation Protocol (SCAP). The DISA STIG, which provides required settings for US Department of Defense systems, is one example of a baseline created from this guidance.
Do not attempt to implement any of the settings in this guide without first testing them in a non-operational environment. The creators of this guidance assume no responsibility whatsoever for its use by other parties, and makes no guarantees, expressed or implied, about its quality, reliability, or any other characteristic.
Profile TitleRed Hat STIG for Red Hat Hummingbird
Profile IDxccdf_org.ssgproject.content_profile_stig

Revision History

Current version: 0.1.81

  • draft (as of 2026-07-15)

Platforms

  • cpe:/a:redhat:hummingbird

Table of Contents

  1. System Settings
    1. Installing and Maintaining Software
    2. Account and Access Control
    3. File Permissions and Masks
  2. Services
    1. DNS Server
    2. FTP Server
    3. NFS and RPC
    4. Obsolete Services

Checklist

contains 63 rules

System Settings   [ref]group

Contains rules that check correct system settings.

contains 55 rules

Installing and Maintaining Software   [ref]group

The following sections contain information on security-relevant choices during the initial operating system installation process and the setup of software updates.

contains 6 rules

System and Software Integrity   [ref]group

System and software integrity can be gained by installing antivirus, increasing system encryption strength with FIPS, verifying installed software, enabling SELinux, installing an Intrusion Prevention System, etc. However, installing or enabling integrity checking tools cannot prevent intrusions, but they can detect that an intrusion may have occurred. Requirements for integrity checking may be highly dependent on the environment in which the system will be used. Snapshot-based approaches such as AIDE may induce considerable overhead in the presence of frequent software updates.

contains 3 rules

System Cryptographic Policies   [ref]group

Linux has the capability to centrally configure cryptographic polices. The command update-crypto-policies is used to set the policy applicable for the various cryptographic back-ends, such as SSL/TLS libraries. The configured cryptographic policies will be the default policy used by these backends unless the application user configures them otherwise. When the system has been configured to use the centralized cryptographic policies, the administrator is assured that any application that utilizes the supported backends will follow a policy that adheres to the configured profile. Currently the supported backends are:

  • GnuTLS library
  • OpenSSL library
  • NSS library
  • OpenJDK
  • Libkrb5
  • BIND
  • OpenSSH
Applications and languages which rely on any of these backends will follow the system policies as well. Examples are apache httpd, nginx, php, and others.

contains 2 rules

Install crypto-policies package   [ref]rule

The crypto-policies package needs to be present in the container or container image.

Rationale:

Centralized cryptographic policies simplify applying secure ciphers across an operating system and the applications that run on that operating system. Use of weak or untested encryption algorithms undermines the purposes of utilizing encryption to protect data.

Severity:  medium

Configure System Cryptography Policy   [ref]rule

The rule checks if settings for selected crypto policy are configured as expected. Configuration files in the /etc/crypto-policies/back-ends are either symlinks to correct files provided by Crypto-policies package or they are regular files in case crypto policy customizations are applied. Crypto policies may be customized by crypto policy modules, in which case it is delimited from the base policy using a colon.

Warning:  System Crypto Modules must be provided by a vendor that undergoes FIPS-140 certifications. FIPS-140 is applicable to all Federal agencies that use cryptographic-based security systems to protect sensitive information in computer and telecommunication systems (including voice systems) as defined in Section 5131 of the Information Technology Management Reform Act of 1996, Public Law 104-106. This standard shall be used in designing and implementing cryptographic modules that Federal departments and agencies operate or are operated for them under contract. See https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.140-2.pdf To meet this, the system has to have cryptographic software provided by a vendor that has undergone this certification. This means providing documentation, test results, design information, and independent third party review by an accredited lab. While open source software is capable of meeting this, it does not meet FIPS-140 unless the vendor submits to this process.
Rationale:

Centralized cryptographic policies simplify applying secure ciphers across an operating system and the applications that run on that operating system. Use of weak or untested encryption algorithms undermines the purposes of utilizing encryption to protect data.

Severity:  high

Operating System Vendor Support and Certification   [ref]group

The assurance of a vendor to provide operating system support and maintenance for their product is an important criterion to ensure product stability and security over the life of the product. A certified product that follows the necessary standards and government certification requirements guarantees that known software vulnerabilities will be remediated, and proper guidance for protecting and securing the operating system will be given.

contains 1 rule

The Installed Operating System Is Vendor Supported   [ref]rule

The installed operating system must be maintained by a vendor. Red Hat Enterprise Linux is supported by Red Hat, Inc. As the Red Hat Enterprise Linux vendor, Red Hat, Inc. is responsible for providing security patches.

Warning:  There is no remediation besides switching to a different operating system.
Rationale:

An operating system is considered "supported" if the vendor continues to provide security patches for the product. With an unsupported release, it will not be possible to resolve any security issue discovered in the system software.

Severity:  high

System Tooling / Utilities   [ref]group

The following checks evaluate the system for recommended base packages -- both for installation and removal.

contains 2 rules

Uninstall gssproxy Package   [ref]rule

The gssproxy package should not be present in the container or container image. Remove the gssproxy package from Containerfile and rebuild the container image.

Rationale:

gssproxy is a proxy for GSS API credential handling. Kerberos relies on some key derivation functions that may not be compatible with some site policies such as FIPS 140.

Severity:  medium

Uninstall tuned Package   [ref]rule

The tuned package should not be present in the container or container image. Remove the tuned package from Containerfile and rebuild the container image.

Rationale:

tuned contains a daemon that tunes the system settings dynamically. It does so by monitoring the usage of several system components periodically. Based on that information, components will then be put into lower or higher power savings modes to adapt to the current usage.

Severity:  medium

Updating Software   [ref]group

Hummingbird containers and container images contain an installed software catalog called the RPM database, which records metadata of installed RPM packages.

contains 1 rule

Ensure Red Hat GPG Key Installed   [ref]rule

To ensure the system can cryptographically verify base software packages come from Red Hat (and to connect to the Red Hat Network to receive them), the Red Hat GPG key must properly be installed.

Rationale:

Changes to software components can have significant effects on the overall security of the operating system. This requirement ensures the software has not been tampered with and that it has been provided by a trusted vendor. The Red Hat GPG key is necessary to cryptographically verify packages are from Red Hat.

Severity:  high

Account and Access Control   [ref]group

In traditional Unix security, if an attacker gains shell access to a certain login account, they can perform any action or access any file to which that account has access. Therefore, making it more difficult for unauthorized people to gain shell access to accounts, particularly to privileged accounts, is a necessary part of securing a system. This section introduces mechanisms for restricting access to accounts under Hummingbird.

contains 7 rules

Protect Accounts by Restricting Password-Based Login   [ref]group

Conventionally, Unix shell accounts are accessed by providing a username and password to a login program, which tests these values for correctness using the /etc/passwd and /etc/shadow files. Password-based login is vulnerable to guessing of weak passwords, and to sniffing and man-in-the-middle attacks against passwords entered over a network or at an insecure console. Therefore, mechanisms for accessing accounts by entering usernames and passwords should be restricted to those which are operationally necessary.

contains 1 rule

Verify Proper Storage and Existence of Password Hashes   [ref]group

By default, password hashes for local accounts are stored in the second field (colon-separated) in /etc/shadow. This file should be readable only by processes running with root credentials, preventing users from casually accessing others' password hashes and attempting to crack them. However, it remains possible to misconfigure the system and store password hashes in world-readable files such as /etc/passwd, or to even store passwords themselves in plaintext on the system. Using system-provided tools for password change/creation should allow administrators to avoid such misconfiguration.

contains 1 rule

All GIDs referenced in /etc/passwd must be defined in /etc/group   [ref]rule

Add a group to the system for each GID referenced without a corresponding group.

Rationale:

If a user is assigned the Group Identifier (GID) of a group not existing on the system, and a group with the Group Identifier (GID) is subsequently created, the user may have unintended rights to any files associated with the group.

Severity:  low

Secure Session Configuration Files for Login Accounts   [ref]group

When a user logs into a Unix account, the system configures the user's session by reading a number of files. Many of these files are located in the user's home directory, and may have weak permissions as a result of user error or misconfiguration. If an attacker can modify or even read certain types of account configuration information, they can often gain full access to the affected user's account. Therefore, it is important to test and correct configuration file permissions for interactive accounts, particularly those of privileged users such as root or system administrators.

contains 6 rules

Ensure that Users Have Sensible Umask Values   [ref]group

The umask setting controls the default permissions for the creation of new files. With a default umask setting of 077, files and directories created by users will not be readable by any other user on the system. Users who wish to make specific files group- or world-readable can accomplish this by using the chmod command. Additionally, users can make all their files readable to their group by default by setting a umask of 027 in their shell configuration files. If default per-user groups exist (that is, if every user has a default group whose name is the same as that user's username and whose only member is the user), then it may even be safe for users to select a umask of 007, making it very easy to intentionally share files with groups of which the user is a member.

contains 2 rules

Ensure the Default Bash Umask is Set Correctly   [ref]rule

To ensure the default umask for users of the Bash shell is set properly, add or correct the umask setting in /etc/bashrc to read as follows:

umask 027

Rationale:

The umask value influences the permissions assigned to files when they are created. A misconfigured umask value could result in files with excessive permissions that can be read or written to by unauthorized users.

Severity:  medium

Remediation script:   (show)


var_accounts_user_umask='027'


if grep -q "^[^#]*\bumask" "$NEWROOT/etc/bashrc" ; then
    sed -i -E -e "s/^([^#]*\bumask)[[:space:]]+[[:digit:]]+/\1 $var_accounts_user_umask/g" "$NEWROOT/etc/bashrc"
else
    echo "umask $var_accounts_user_umask" >> "$NEWROOT/etc/bashrc"
fi

Ensure the Default Umask is Set Correctly in /etc/profile   [ref]rule

To ensure the default umask controlled by /etc/profile is set properly, add or correct the umask setting in /etc/profile to read as follows:

umask 027
Note that /etc/profile also reads scripts within /etc/profile.d directory. These scripts are also valid files to set umask value. Therefore, they should also be considered during the check and properly remediated, if necessary.

Rationale:

The umask value influences the permissions assigned to files when they are created. A misconfigured umask value could result in files with excessive permissions that can be read or written to by unauthorized users.

Severity:  medium

Remediation script:   (show)

Complexity:low
Disruption:low
Reboot:false
Strategy:restrict

var_accounts_user_umask='027'


readarray -t profile_files < <(find $NEWROOT/etc/profile.d/ -type f -name '*.sh' -or -name 'sh.local')

for file in "${profile_files[@]}" $NEWROOT/etc/profile; do
  grep -qE '^[^#]*umask' "$file" && sed -i -E "s/^(\s*umask\s*)[0-7]+/\1$var_accounts_user_umask/g" "$file"
done

if ! grep -qrE '^[^#]*umask' $NEWROOT/etc/profile*; then
  echo "umask $var_accounts_user_umask" >> $NEWROOT/etc/profile
fi

All Interactive User Home Directories Must Be Group-Owned By The Primary Group   [ref]rule

Change the group owner of interactive users home directory to the group found in /etc/passwd. To change the group owner of interactive users home directory, use the following command:

$ sudo chgrp USER_GROUP /home/USER
This rule ensures every home directory related to an interactive user is group-owned by an interactive user. It also ensures that interactive users are group-owners of one and only one home directory.

Warning:  Due to OVAL limitation, this rule can report a false negative in a specific situation where two interactive users swap the group-ownership of their respective home directories.
Rationale:

If the Group Identifier (GID) of a local interactive users home directory is not the same as the primary GID of the user, this would allow unauthorized access to the users files, and users that share the same group may not be able to access files that they legitimately should.

Severity:  medium

Ensure All User Initialization Files Have Mode 0740 Or Less Permissive   [ref]rule

Set the mode of the user initialization files to 0740 or less permissisive with the following command:

$ sudo chmod u-s,g-wxs,o= /home/USER/.INIT_FILE

Rationale:

Local initialization files are used to configure the user's shell environment upon logon. Malicious modification of these files could compromise accounts upon logon.

Severity:  medium

Ensure All User Initialization Files Have Mode 0740 Or Less Permissive   [ref]rule

Set the mode of the user initialization files, including the root user, to 0740 or less permissisive with the following commands:

$ sudo chmod u-s,g-wxs,o= /root/.INIT_FILE
$ sudo chmod u-s,g-wxs,o= /home/USER/.INIT_FILE

Rationale:

Local initialization files are used to configure the user's shell environment upon logon. Malicious modification of these files could compromise accounts upon logon.

Severity:  medium

All Interactive User Home Directories Must Have mode 0750 Or Less Permissive   [ref]rule

Change the mode of interactive users home directories to 0750. To change the mode of interactive users home directory, use the following command:

$ sudo chmod 0750 /home/USER

Rationale:

Excessive permissions on local interactive user home directories may allow unauthorized access to user files by other users.

Severity:  medium

File Permissions and Masks   [ref]group

Traditional Unix security relies heavily on file and directory permissions to prevent unauthorized users from reading or modifying files to which they should not have access.

Several of the commands in this section search filesystems for files or directories with certain characteristics, and are intended to be run on every local partition on a given system. When the variable PART appears in one of the commands below, it means that the command is intended to be run repeatedly, with the name of each local partition substituted for PART in turn.

The following command prints a list of all xfs partitions on the local system, which is the default filesystem for Hummingbird installations:

$ mount -t xfs | awk '{print $3}'
For any systems that use a different local filesystem type, modify this command as appropriate.

contains 42 rules

Verify Permissions on Important Files and Directories   [ref]group

Permissions for many files on a system must be set restrictively to ensure sensitive information is properly protected. This section discusses important permission restrictions which can be verified to ensure that no harmful discrepancies have arisen.

contains 42 rules
contains 24 rules

Verify Group Who Owns Backup group File   [ref]rule

The /etc/group- should be group-owned by the root group.

Rationale:

The /etc/group- file is a backup file of /etc/group, and as such, it contains information regarding groups that are configured on the system. Protection of this file is important for system security.

Severity:  medium

Verify Group Who Owns Backup gshadow File   [ref]rule

The /etc/gshadow- should be group-owned by the root group.

Rationale:

The /etc/gshadow- file is a backup of /etc/gshadow, and as such, it contains group password hashes. Protection of this file is critical for system security.

Severity:  medium

Verify Group Who Owns Backup passwd File   [ref]rule

The /etc/passwd- should be group-owned by the root group.

Rationale:

The /etc/passwd- file is a backup file of /etc/passwd, and as such, it contains information about the users that are configured on the system. Protection of this file is critical for system security.

Severity:  medium

Verify User Who Owns Backup shadow File   [ref]rule

The /etc/shadow- should be group-owned by the root group.

Rationale:

The /etc/shadow- file is a backup file of /etc/shadow, and as such, it contains the list of local system accounts and password hashes. Protection of this file is critical for system security.

Severity:  medium

Verify Group Who Owns group File   [ref]rule

The /etc/group should be group-owned by the root group.

Rationale:

The /etc/group file contains information regarding groups that are configured on the system. Protection of this file is important for system security.

Severity:  medium

Verify Group Who Owns gshadow File   [ref]rule

The /etc/gshadow should be group-owned by the root group.

Rationale:

The /etc/gshadow file contains group password hashes. Protection of this file is critical for system security.

Severity:  medium

Verify Group Who Owns passwd File   [ref]rule

The /etc/passwd should be group-owned by the root group.

Rationale:

The /etc/passwd file contains information about the users that are configured on the system. Protection of this file is critical for system security.

Severity:  medium

Verify Group Who Owns shadow File   [ref]rule

The /etc/shadow should be group-owned by the root group.

Rationale:

The /etc/shadow file stores password hashes. Protection of this file is critical for system security.

Severity:  medium

Verify User Who Owns Backup group File   [ref]rule

The /etc/group- should be owned by the root user.

Rationale:

The /etc/group- file is a backup file of /etc/group, and as such, it contains information regarding groups that are configured on the system. Protection of this file is important for system security.

Severity:  medium

Verify User Who Owns Backup gshadow File   [ref]rule

The /etc/gshadow- should be owned by the root user.

Rationale:

The /etc/gshadow- file is a backup of /etc/gshadow, and as such, it contains group password hashes. Protection of this file is critical for system security.

Severity:  medium

Verify User Who Owns Backup passwd File   [ref]rule

The /etc/passwd- should be owned by the root user.

Rationale:

The /etc/passwd- file is a backup file of /etc/passwd, and as such, it contains information about the users that are configured on the system. Protection of this file is critical for system security.

Severity:  medium

Verify Group Who Owns Backup shadow File   [ref]rule

The /etc/shadow- should be owned by the root user.

Rationale:

The /etc/shadow- file is a backup file of /etc/shadow, and as such, it contains the list of local system accounts and password hashes. Protection of this file is critical for system security.

Severity:  medium

Verify User Who Owns group File   [ref]rule

The /etc/group should be owned by the root user.

Rationale:

The /etc/group file contains information regarding groups that are configured on the system. Protection of this file is important for system security.

Severity:  medium

Verify User Who Owns gshadow File   [ref]rule

The /etc/gshadow should be owned by the root user.

Rationale:

The /etc/gshadow file contains group password hashes. Protection of this file is critical for system security.

Severity:  medium

Verify User Who Owns passwd File   [ref]rule

The /etc/passwd should be owned by the root user.

Rationale:

The /etc/passwd file contains information about the users that are configured on the system. Protection of this file is critical for system security.

Severity:  medium

Verify User Who Owns shadow File   [ref]rule

The /etc/shadow should be owned by the root user.

Rationale:

The /etc/shadow file contains the list of local system accounts and stores password hashes. Protection of this file is critical for system security. Failure to give ownership of this file to root provides the designated owner with access to sensitive information which could weaken the system security posture.

Severity:  medium

Verify Permissions on Backup group File   [ref]rule

The /etc/group- shall have the 0644 permission mode.

Rationale:

The /etc/group- file is a backup file of /etc/group, and as such, it contains information regarding groups that are configured on the system. Protection of this file is important for system security.

Severity:  medium

Verify Permissions on Backup gshadow File   [ref]rule

The /etc/gshadow- shall have the 0000 permission mode.

Rationale:

The /etc/gshadow- file is a backup of /etc/gshadow, and as such, it contains group password hashes. Protection of this file is critical for system security.

Severity:  medium

Verify Permissions on Backup passwd File   [ref]rule

The /etc/passwd- shall have the 0644 permission mode.

Rationale:

The /etc/passwd- file is a backup file of /etc/passwd, and as such, it contains information about the users that are configured on the system. Protection of this file is critical for system security.

Severity:  medium

Verify Permissions on Backup shadow File   [ref]rule

The /etc/shadow- shall have the 0000 permission mode.

Rationale:

The /etc/shadow- file is a backup file of /etc/shadow, and as such, it contains the list of local system accounts and password hashes. Protection of this file is critical for system security.

Severity:  medium

Verify Permissions on group File   [ref]rule

The /etc/group shall have the 0644 permission mode.

Rationale:

The /etc/group file contains information regarding groups that are configured on the system. Protection of this file is important for system security.

Severity:  medium

Verify Permissions on gshadow File   [ref]rule

The /etc/gshadow shall have the 0000 permission mode.

Rationale:

The /etc/gshadow file contains group password hashes. Protection of this file is critical for system security.

Severity:  medium

Verify Permissions on passwd File   [ref]rule

The /etc/passwd shall have the 0644 permission mode.

Rationale:

If the /etc/passwd file is writable by a group-owner or the world the risk of its compromise is increased. The file contains the list of accounts on the system and associated information, and protection of this file is critical for system security.

Severity:  medium

Verify Permissions on shadow File   [ref]rule

The /etc/shadow shall have the 0000 permission mode.

Rationale:

The /etc/shadow file contains the list of local system accounts and stores password hashes. Protection of this file is critical for system security. Failure to give ownership of this file to root provides the designated owner with access to sensitive information which could weaken the system security posture.

Severity:  medium

Verify Permissions on Files within /var/log Directory   [ref]group

The /var/log directory contains files with logs of error messages in the system and should only be accessed by authorized personnel.

contains 6 rules

Verify Group Who Owns /var/log Directory   [ref]rule

The /var/log should be group-owned by the root group.

Rationale:

The /var/log directory contains files with logs of error messages in the system and should only be accessed by authorized personnel.

Severity:  medium

Verify Group Who Owns /var/log/messages File   [ref]rule

The /var/log/messages should be group-owned by the root group.

Rationale:

The /var/log/messages file contains logs of error messages in the system and should only be accessed by authorized personnel.

Severity:  medium

Verify User Who Owns /var/log Directory   [ref]rule

The /var/log should be owned by the root user.

Rationale:

The /var/log directory contains files with logs of error messages in the system and should only be accessed by authorized personnel.

Severity:  medium

Verify User Who Owns /var/log/messages File   [ref]rule

The /var/log/messages should be owned by the root user.

Rationale:

The /var/log/messages file contains logs of error messages in the system and should only be accessed by authorized personnel.

Severity:  medium

Verify Permissions on /var/log Directory   [ref]rule

The /var/log shall have the 0755 permission mode.

Rationale:

The /var/log directory contains files with logs of error messages in the system and should only be accessed by authorized personnel.

Severity:  medium

Verify Permissions on /var/log/messages File   [ref]rule

The /var/log/messages shall have the 0600 permission mode.

Rationale:

The /var/log/messages file contains logs of error messages in the system and should only be accessed by authorized personnel.

Severity:  medium

Verify File Permissions Within Some Important Directories   [ref]group

Some directories contain files whose confidentiality or integrity is notably important and may also be susceptible to misconfiguration over time, particularly if unpackaged software is installed. As such, an argument exists to verify that files' permissions within these directories remain configured correctly and restrictively.

contains 9 rules

Verify that Shared Library Directories Have Root Group Ownership   [ref]rule

System-wide shared library files, which are linked to executables during process load time or run time, are stored in the following directories by default:

/lib
/lib64
/usr/lib
/usr/lib64
All files in these directories should be group-owned by the root group.

Rationale:

Files from shared library directories are loaded into the address space of processes (including privileged ones) or of the kernel itself at runtime. Proper ownership of library directories is necessary to protect the integrity of the system.

Severity:  medium

Verify that Shared Library Directories Have Root Ownership   [ref]rule

System-wide shared library files, which are linked to executables during process load time or run time, are stored in the following directories by default:

/lib
/lib64
/usr/lib
/usr/lib64
All files in these directories should be owned by the root user.

Rationale:

Files from shared library directories are loaded into the address space of processes (including privileged ones) or of the kernel itself at runtime. Proper ownership of library directories is necessary to protect the integrity of the system.

Severity:  medium

Verify that Shared Library Directories Have Restrictive Permissions   [ref]rule

System-wide shared library directories, which contain are linked to executables during process load time or run time, are stored in the following directories by default:

/lib
/lib64
/usr/lib
/usr/lib64
All sub-directories in these directories should not be group-writable or world-writable.

Rationale:

If the operating system were to allow any user to make changes to software libraries, then those changes might be implemented without undergoing the appropriate testing and approvals that are part of a robust change management process. This requirement applies to operating systems with software libraries that are accessible and configurable, as in the case of interpreted languages. Software libraries also include privileged programs which execute with escalated privileges. Only qualified and authorized individuals must be allowed to obtain access to information system components for purposes of initiating changes, including upgrades and modifications.

Severity:  medium

Verify that system commands files are group owned by root or a system account   [ref]rule

System commands files are stored in the following directories by default:

/bin
/sbin
/usr/bin
/usr/sbin
/usr/local/bin
/usr/local/sbin
All files in these directories should be owned by the root group, or a system account. If the directory, or any file in these directories, is found to be owned by a group other than root or a a system account correct its ownership with the following command:
$ sudo chgrp root FILE

Rationale:

If the operating system allows any user to make changes to software libraries, then those changes might be implemented without undergoing the appropriate testing and approvals that are part of a robust change management process. This requirement applies to operating systems with software libraries that are accessible and configurable, as in the case of interpreted languages. Software libraries also include privileged programs which execute with escalated privileges. Only qualified and authorized individuals must be allowed to obtain access to information system components for purposes of initiating changes, including upgrades and modifications.

Severity:  medium

Verify that System Executables Have Root Ownership   [ref]rule

System executables are stored in the following directories by default:

/bin
/sbin
/usr/bin
/usr/libexec
/usr/local/bin
/usr/local/sbin
/usr/sbin
All files in these directories should be owned by the root user. If any file FILE in these directories is found to be owned by a user other than root, correct its ownership with the following command:
$ sudo chown root FILE

Rationale:

System binaries are executed by privileged users as well as system services, and restrictive permissions are necessary to ensure that their execution of these programs cannot be co-opted.

Severity:  medium

Verify that Shared Library Files Have Root Ownership   [ref]rule

System-wide shared library files, which are linked to executables during process load time or run time, are stored in the following directories by default:

/lib
/lib64
/usr/lib
/usr/lib64
All files in these directories should be owned by the root user.

Rationale:

Files from shared library directories are loaded into the address space of processes (including privileged ones) or of the kernel itself at runtime. Proper ownership is necessary to protect the integrity of the system.

Severity:  medium

Verify that System Executables Have Restrictive Permissions   [ref]rule

System executables are stored in the following directories by default:

/bin
/sbin
/usr/bin
/usr/libexec
/usr/local/bin
/usr/local/sbin
/usr/sbin
All files in these directories should not be group-writable or world-writable. If any file FILE in these directories is found to be group-writable or world-writable, correct its permission with the following command:
$ sudo chmod go-w FILE

Rationale:

System binaries are executed by privileged users, as well as system services, and restrictive permissions are necessary to ensure execution of these programs cannot be co-opted.

Severity:  medium

Verify that Shared Library Files Have Restrictive Permissions   [ref]rule

System-wide shared library files, which are linked to executables during process load time or run time, are stored in the following directories by default:

/lib
/lib64
/usr/lib
/usr/lib64
All files in these directories should not be group-writable or world-writable.

Rationale:

Files from shared library directories are loaded into the address space of processes (including privileged ones) or of the kernel itself at runtime. Restrictive permissions are necessary to protect the integrity of the system.

Severity:  medium

Verify the system-wide library files in directories "/lib", "/lib64", "/usr/lib/" and "/usr/lib64" are group-owned by root.   [ref]rule

System-wide library files are stored in the following directories by default:

/lib
/lib64
/usr/lib
/usr/lib64
All system-wide shared library files should be protected from unauthorised access. If any of these files is not group-owned by root, correct its group-owner with the following command:
$ sudo chgrp root FILE

Rationale:

If the operating system were to allow any user to make changes to software libraries, then those changes might be implemented without undergoing the appropriate testing and approvals that are part of a robust change management process. This requirement applies to operating systems with software libraries that are accessible and configurable, as in the case of interpreted languages. Software libraries also include privileged programs which execute with escalated privileges. Only qualified and authorized individuals must be allowed to obtain access to information system components for purposes of initiating changes, including upgrades and modifications.

Severity:  medium

Ensure All World-Writable Directories Are Owned by root User   [ref]rule

All directories in local partitions which are world-writable should be owned by root. If any world-writable directories are not owned by root, this should be investigated. Following this, the files should be deleted or assigned to root user.

Rationale:

Allowing a user account to own a world-writable directory is undesirable because it allows the owner of that directory to remove or replace any files that may be placed in the directory by other users.

Severity:  medium

Verify that All World-Writable Directories Have Sticky Bits Set   [ref]rule

When the so-called 'sticky bit' is set on a directory, only the owner of a given file may remove that file from the directory. Without the sticky bit, any user with write access to a directory may remove any file in the directory. Setting the sticky bit prevents users from removing each other's files. In cases where there is no reason for a directory to be world-writable, a better solution is to remove that permission rather than to set the sticky bit. However, if a directory is used by a particular application, consult that application's documentation instead of blindly changing modes.
To set the sticky bit on a world-writable directory DIR, run the following command:

$ sudo chmod +t DIR

Warning:  This rule can take a long time to perform the check and might consume a considerable amount of resources depending on the number of directories present on the system. It is not a problem in most cases, but especially systems with a large number of directories can be affected. See https://access.redhat.com/articles/6999111.
Warning:  Please note that there might be cases where the rule remediation cannot fix directory permissions. This can happen for example when running on a system with some immutable parts. These immutable parts cannot be remediated because they are read-only. Example of such directories can be OStree deployments located at /sysroot/ostree/deploy. In such case, it is needed to make modifications to the underlying ostree snapshot and this is out of scope of regular rule remediation.
Rationale:

Failing to set the sticky bit on public directories allows unauthorized users to delete files in the directory structure.

The only authorized public directories are those temporary directories supplied with the system, or those designed to be temporary file repositories. The setting is normally reserved for directories used by the system, by users for temporary file storage (such as /tmp), and for directories requiring global read/write access.

Severity:  medium

Ensure All Files Are Owned by a Group   [ref]rule

If any file is not group-owned by a valid defined group, the cause of the lack of group-ownership must be investigated. Following this, those files should be deleted or assigned to an appropriate group. The groups need to be defined in /etc/group or in /usr/lib/group if nss-altfiles are configured to be used in /etc/nsswitch.conf. Locate the mount points related to local devices by the following command:

$ findmnt -n -l -k -it $(awk '/nodev/ { print $2 }' /proc/filesystems | paste -sd,)
For all mount points listed by the previous command, it is necessary to search for files which do not belong to a valid group using the following command:
$ sudo find MOUNTPOINT -xdev -nogroup 2>/dev/null

Warning:  This rule only considers local groups as valid groups. If you have your groups defined outside /etc/group or /usr/lib/group, the rule won't consider those.
Warning:  This rule can take a long time to perform the check and might consume a considerable amount of resources depending on the number of files present on the system. It is not a problem in most cases, but especially systems with a large number of files can be affected. See https://access.redhat.com/articles/6999111.
Rationale:

Unowned files do not directly imply a security problem, but they are generally a sign that something is amiss. They may be caused by an intruder, by incorrect software installation or draft software removal, or by failure to remove all files belonging to a deleted account, or other similar cases. The files should be repaired so they will not cause problems when accounts are created in the future, and the cause should be discovered and addressed.

Severity:  medium

Services   [ref]group

The best protection against vulnerable software is running less software. This section describes how to review the software which Hummingbird installs on a system and disable software which is not needed. It then enumerates the software packages installed on a default Hummingbird system and provides guidance about which ones can be safely disabled.

Hummingbird provides a convenient minimal install option that essentially installs the bare necessities for a functional system. When building Hummingbird systems, it is highly recommended to select the minimal packages and then build up the system from there.

contains 8 rules

DNS Server   [ref]group

Most organizations have an operational need to run at least one nameserver. However, there are many common attacks involving DNS server software, and this server software should be disabled on any system on which it is not needed.

contains 1 rule

Uninstall unbound Package   [ref]rule

The named service is provided by the unbound package. The unbound package should not be present in the container or container image. Remove the unbound package from Containerfile and rebuild the container image.

Rationale:

If there is no need to make DNS server software available, removing it provides a safeguard against its activation.

Severity:  low

FTP Server   [ref]group

FTP is a common method for allowing remote access to files. Like telnet, the FTP protocol is unencrypted, which means that passwords and other data transmitted during the session can be captured and that the session is vulnerable to hijacking. Therefore, running the FTP server software is not recommended.

However, there are some FTP server configurations which may be appropriate for some environments, particularly those which allow only read-only anonymous access as a means of downloading data available to the public.

contains 1 rule

Disable vsftpd if Possible   [ref]group

To minimize attack surface, disable vsftpd if at all possible.

contains 1 rule

Uninstall vsftpd Package   [ref]rule

The vsftpd package should not be present in the container or container image. Remove the vsftpd package from Containerfile and rebuild the container image.

Rationale:

Removing the vsftpd package decreases the risk of its accidental activation.

Severity:  high

NFS and RPC   [ref]group

The Network File System is a popular distributed filesystem for the Unix environment, and is very widely deployed. This section discusses the circumstances under which it is possible to disable NFS and its dependencies, and then details steps which should be taken to secure NFS's configuration. This section is relevant to systems operating as NFS clients, as well as to those operating as NFS servers.

contains 1 rule

Uninstall nfs-utils Package   [ref]rule

The nfs-utils package should not be present in the container or container image. Remove the nfs-utils package from Containerfile and rebuild the container image.

Rationale:

nfs-utils provides a daemon for the kernel NFS server and related tools. This package also contains the showmount program. showmount queries the mount daemon on a remote host for information about the Network File System (NFS) server on the remote host. For example, showmount can display the clients which are mounted on that host.

Severity:  low

Obsolete Services   [ref]group

This section discusses a number of network-visible services which have historically caused problems for system security, and for which disabling or severely limiting the service has been the best available guidance for some time. As a result of this, many of these services are not installed as part of Hummingbird by default.

Organizations which are running these services should switch to more secure equivalents as soon as possible. If it remains absolutely necessary to run one of these services for legacy reasons, care should be taken to restrict the service as much as possible, for instance by configuring host firewall software such as iptables to restrict access to the vulnerable service to only those remote hosts which have a known need to use it.

contains 5 rules

Rlogin, Rsh, and Rexec   [ref]group

The Berkeley r-commands are legacy services which allow cleartext remote access and have an insecure trust model.

contains 2 rules

Remove Host-Based Authentication Files   [ref]rule

The shosts.equiv file lists remote hosts and users that are trusted by the local system. To remove these files, run the following command to delete them from any location:

$ sudo rm /[path]/[to]/[file]/shosts.equiv

Rationale:

The shosts.equiv files are used to configure host-based authentication for the system via SSH. Host-based authentication is not sufficient for preventing unauthorized access to the system, as it does not require interactive identification and authentication of a connection request, or for the use of two-factor authentication.

Severity:  high

Remediation script:   (show)

find "$NEWROOT" -type f -name "shosts.equiv" -exec rm -f {} \;

Remove User Host-Based Authentication Files   [ref]rule

The ~/.shosts (in each user's home directory) files list remote hosts and users that are trusted by the local system. To remove these files, run the following command to delete them from any location:

$ sudo find / -name '.shosts' -type f -delete

Rationale:

The .shosts files are used to configure host-based authentication for individual users or the system via SSH. Host-based authentication is not sufficient for preventing unauthorized access to the system, as it does not require interactive identification and authentication of a connection request, or for the use of two-factor authentication.

Severity:  high

Telnet   [ref]group

The telnet protocol does not provide confidentiality or integrity for information transmitted on the network. This includes authentication information such as passwords. Organizations which use telnet should be actively working to migrate to a more secure protocol.

contains 1 rule

Uninstall telnet-server Package   [ref]rule

The telnet-server package should not be present in the container or container image. Remove the telnet-server package from Containerfile and rebuild the container image.

Rationale:

It is detrimental for operating systems to provide, or install by default, functionality exceeding requirements or mission objectives. These unnecessary capabilities are often overlooked and therefore may remain insecure. They increase the risk to the platform by providing additional attack vectors.
The telnet service provides an unencrypted remote access service which does not provide for the confidentiality and integrity of user passwords or the remote session. If a privileged user were to login using this service, the privileged user password could be compromised.
Removing the telnet-server package decreases the risk of the telnet service's accidental (or intentional) activation.

Severity:  high

TFTP Server   [ref]group

TFTP is a lightweight version of the FTP protocol which has traditionally been used to configure networking equipment. However, TFTP provides little security, and modern versions of networking operating systems frequently support configuration via SSH or other more secure protocols. A TFTP server should be run only if no more secure method of supporting existing equipment can be found.

contains 2 rules

Uninstall tftp-server Package   [ref]rule

The tftp-server package should not be present in the container or container image. Remove the tftp-server package from Containerfile and rebuild the container image.

Rationale:

Removing the tftp-server package decreases the risk of the accidental (or intentional) activation of tftp services.

If TFTP is required for operational support (such as transmission of router configurations), its use must be documented with the Information Systems Security Manager (ISSM), restricted to only authorized personnel, and have access control rules established.

Severity:  high

Remove tftp Daemon   [ref]rule

Trivial File Transfer Protocol (TFTP) is a simple file transfer protocol, typically used to automatically transfer configuration or boot files between systems. TFTP does not support authentication and can be easily hacked. The package tftp is a client program that allows for connections to a tftp server.

Rationale:

It is recommended that TFTP be removed, unless there is a specific need for TFTP (such as a boot server). In that case, use extreme caution when configuring the services.

Severity:  low

Red Hat and Red Hat Enterprise Linux are either registered trademarks or trademarks of Red Hat, Inc. in the United States and other countries. All other names are registered trademarks or trademarks of their respective companies.