Guide to the Secure Configuration of Red Hat Enterprise Linux 7

with profile Standard System Security Profile

Profile TitleStandard System Security Profile
Profile IDstandard

Revision History

Current version: 0.9

  • draft (as of 2015-06-25)

Platforms

  • cpe:/o:redhat:enterprise_linux:7
  • cpe:/o:redhat:enterprise_linux:7::client

Table of Contents

  1. System Base Security Settings

Checklist

contains 14 rules

System Base Security Settingsgroup

contains 14 rules

Ensure Software Patches Installedrule

If the system is joined to the Red Hat Network, a Red Hat Satellite Server, or a yum server, run the following command to install updates:

$ sudo yum update
If the system is not configured to use one of these sources, updates (in the form of RPM packages) can be manually downloaded from the Red Hat Network and installed using rpm.

Rationale:

Installing software updates is a fundamental mitigation against the exploitation of publicly-known vulnerabilities.

identifiers:  CCE-26853-2

references:  SI-2, MA-1(b), http://iase.disa.mil/stigs/cci/Pages/index.aspx, Test attestation on 20120928 by MM

Prevent Log In to Accounts With Empty Passwordrule

If an account is configured for password authentication but does not have an assigned password, it may be possible to log into the account without authentication. Remove any instances of the nullok option in /etc/pam.d/system-auth to prevent logins with empty passwords.

Rationale:

If an account has an empty password, anyone could log in and run commands with the privileges of that account. Accounts with empty passwords should never be used in operational environments.

identifiers:  CCE-27010-8

references:  IA-5(b), IA-5(c), IA-5(1)(a), Test attestation on 20121024 by DS

Remediation script:
sed -i 's/\<nullok\>//g' /etc/pam.d/system-auth

Verify All Account Password Hashes are Shadowedrule

If any password hashes are stored in /etc/passwd (in the second field, instead of an x), the cause of this misconfiguration should be investigated. The account should have its password reset and the hash should be properly stored, or the account should be deleted entirely.

Rationale:

The hashes for all user account passwords should be stored in the file /etc/shadow and never in /etc/passwd, which is readable by all users.

identifiers:  CCE-27144-5

references:  IA-5(h), http://iase.disa.mil/stigs/cci/Pages/index.aspx, Test attestation on 20121024 by DS

Ensure All SGID Executables Are Authorizedrule

The SGID (set group id) bit should be set only on files that were installed via authorized means. A straightforward means of identifying unauthorized SGID files is determine if any were not installed as part of an RPM package, which is cryptographically verified. Investigate the origin of any unpackaged SGID files.

Rationale:

Executable files with the SGID permission run with the privileges of the owner of the file. SGID files of uncertain provenance could allow for unprivileged users to elevate privileges. The presence of these files should be strictly controlled on the system.

identifiers:  CCE-RHEL7-CCE-TBD

references:  http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf

Ensure All SUID Executables Are Authorizedrule

The SUID (set user id) bit should be set only on files that were installed via authorized means. A straightforward means of identifying unauthorized SGID files is determine if any were not installed as part of an RPM package, which is cryptographically verified. Investigate the origin of any unpackaged SUID files.

Rationale:

Executable files with the SUID permission run with the privileges of the owner of the file. SUID files of uncertain provenance could allow for unprivileged users to elevate privileges. The presence of these files should be strictly controlled on the system.

identifiers:  CCE-RHEL7-CCE-TBD

references:  AC-6(1)

Ensure No World-Writable Files Existrule

It is generally a good idea to remove global (other) write access to a file when it is discovered. However, check with documentation for specific applications before making changes. Also, monitor for recurring world-writable files, as these may be symptoms of a misconfigured application or user account.

Rationale:

Data in world-writable files can be modified by any user on the system. In almost all circumstances, files can be configured using a combination of user and group permissions to support whatever legitimate access is needed without the risk caused by world-writable files.

identifiers:  CCE-RHEL7-CCE-TBD

references:  AC-6

Ensure All World-Writable Directories Are Owned by a System Accountrule

All directories in local partitions which are world-writable should be owned by root or another system account. If any world-writable directories are not owned by a system account, this should be investigated. Following this, the files should be deleted or assigned to an appropriate group.

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.

identifiers:  CCE-RHEL7-CCE-TBD

references:  AC-6, Test attestation on 20120929 by swells

Ensure that Root's Path Does Not Include Relative Paths or Null Directoriesrule

Ensure that none of the directories in root's path is equal to a single . character, or that it contains any instances that lead to relative path traversal, such as .. or beginning a path without the slash (/) character. Also ensure that there are no "empty" elements in the path, such as in these examples:

PATH=:/bin
PATH=/bin:
PATH=/bin::/sbin
These empty elements have the same effect as a single . character.

Rationale:

Including these entries increases the risk that root could execute code from an untrusted location.

identifiers:  CCE-RHEL7-CCE-TBD

references:  http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf

Ensure that Root's Path Does Not Include World or Group-Writable Directoriesrule

For each element in root's path, run:

# ls -ld DIR
and ensure that write permissions are disabled for group and other.

Rationale:

Such entries increase the risk that root could execute code provided by unprivileged users, and potentially malicious code.

identifiers:  CCE-RHEL7-CCE-TBD

references:  http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf

Verify File Hashes with RPMrule

The RPM package management system can check the hashes of installed software packages, including many that are important to system security. Run the following command to list which files on the system have hashes that differ from what is expected by the RPM database:

$ rpm -Va | grep '^..5'
A "c" in the second column indicates that a file is a configuration file, which may appropriately be expected to change. If the file was not expected to change, investigate the cause of the change using audit logs or other means. The package can then be reinstalled to restore the file. Run the following command to determine which package owns the file:
$ rpm -qf FILENAME
The package can be reinstalled from a yum repository using the command:
$ sudo yum reinstall PACKAGENAME
Alternatively, the package can be reinstalled from trusted media using the command:
$ sudo rpm -Uvh PACKAGENAME

Rationale:

The hashes of important files like system executables should match the information given by the RPM database. Executables with erroneous hashes could be a sign of nefarious activity on the system.

identifiers:  CCE-RHEL7-CCE-TBD

references:  CM-6(d), CM-6(3), SI-7, 1496

Ensure SELinux State is Enforcingrule

The SELinux state should be set to enforcing at system boot time. In the file /etc/selinux/config, add or correct the following line to configure the system to boot into enforcing mode:

SELINUX=enforcing

Rationale:

Setting the SELinux state to enforcing ensures SELinux is able to confine potentially compromised processes to the security policy, which is designed to prevent them from causing damage to the system or further elevating their privileges.

identifiers:  CCE-26800-3

references:  AC-3, AC-3(3), AC-4, AC-6, AU-9, http://iase.disa.mil/stigs/cci/Pages/index.aspx, Test attestation on 20121024 by DS

Remediation script:
var_selinux_state="enforcing"
grep -q ^SELINUX= /etc/selinux/config && \
  sed -i "s/SELINUX=.*/SELINUX=$var_selinux_state/g" /etc/selinux/config
if ! [ $? -eq 0 ]; then
    echo "SELINUX=$var_selinux_state" >> /etc/selinux/config
fi

Enable auditd Servicerule

The auditd service is an essential userspace component of the Linux Auditing System, as it is responsible for writing audit records to disk. The auditd service can be enabled with the following command:

$ sudo systemctl enable auditd

Rationale:

Ensuring the auditd service is active ensures audit records generated by the kernel can be written to disk, or that appropriate actions will be taken if other obstacles exist.

identifiers:  CCE-RHEL7-CCE-TBD

references:  AC-17(1), AU-1(b), AU-10, AU-12(a), AU-12(c), IR-5, 347, 157, 172, 880, 1353, 1462, 1487, 1115, 1454, 067, 158, 831, 1190, 1312, 1263, 130, 120, 1589, Test attestation on 20121024 by DS

Remediation script:
#
# Enable auditd.service for all systemd targets
#
systemctl enable auditd.service

#
# Start auditd.service if not currently running
#
systemctl start auditd.service

Enable Auditing for Processes Which Start Prior to the Audit Daemonrule

To ensure all processes can be audited, even those which start prior to the audit daemon, add the argument audit=1 to the kernel line in /etc/grub.conf, in the manner below:

kernel /vmlinuz-version ro vga=ext root=/dev/VolGroup00/LogVol00 rhgb quiet audit=1

Rationale:

Each process on the system carries an "auditable" flag which indicates whether its activities can be audited. Although auditd takes care of enabling this for all processes which launch after it does, adding the kernel argument ensures it is set for every process during boot.

identifiers:  CCE-RHEL7-CCE-TBD

references:  AC-17(1), AU-14(1), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-10, IR-5, 1464, 130

Ensure auditd Collects Information on the Use of Privileged Commandsrule

At a minimum the audit system should collect the execution of privileged commands for all users and root. To find the relevant setuid / setgid programs, run the following command for each local partition PART:

$ sudo find PART -xdev -type f -perm -4000 -o -type f -perm -2000 2>/dev/null
If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add a line of the following form to a file with suffix .rules in the directory /etc/audit/rules.d for each setuid / setgid program on the system, replacing the SETUID_PROG_PATH part with the full path of that setuid / setgid program in the list:
-a always,exit -F path=SETUID_PROG_PATH -F perm=x -F auid>=1000 -F auid!=4294967295 -k privileged
If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules for each setuid / setgid program on the system, replacing the SETUID_PROG_PATH part with the full path of that setuid / setgid program in the list:
-a always,exit -F path=SETUID_PROG_PATH -F perm=x -F auid>=1000 -F auid!=4294967295 -k privileged

Rationale:

Privileged programs are subject to escalation-of-privilege attacks, which attempt to subvert their normal role of providing some necessary but limited capability. As such, motivation exists to monitor these programs for unusual activity.

identifiers:  CCE-RHEL7-CCE-TBD

references:  AC-17(7), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-2(4), AU-12(a), AU-12(c), IR-5, 40, Test attestation on 20121024 by DS

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.