Select any two versions of this STIG to compare the individual requirements
Select any old version/release of this STIG to view the previous requirements
Verify the audit service is configured to produce audit records. Check that the audit service is installed with the following command: $ sudo yum list installed audit If the "auditd" package is not installed, this is a finding.
Configure the audit service to produce audit records containing the information needed to establish when (date and time) an event occurred. Install the audit service (if the audit service is not already installed) with the following command: $ sudo yum install audit
Verify the audit service is configured to produce audit records with the following command: $ sudo systemctl status auditd.service auditd.service - Security Auditing Service Loaded:loaded (/usr/lib/systemd/system/auditd.service; enabled; vendor preset: enabled) Active: active (running) since Tues 2020-12-11 12:56:56 EST; 4 weeks 0 days ago If the audit service is not "active" and "running", this is a finding.
Configure the audit service to produce audit records containing the information needed to establish when (date and time) an event occurred with the following commands: $ sudo systemctl enable auditd.service $ sudo systemctl start auditd.service
Verify the version of the operating system is vendor supported. Check the version of the operating system with the following command: $ udo cat /etc/oracle-release Oracle Linux Server release 8.2 Current End of Premier Support for Oracle Linux 8 is July 2029, while Extended Support might consider an extended term. If the release is not supported by the vendor, this is a finding.
Upgrade to a supported version of the operating system.
Verify the operating system security patches and updates are installed and up to date. Updates are required to be applied with a frequency determined by the site or Program Management Office (PMO). Obtain the list of available package security updates from Oracle. The URL for updates is https://linux.oracle.com/errata/. It is important to note that updates provided by Oracle may not be present on the system if the underlying packages are not installed. Check that the available package security updates have been installed on the system with the following command: $ sudo yum history list | more Loaded plugins: langpacks, product-id, subscription-manager ID | Command line | Date and time | Action(s) | Altered ------------------------------------------------------------------------------- 70 | install aide | 2020-03-05 10:58 | Install | 1 69 | update -y | 2020-03-04 14:34 | Update | 18 EE 68 | install vlc | 2020-02-21 17:12 | Install | 21 67 | update -y | 2020-02-21 17:04 | Update | 7 EE If package updates have not been performed on the system within the timeframe that the site/program documentation requires, this is a finding. Typical update frequency may be overridden by Information Assurance Vulnerability Alert (IAVA) notifications from CYBERCOM. If the operating system is not in compliance with the Information Assurance Vulnerability Management (IAVM) process, this is a finding.
Install the operating system patches or updated packages available from Oracle within 30 days or sooner as local policy dictates.
Verify the operating system implements DOD-approved encryption to protect the confidentiality of remote access sessions. Check to see if FIPS mode is enabled with the following command: $ fips-mode-setup --check FIPS mode is enabled If FIPS mode is "enabled", check to see if the kernel boot parameter is configured for FIPS mode with the following command: $ sudo grub2-editenv list | grep fips kernelopts=root=/dev/mapper/ol-root ro resume=/dev/mapper/ol-swap rd.lvm.lv=ol/root rd.lvm.lv=ol/swap rhgb quiet fips=1 boot=UUID=25856928-386b-4205-9a0e-a2953ae2712d audit=1 audit_backlog_limit=8192 pti=on random.trust_cpu=on slub_debug=P page_poison=1 If the kernel boot parameter is configured to use FIPS mode, check to see if the system is in FIPS mode with the following command: $ sudo cat /proc/sys/crypto/fips_enabled 1 If FIPS mode is not "enabled", the kernel boot parameter is not configured for FIPS mode, or the system does not have a value of "1" for "fips_enabled" in "/proc/sys/crypto", this is a finding.
Configure the operating system to implement DOD-approved encryption by following the steps below: To enable strict FIPS compliance, the fips=1 kernel option must be added to the kernel boot parameters during system installation so key generation is done with FIPS-approved algorithms and continuous monitoring tests in place. Enable FIPS mode after installation (not strict FIPS-compliant) with the following command: $ sudo fips-mode-setup --enable Reboot the system for the changes to take effect.
Verify OL 8 prevents unauthorized disclosure or modification of all information requiring at-rest protection by using disk encryption. If there is a documented and approved reason for not having data-at-rest encryption at the operating system level, such as encryption provided by a hypervisor or a disk storage array in a virtualized environment, this requirement is not applicable. Verify all system partitions are encrypted with the following command: $ sudo blkid /dev/mapper/ol-root: UUID="67b7d7fe-de60-6fd0-befb-e6748cf97743" TYPE="crypto_LUKS" Every persistent disk partition present must be of type "crypto_LUKS". If any partitions other than the boot partition or pseudo file systems (such as "/proc" or "/sys") are not listed, ask the administrator to indicate how the partitions are encrypted. If there is no evidence that these partitions are encrypted, this is a finding.
Configure OL 8 to prevent unauthorized modification of all information at rest by using disk encryption. Encrypting a partition in an already-installed system is more difficult because existing partitions will need to be resized and changed. To encrypt an entire partition, dedicate a partition for encryption in the partition layout.
Verify that any publicly accessible connection to the operating system displays the Standard Mandatory DOD Notice and Consent Banner before granting access to the system. Check for the location of the banner file being used with the following command: $ sudo /usr/sbin/sshd -dd 2>&1 | awk '/filename/ {print $4}' | tr -d '\r' | tr '\n' ' ' | xargs sudo grep -iH '^\s*banner' banner /etc/issue This command will return the banner keyword and the name of the file that contains the SSH banner (in this case "/etc/issue"). If the line is commented out, this is a finding. If conflicting results are returned, this is a finding. View the file specified by the banner keyword to check that it matches the text of the Standard Mandatory DOD Notice and Consent Banner: "You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only. By using this IS (which includes any device attached to this IS), you consent to the following conditions: -The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations. -At any time, the USG may inspect and seize data stored on this IS. -Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose. -This IS includes security measures (e.g., authentication and access controls) to protect USG interests--not for your personal benefit or privacy. -Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details." If the system does not display a graphical logon banner or the banner does not match the Standard Mandatory DOD Notice and Consent Banner, this is a finding. If the text in the file does not match the Standard Mandatory DOD Notice and Consent Banner, this is a finding.
Configure OL 8 to display the Standard Mandatory DOD Notice and Consent Banner before granting access to the system via the SSH. Edit the "/etc/ssh/sshd_config" file to uncomment the banner keyword and configure it to point to a file that will contain the logon banner (this file may be named differently or be in a different location if using a version of SSH that is provided by a third-party vendor). An example configuration line is: banner /etc/issue Either create the file containing the banner or replace the text in the file with the Standard Mandatory DOD Notice and Consent Banner. The DOD-required text is: "You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only. By using this IS (which includes any device attached to this IS), you consent to the following conditions: -The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations. -At any time, the USG may inspect and seize data stored on this IS. -Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose. -This IS includes security measures (e.g., authentication and access controls) to protect USG interests--not for your personal benefit or privacy. -Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details." The SSH service must be restarted for changes to take effect.
Note: This requirement assumes the use of the OL 8 default graphical user interface, Gnome Shell. If the system does not have any graphical user interface installed, this requirement is Not Applicable. Verify OL 8 displays a banner before granting access to the operating system via a graphical user logon. Determine if the operating system displays a banner at the logon screen with the following command: $ sudo grep banner-message-enable /etc/dconf/db/local.d/* banner-message-enable=true If "banner-message-enable" is set to "false" or is missing, this is a finding.
Configure the operating system to display a banner before granting access to the system. Note: If the system does not have a graphical user interface installed, this requirement is Not Applicable. Create a database to contain the system-wide graphical user logon settings (if it does not already exist) with the following command: $ sudo touch /etc/dconf/db/local.d/01-banner-message Add the following lines to the [org/gnome/login-screen] section of the "/etc/dconf/db/local.d/01-banner-message": [org/gnome/login-screen] banner-message-enable=true Run the following command to update the database: $ sudo dconf update
Note: This requirement assumes the use of the OL 8 default graphical user interface, Gnome Shell. If the system does not have any graphical user interface installed, this requirement is Not Applicable. Verify OL 8 displays the Standard Mandatory DoD Notice and Consent Banner before granting access to the operating system via a graphical user logon. Check that the operating system displays the exact Standard Mandatory DoD Notice and Consent Banner text with the command: $ sudo grep banner-message-text /etc/dconf/db/local.d/* banner-message-text= 'You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only.\nBy using this IS (which includes any device attached to this IS), you consent to the following conditions:\n-The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations.\n-At any time, the USG may inspect and seize data stored on this IS.\n-Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose.\n-This IS includes security measures (e.g., authentication and access controls) to protect USG interests--not for your personal benefit or privacy.\n-Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details. ' Note: The "\n" characters are for formatting only. They will not be displayed on the graphical interface. If the banner does not match the Standard Mandatory DoD Notice and Consent Banner exactly, this is a finding.
Configure OL 8 to display the Standard Mandatory DoD Notice and Consent Banner before granting access to the system. Note: If the system does not have a graphical user interface installed, this requirement is Not Applicable. Add the following lines to the [org/gnome/login-screen] section of the "/etc/dconf/db/local.d/01-banner-message": banner-message-text='You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only.\nBy using this IS (which includes any device attached to this IS), you consent to the following conditions:\n-The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations.\n-At any time, the USG may inspect and seize data stored on this IS.\n-Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose.\n-This IS includes security measures (e.g., authentication and access controls) to protect USG interests--not for your personal benefit or privacy.\n-Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details. ' Note: The "\n" characters are for formatting only. They will not be displayed on the graphical interface. Run the following command to update the database: $ sudo dconf update
Verify OL 8 displays the Standard Mandatory DoD Notice and Consent Banner before granting access to the operating system via a command line user logon. Check that OL 8 displays a banner at the command line login screen with the following command: $ sudo cat /etc/issue If the banner is set correctly, it will return the following text: "You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only. By using this IS (which includes any device attached to this IS), you consent to the following conditions: -The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations. -At any time, the USG may inspect and seize data stored on this IS. -Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose. -This IS includes security measures (e.g., authentication and access controls) to protect USG interests--not for your personal benefit or privacy. -Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details." If the banner text does not match the Standard Mandatory DoD Notice and Consent Banner exactly, this is a finding.
Configure OL 8 to display the Standard Mandatory DoD Notice and Consent Banner before granting access to the system via command line logon. Edit the "/etc/issue" file to replace the default text with the Standard Mandatory DoD Notice and Consent Banner. The DoD-required text is: "You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only. By using this IS (which includes any device attached to this IS), you consent to the following conditions: -The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations. -At any time, the USG may inspect and seize data stored on this IS. -Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose. -This IS includes security measures (e.g., authentication and access controls) to protect USG interests -- not for your personal benefit or privacy. -Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details."
Verify that OL 8 monitors all remote access methods. Check that remote access methods are being logged by running the following command: $ sudo grep -E '(auth\.\*|authpriv\.\*|daemon\.\*)' /etc/rsyslog.conf /etc/rsyslog.d/*.conf /etc/rsyslog.conf:auth.*;authpriv.*;daemon.* /var/log/secure If "auth.*", "authpriv.*", or "daemon.*" are not configured to be logged, this is a finding.
Configure OL 8 to monitor all remote access methods by installing rsyslog with the following command: $ sudo yum install rsyslog Add or update the following lines to the "/etc/rsyslog.conf" file: auth.*;authpriv.*;daemon.* /var/log/secure The "rsyslog" service must be restarted for the changes to take effect. To restart the "rsyslog" service, run the following command: $ sudo systemctl restart rsyslog.service
Verify OL 8, for PKI-based authentication, has valid certificates by constructing a certification path (which includes status information) to an accepted trust anchor. Note: If the system administrator (SA) demonstrates the use of an approved alternate multifactor authentication method, this requirement is Not Applicable. Check that the system has a valid DOD root CA installed with the following command: $ sudo openssl x509 -text -in /etc/sssd/pki/sssd_auth_ca_db.pem Certificate: Data: Version: 3 (0x2) Serial Number: 1 (0x1) Signature Algorithm: sha256WithRSAEncryption Issuer: C = US, O = U.S. Government, OU = DoD, OU = PKI, CN = DoD Root CA 3 Validity Not Before: Mar 20 18:46:41 2012 GMT Not After : Dec 30 18:46:41 2029 GMT Subject: C = US, O = U.S. Government, OU = DoD, OU = PKI, CN = DoD Root CA 3 Subject Public Key Info: Public Key Algorithm: rsaEncryption If the root ca file is not a DOD-issued certificate with a valid date installed in the "/etc/sssd/pki/sssd_auth_ca_db.pem" location, this is a finding.
Configure OL 8, for PKI-based authentication, to validate certificates by constructing a certification path (which includes status information) to an accepted trust anchor. Obtain a valid copy of the DOD root CA file from the PKI CA certificate bundle at cyber.mil and copy it into the following file: /etc/sssd/pki/sssd_auth_ca_db.pem
Verify the SSH private key files have a passcode. For each private key stored on the system, use the following command: $ sudo ssh-keygen -y -f /path/to/file If the contents of the key are displayed, this is a finding.
Create a new private and public key pair that uses a passcode with the following command: $ sudo ssh-keygen -n [passphrase]
Verify that the shadow password suite configuration is set to encrypt passwords with a FIPS 140-2 approved cryptographic hashing algorithm. Check the hashing algorithm that is being used to hash passwords with the following command: $ sudo cat /etc/login.defs | grep -i crypt ENCRYPT_METHOD SHA512 If "ENCRYPT_METHOD" does not equal SHA512 or greater, this is a finding.
Configure OL 8 to encrypt all stored passwords. Edit/modify the following line in the "/etc/login.defs" file and set "[ENCRYPT_METHOD]" to SHA512: ENCRYPT_METHOD SHA512
Confirm that the interactive user account passwords are using a strong password hash with the following command: $ sudo cut -d: -f2 /etc/shadow $6$kcOnRq/5$NUEYPuyL.wghQwWssXRcLRFiiru7f5JPV6GaJhNC2aK5F3PZpE/BCCtwrxRc/AInKMNX3CdMw11m9STiql12f/ Password hashes "!" or "*" indicate inactive accounts not available for logon and are not evaluated. If any interactive user password hash does not begin with "$6$", this is a finding.
Lock all interactive user accounts not using SHA-512 hashing until the passwords can be regenerated with SHA-512.
Check that a minimum number of hash rounds is configured by running the following command: $ sudo grep -E "^SHA_CRYPT_" /etc/login.defs If only one of "SHA_CRYPT_MIN_ROUNDS" or "SHA_CRYPT_MAX_ROUNDS" is set, and this value is below "5000", this is a finding. If both "SHA_CRYPT_MIN_ROUNDS" and "SHA_CRYPT_MAX_ROUNDS" are set, and the value for either is below "5000", this is a finding.
Configure OL 8 to encrypt all stored passwords with a strong cryptographic hash. Edit/modify the following line in the "/etc/login.defs" file and set "SHA_CRYPT_MIN_ROUNDS" to a value no lower than "5000": SHA_CRYPT_MIN_ROUNDS 5000
For systems that use BIOS, this is not applicable. Determine if an encrypted password is set for the grub superusers account. On systems that use UEFI, use the following command: $ sudo grep -iw grub2_password /boot/efi/EFI/redhat/user.cfg GRUB2_PASSWORD=grub.pbkdf2.sha512.[password_hash] If the grub superusers account password does not begin with "grub.pbkdf2.sha512", this is a finding.
Configure the system to require an encrypted grub bootloader password for the grub superusers account with the grub2-setpassword command, which creates/overwrites the "/boot/efi/EFI/redhat/user.cfg" file. Generate an encrypted grub2 password for the grub superusers account with the following command: $ sudo grub2-setpassword Enter password: Confirm password:
For systems that use BIOS, this is Not Applicable. Verify that a unique name is set as the "superusers" account: $ sudo grep -iw "superusers" /boot/efi/EFI/redhat/grub.cfg set superusers="[someuniqueUserNamehere]" export superusers If "superusers" is identical to any OS account name or is missing a name, this is a finding.
Configure the system to replace "root" with a unique name for the grub superusers account. Edit the /etc/grub.d/01_users file and add or modify the following lines: set superusers="[someuniqueUserNamehere]" export superusers password_pbkdf2 [someuniqueUserNamehere] ${GRUB2_PASSWORD} Generate a new grub.cfg file with the following command: $ sudo grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg
For systems that use UEFI, this is Not Applicable. Verify that a unique name is set as the "superusers" account: $ sudo grep -iw "superusers" /boot/grub2/grub.cfg set superusers="[someuniqueUserNamehere]" export superusers If "superusers" is identical to any OS account name or is missing a name, this is a finding.
Configure the system to replace "root" with a unique name for the grub superusers account. Edit the /etc/grub.d/01_users file and add or modify the following lines: set superusers="[someuniqueUserNamehere]" export superusers password_pbkdf2 [someuniqueUserNamehere] ${GRUB2_PASSWORD} Generate a new grub.cfg file with the following command: $ sudo grub2-mkconfig -o /boot/grub2/grub.cfg
For systems that use UEFI, this is not applicable. Determine if an encrypted password is set for the grub superusers account. On systems that use a BIOS, use the following command: $ sudo grep -iw grub2_password /boot/grub2/user.cfg GRUB2_PASSWORD=grub.pbkdf2.sha512.[password_hash] If the grub superusers account password does not begin with "grub.pbkdf2.sha512", this is a finding.
Configure the system to require a grub bootloader password for the grub superusers account with the grub2-setpassword command, which creates/overwrites the "/boot/grub2/user.cfg" file. Generate an encrypted grub2 password for the grub superusers account with the following command: $ sudo grub2-setpassword Enter password: Confirm password:
Determine if the system requires authentication for rescue mode with the following command: $ sudo grep sulogin-shell /usr/lib/systemd/system/rescue.service ExecStart=-/usr/lib/systemd/systemd-sulogin-shell rescue If the "ExecStart" line is configured for anything other than "/usr/lib/systemd/systemd-sulogin-shell rescue" or is commented out or missing, this is a finding.
Configure the system to require authentication upon booting into rescue mode by adding the following line to the "/usr/lib/systemd/system/rescue.service" file: ExecStart=-/usr/lib/systemd/systemd-sulogin-shell rescue
Determine if the system requires authentication for emergency mode with the following command: $ sudo grep sulogin-shell /usr/lib/systemd/system/emergency.service ExecStart=-/usr/lib/systemd/systemd-sulogin-shell emergency If the "ExecStart" line is configured for anything other than "/usr/lib/systemd/systemd-sulogin-shell emergency" or is commented out or missing, this is a finding.
Configure the system to require authentication upon booting into emergency mode by adding the following line to the "/usr/lib/systemd/system/emergency.service" file: ExecStart=-/usr/lib/systemd/systemd-sulogin-shell emergency
Verify that the "pam_unix.so" module is configured to use sha512. Check that pam_unix.so module is configured to use sha512 in /etc/pam.d/system-auth with the following command: $ sudo grep password /etc/pam.d/system-auth | grep pam_unix password sufficient pam_unix.so sha512 If "sha512" is missing, or is commented out, this is a finding.
Configure OL 8 to use a FIPS 140-2 approved cryptographic hashing algorithm for system authentication. Edit/modify the following line in the "/etc/pam.d/system-auth" file to include the sha512 option for pam_unix.so: password sufficient pam_unix.so sha512
Verify that the "pam_unix.so" module is configured to use sha512 in "/etc/pam.d/password-auth" with the following command: $ sudo grep password /etc/pam.d/password-auth | grep pam_unix password sufficient pam_unix.so sha512 If "sha512" is missing, or is commented out, this is a finding.
Configure OL 8 to use a FIPS 140-2 approved cryptographic hashing algorithm for system authentication. Edit/modify the following line in the "/etc/pam.d/password-auth" file to include the sha512 option for pam_unix.so: password sufficient pam_unix.so sha512
Verify that OL 8 prevents system daemons from using Kerberos for authentication. If the system is a server using krb5-server-1.17-18.el8.x86_64 or newer, this requirement is not applicable. If the system is a workstation using krb5-workstation-1.17-18.el8.x86_64 or newer, this requirement is not applicable. Check if there are available keytabs with the following command: $ sudo ls -al /etc/*.keytab If this command produces any file(s), this is a finding.
Configure OL 8 to prevent system daemons from using Kerberos for authentication. Remove any files with the .keytab extension from the operating system.
Verify the krb5-workstation package has not been installed on the system with the following commands: If the system is a server or is using krb5-workstation-1.17-18.el8.x86_64 or newer, this is Not Applicable. $ sudo yum list installed krb5-workstation krb5-workstation.x86_64 1.17-9.el8 repository If the krb5-workstation package is installed and is not documented with the Information System Security Officer (ISSO) as an operational requirement, this is a finding.
Document the krb5-workstation package with the ISSO as an operational requirement or remove it from the system with the following command: $ sudo yum remove krb5-workstation
Verify the krb5-server package has not been installed on the system with the following commands: If the system is a workstation or is using krb5-server-1.17-18.el8.x86_64 or newer, this is Not Applicable $ sudo yum list installed krb5-server krb5-server.x86_64 1.17-9.el8 repository If the krb5-server package is installed and is not documented with the Information System Security Officer (ISSO) as an operational requirement, this is a finding.
Document the krb5-server package with the ISSO as an operational requirement or remove it from the system with the following command: $ sudo yum remove krb5-server
Verify the operating system verifies correct operation of all security functions. Check if "SELinux" is in "Enforcing" mode with the following command: $ getenforce Enforcing If "SELinux" is not in "Enforcing" mode, this is a finding.
Configure OL 8 to verify correct operation of all security functions. Set "SELinux" to "Enforcing" mode by modifying the "/etc/selinux/config" file with the following line: SELINUX=enforcing A reboot is required for the changes to take effect.
Verify the operating system has the "policycoreutils" package installed with the following command: $ sudo yum list installed policycoreutils policycoreutils.x86_64 2.9-3.el8 @anaconda If the "policycoreutils" package is not installed, this is a finding.
Install the "policycoreutil" package, if it is not already installed, by running the following command: $ sudo yum install policycoreutils
Verify that all world-writable directories have the sticky bit set. Verify that all world-writable directories have the sticky bit set by running the following command: $ sudo find / -type d \( -perm -0002 -a ! -perm -1000 \) -print 2>/dev/null If any of the returned directories are world-writable and do not have the sticky bit set, this is a finding.
Configure all world-writable directories to have the sticky bit set to prevent unauthorized and unintended information transferred via shared system resources. Set the sticky bit on all world-writable directories using the command, replace "[World-Writable Directory]" with any directory path missing the sticky bit: $ sudo chmod 1777 [World-Writable Directory]
Verify the SSH server automatically terminates a user session after the SSH client has become unresponsive. Check that the "ClientAliveCountMax" is set to "1" by running the following command: $ sudo /usr/sbin/sshd -dd 2>&1 | awk '/filename/ {print $4}' | tr -d '\r' | tr '\n' ' ' | xargs sudo grep -iH '^\s*clientalivecountmax' ClientAliveCountMax 1 If "ClientAliveCountMax" does not exist, does not have a product value of "1" in "/etc/ssh/sshd_config", or is commented out, this is a finding. If conflicting results are returned, this is a finding.
Note: This setting must be applied in conjunction with OL08-00-010201 to function correctly. Configure the SSH server to terminate a user session automatically after the SSH client has become unresponsive. Modify or append the following line in the "/etc/ssh/sshd_config" file: ClientAliveCountMax 1 For the changes to take effect, the SSH daemon must be restarted. $ sudo systemctl restart sshd.service
Verify the SSH server automatically terminates a user session after the SSH client has been unresponsive for 10 minutes. Check that the "ClientAliveInterval" variable is set to a value of "600" or less by running the following command: $ sudo /usr/sbin/sshd -dd 2>&1 | awk '/filename/ {print $4}' | tr -d '\r' | tr '\n' ' ' | xargs sudo grep -iH '^\s*clientaliveinterval' ClientAliveInterval 600 If "ClientAliveInterval" does not exist, does not have a product value of "600" or less in "/etc/ssh/sshd_config", or is commented out, this is a finding. If conflicting results are returned, this is a finding.
Note: This setting must be applied in conjunction with OL08-00-010200 to function correctly. Configure the SSH server to terminate a user session automatically after the SSH client has been unresponsive for 10 minutes. Modify or append the following lines in the "/etc/ssh/sshd_config" file to have a product value of "600" or less: ClientAliveInterval 600 The SSH daemon must be restarted for changes to take effect. $ sudo systemctl restart sshd.service
Verify that the "/var/log/messages" file has mode "0640" or less permissive with the following command: $ sudo stat -c "%a %n" /var/log/messages 640 /var/log/messages If a value of "0640" or less permissive is not returned, this is a finding.
Change the permissions of the file "/var/log/messages" to "0640" by running the following command: $ sudo chmod 0640 /var/log/messages
Verify that the /var/log/messages file is owned by root with the following command: $ sudo stat -c "%U" /var/log/messages root If "root" is not returned as a result, this is a finding.
Change the owner of the file /var/log/messages to root by running the following command: $ sudo chown root /var/log/messages
Verify the "/var/log/messages" file is group-owned by root with the following command: $ sudo stat -c "%G" /var/log/messages root If "root" is not returned as a result, this is a finding.
Change the group of the file "/var/log/messages" to "root" by running the following command: $ sudo chgrp root /var/log/messages
Verify that the "/var/log" directory has a mode of "0755" or less with the following command: $ sudo stat -c "%a %n" /var/log 755 /var/log If a value of "0755" or less permissive is not returned, this is a finding.
Change the permissions of the directory "/var/log" to "0755" by running the following command: $ sudo chmod 0755 /var/log
Verify the /var/log directory is owned by root with the following command: $ sudo stat -c "%U" /var/log root If "root" is not returned as a result, this is a finding.
Change the owner of the directory /var/log to root by running the following command: $ sudo chown root /var/log
Verify the "/var/log" directory is group-owned by root with the following command: $ sudo stat -c "%G" /var/log root If "root" is not returned as a result, this is a finding.
Change the group of the directory "/var/log" to "root" by running the following command: $ sudo chgrp root /var/log
Verify that system-wide crypto policies are in effect: $ sudo grep -i CRYPTO_POLICY /etc/sysconfig/sshd # CRYPTO_POLICY= If the "CRYPTO_POLICY" is uncommented, this is a finding.
Configure the OL 8 SSH daemon to use system-wide crypto policies by adding the following line to /etc/sysconfig/sshd: # CRYPTO_POLICY= A reboot is required for the changes to take effect.
Verify the SSH server is configured to use only MACs employing FIPS 140-2-approved algorithms with the following command: $ sudo grep -i macs /etc/crypto-policies/back-ends/opensshserver.config -oMACS=hmac-sha2-512,hmac-sha2-256,hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com If the MACs entries in the "opensshserver.config" file have any hashes other than shown here, the order differs from the example above, or they are missing or commented out, this is a finding.
Configure the OL 8 SSH server to use only MACs employing FIPS 140-2 approved algorithms: Update the "/etc/crypto-policies/back-ends/opensshserver.config" file to include these MACs employing FIPS 140-2 approved algorithms: -oMACS=hmac-sha2-512,hmac-sha2-256,hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com A reboot is required for the changes to take effect.
Verify the OL 8 SSH server is configured to use only ciphers employing FIPS 140-2 approved algorithms with the following command: $ sudo grep -i ciphers /etc/crypto-policies/back-ends/opensshserver.config CRYPTO_POLICY='-oCiphers=aes256-ctr,aes192-ctr,aes128-ctr,aes256-gcm@openssh.com,aes128-gcm@openssh.com' If the cipher entries in the "opensshserver.config" file have any ciphers other than shown here, the order differs from the example above, or they are missing or commented out, this is a finding.
Configure the OL 8 SSH server to use only ciphers employing FIPS 140-2 approved algorithms: Update the "/etc/crypto-policies/back-ends/opensshserver.config" file to include these ciphers employing FIPS 140-2-approved algorithms: CRYPTO_POLICY='-oCiphers=aes256-ctr,aes192-ctr,aes128-ctr,aes256-gcm@openssh.com,aes128-gcm@openssh.com' A reboot is required for the changes to take effect.
Verify the operating system SSH server uses strong entropy with the following command: $ sudo grep -i ssh_use_strong_rng /etc/sysconfig/sshd SSH_USE_STRONG_RNG=32 If the "SSH_USE_STRONG_RNG" line does not equal "32" or is commented out or missing, this is a finding.
Configure the operating system SSH server to use strong entropy. Add or modify the following line in the "/etc/sysconfig/sshd" file. SSH_USE_STRONG_RNG=32 The SSH service must be restarted for changes to take effect.
Verify the OpenSSL library is configured to use only ciphers employing FIPS 140-2-approved algorithms: Verify that system-wide crypto policies are in effect: $ sudo grep -i opensslcnf.config /etc/pki/tls/openssl.cnf .include /etc/crypto-policies/back-ends/opensslcnf.config If the "opensslcnf.config" is not defined in the "/etc/pki/tls/openssl.cnf" file, this is a finding. Verify which system-wide crypto policy is in use: $ sudo update-crypto-policies --show FIPS If the system-wide crypto policy is set to anything other than "FIPS", this is a finding.
Configure the OL 8 OpenSSL library to use only ciphers employing FIPS 140-2-approved algorithms with the following command: $ sudo fips-mode-setup --enable A reboot is required for the changes to take effect.
Verify the OpenSSL library is configured to use only DoD-approved TLS encryption: For versions prior to crypto-policies-20210617-1.gitc776d3e.el8.noarch: $ sudo grep -i MinProtocol /etc/crypto-policies/back-ends/opensslcnf.config MinProtocol = TLSv1.2 If the "MinProtocol" is set to anything older than "TLSv1.2", this is a finding. For version crypto-policies-20210617-1.gitc776d3e.el8.noarch and newer: $ sudo grep -i MinProtocol /etc/crypto-policies/back-ends/opensslcnf.config TLS.MinProtocol = TLSv1.2 DTLS.MinProtocol = DTLSv1.2 If the "TLS.MinProtocol" is set to anything older than "TLSv1.2" or the "DTLS.MinProtocol" is set to anything older than "DTLSv1.2", this is a finding.
Configure the OL 8 OpenSSL library to use only DoD-approved TLS encryption by editing the following line in the "/etc/crypto-policies/back-ends/opensslcnf.config" file: For versions prior to crypto-policies-20210617-1.gitc776d3e.el8.noarch: MinProtocol = TLSv1.2 For version crypto-policies-20210617-1.gitc776d3e.el8.noarch and newer: TLS.MinProtocol = TLSv1.2 DTLS.MinProtocol = DTLSv1.2 A reboot is required for the changes to take effect.
Verify the GnuTLS library is configured to only allow DoD-approved SSL/TLS versions: $ sudo grep -io +vers.* /etc/crypto-policies/back-ends/gnutls.config +VERS-ALL:-VERS-DTLS0.9:-VERS-SSL3.0:-VERS-TLS1.0:-VERS-TLS1.1:-VERS-DTLS1.0:+COMP-NULL:%PROFILE_MEDIUM If the "gnutls.config" does not list "-VERS-DTLS0.9:-VERS-SSL3.0:-VERS-TLS1.0:-VERS-TLS1.1:-VERS-DTLS1.0" to disable unapproved SSL/TLS versions, this is a finding.
Configure the OL 8 GnuTLS library to use only DoD-approved encryption by adding the following line to "/etc/crypto-policies/back-ends/gnutls.config": +VERS-ALL:-VERS-DTLS0.9:-VERS-SSL3.0:-VERS-TLS1.0:-VERS-TLS1.1:-VERS-DTLS1.0 A reboot is required for the changes to take effect.
Verify the system commands contained in the following directories have mode "755" or less permissive with the following command: $ sudo find -L /bin /sbin /usr/bin /usr/sbin /usr/local/bin /usr/local/sbin -perm /022 -exec ls -l {} \; If any system commands are found to be group-writable or world-writable, this is a finding.
Configure the system commands to be protected from unauthorized access. Run the following command, replacing "[FILE]" with any system command with a mode more permissive than "755". $ sudo chmod 755 [FILE]
Verify the system commands contained in the following directories are owned by "root" with the following command: $ sudo find -L /bin /sbin /usr/bin /usr/sbin /usr/local/bin /usr/local/sbin ! -user root -exec ls -l {} \; If any system commands are returned, this is a finding.
Configure the system commands to be protected from unauthorized access. Run the following command, replacing "[FILE]" with any system command file not owned by "root". $ sudo chown root [FILE]
Verify the system commands contained in the following directories are group-owned by "root" or a required system account, with the following command: $ sudo find -L /bin /sbin /usr/bin /usr/sbin /usr/local/bin /usr/local/sbin ! -group root -exec ls -l {} \; If any system commands are returned and is not group-owned by a required system account, this is a finding.
Configure the system commands to be protected from unauthorized access. Run the following command, replacing "[FILE]" with any system command file not group-owned by "root" or a required system account. $ sudo chgrp root [FILE]
Verify the system-wide shared library files contained in the following directories have mode "755" or less permissive with the following command: $ sudo find -L /lib /lib64 /usr/lib /usr/lib64 -perm /022 -type f -exec ls -l {} \; If any system-wide shared library file is found to be group-writable or world-writable, this is a finding.
Configure the library files to be protected from unauthorized access. Run the following command, replacing "[FILE]" with any library file with a mode more permissive than 755. $ sudo chmod 755 [FILE]
Verify the system-wide shared library files are owned by "root" with the following command: $ sudo find -L /lib /lib64 /usr/lib /usr/lib64 ! -user root -exec ls -l {} \; If any system-wide shared library file is returned, this is a finding.
Configure the system-wide shared library files (/lib, /lib64, /usr/lib, and /usr/lib64) to be protected from unauthorized access. Run the following command, replacing "[FILE]" with any library file not owned by "root". $ sudo chown root [FILE]
Verify the system-wide shared library files are group-owned by "root" with the following command: $ sudo find -L /lib /lib64 /usr/lib /usr/lib64 ! -group root -exec ls -l {} \; If any system-wide shared library file is returned, this is a finding.
Configure the system-wide shared library files (/lib, /lib64, /usr/lib, and /usr/lib64) to be protected from unauthorized access. Run the following command, replacing "[FILE]" with any library file not group-owned by "root". $ sudo chgrp root [FILE]
Verify the operating system routinely checks the baseline configuration for unauthorized changes and notifies the SA when anomalies in the operation of any security functions are discovered. Check that OL 8 routinely executes a file integrity scan for changes to the system baseline. The command used in the example will use a daily occurrence. Check the cron directories for scripts controlling the execution and notification of results of the file integrity application. For example, if AIDE is installed on the system, use the following commands: $ sudo ls -al /etc/cron.* | grep aide -rwxr-xr-x 1 root root 29 Nov 22 2015 aide $ sudo grep aide /etc/crontab /var/spool/cron/root /etc/crontab: 30 04 * * * /root/aide /var/spool/cron/root: 30 04 * * * /root/aide $ sudo more /etc/cron.daily/aide #!/bin/bash /usr/sbin/aide --check | /bin/mail -s "$HOSTNAME - Daily AIDE integrity check run" root@example_server_name.mil If the file integrity application does not exist, a script file controlling the execution of the file integrity application does not exist, or the file integrity application does not notify designated personnel of changes, this is a finding.
Configure the file integrity tool to run automatically on the system at least weekly and to notify designated personnel if baseline configurations are changed in an unauthorized manner. The AIDE tool can be configured to email designated personnel with the use of the cron system. The following example output is generic. It will set cron to run AIDE daily and to send an email at the completion of the analysis. $ sudo more /etc/cron.daily/aide #!/bin/bash /usr/sbin/aide --check |/bin/mail -s "$HOSTNAME - Daily AIDE integrity check run" root@example_server_name.mil Note: Per requirement OL08-00-010358, the "mailx" package must be installed on the system to enable email functionality.
Check that YUM verifies the signature of packages from a repository prior to install with the following command: $ sudo grep gpgcheck /etc/yum.repos.d/*.repo gpgcheck=1 If "gpgcheck" is not set to "1", or if options are missing or commented out, ask the system administrator (SA) how the certificates for patches and other operating system components are verified. If there is no process to validate certificates that is approved by the organization, this is a finding.
Configure OL 8 to verify the signature of packages from a repository prior to install by setting the following option in the "/etc/yum.repos.d/[your_repo_name].repo" file: gpgcheck=1
Verify the operating system prevents the installation of patches, service packs, device drivers, or operating system components from a repository without verification that they have been digitally signed using a certificate that is recognized and approved by the organization. Check if YUM is configured to perform a signature check on local packages with the following command: $ sudo grep -i localpkg_gpgcheck /etc/dnf/dnf.conf localpkg_gpgcheck =True If "localpkg_gpgcheck" is not set to either "1", "True", or "yes", commented out, or is missing from "/etc/dnf/dnf.conf", this is a finding.
Configure the operating system to remove all software components after updated versions have been installed. Set the "localpkg_gpgcheck" option to "True" in the "/etc/dnf/dnf.conf" file: localpkg_gpgcheck=True
Note: For OL 8 systems using the Oracle Unbreakable Enterprise Kernel (UEK) Release 6 or above and with secureboot enabled, this requirement is Not Applicable. Verify the operating system is configured to disable kernel image loading with the following commands. Check the status of the "kernel.kexec_load_disabled" kernel parameter: $ sudo sysctl kernel.kexec_load_disabled kernel.kexec_load_disabled = 1 If "kernel.kexec_load_disabled" is not set to "1" or is missing, this is a finding. Check that the configuration files are present to enable this kernel parameter: $ sudo grep -r kernel.kexec_load_disabled /run/sysctl.d/*.conf /usr/local/lib/sysctl.d/*.conf /usr/lib/sysctl.d/*.conf /lib/sysctl.d/*.conf /etc/sysctl.conf /etc/sysctl.d/*.conf /etc/sysctl.d/99-sysctl.conf:kernel.kexec_load_disabled = 1 If "kernel.kexec_load_disabled" is not set to "1" or is missing or commented out, this is a finding. If conflicting results are returned, this is a finding.
Configure OL 8 to disable kernel image loading. Add or edit the following line in a system configuration file in the "/etc/sysctl.d/" directory: kernel.kexec_load_disabled = 1 Remove any configurations that conflict with the above from the following locations: /run/sysctl.d/*.conf /usr/local/lib/sysctl.d/*.conf /usr/lib/sysctl.d/*.conf /lib/sysctl.d/*.conf /etc/sysctl.conf /etc/sysctl.d/*.conf Load settings from all system configuration files with the following command: $ sudo sysctl --system
Verify the operating system is configured to enable DAC on symlinks with the following commands. Check the status of the "fs.protected_symlinks" kernel parameter: $ sudo sysctl fs.protected_symlinks fs.protected_symlinks = 1 If "fs.protected_symlinks" is not set to "1" or is missing, this is a finding. Check that the configuration files are present to enable this kernel parameter: $ sudo grep -r fs.protected_symlinks /run/sysctl.d/*.conf /usr/local/lib/sysctl.d/*.conf /usr/lib/sysctl.d/*.conf /lib/sysctl.d/*.conf /etc/sysctl.conf /etc/sysctl.d/*.conf /etc/sysctl.d/99-sysctl.conf:fs.protected_symlinks = 1 If "fs.protected_symlinks" is not set to "1" or is missing or commented out, this is a finding. If conflicting results are returned, this is a finding.
Configure OL 8 to enable DAC on symlinks. Add or edit the following line in a system configuration file in the "/etc/sysctl.d/" directory: fs.protected_symlinks = 1 Remove any configurations that conflict with the above from the following locations: /run/sysctl.d/*.conf /usr/local/lib/sysctl.d/*.conf /usr/lib/sysctl.d/*.conf /lib/sysctl.d/*.conf /etc/sysctl.conf /etc/sysctl.d/*.conf Load settings from all system configuration files with the following command: $ sudo sysctl --system
Verify the operating system is configured to enable DAC on hardlinks with the following commands. Check the status of the "fs.protected_hardlinks" kernel parameter: $ sudo sysctl fs.protected_hardlinks fs.protected_hardlinks = 1 If "fs.protected_hardlinks" is not set to "1" or is missing, this is a finding. Check that the configuration files are present to enable this kernel parameter: $ sudo grep -r fs.protected_hardlinks /run/sysctl.d/*.conf /usr/local/lib/sysctl.d/*.conf /usr/lib/sysctl.d/*.conf /lib/sysctl.d/*.conf /etc/sysctl.conf /etc/sysctl.d/*.conf /etc/sysctl.d/99-sysctl.conf:fs.protected_hardlinks = 1 If "fs.protected_hardlinks" is not set to "1" or is missing or commented out, this is a finding. If conflicting results are returned, this is a finding.
Configure OL 8 to enable DAC on hardlinks. Add or edit the following line in a system configuration file in the "/etc/sysctl.d/" directory: fs.protected_hardlinks = 1 Remove any configurations that conflict with the above from the following locations: /run/sysctl.d/*.conf /usr/local/lib/sysctl.d/*.conf /usr/lib/sysctl.d/*.conf /lib/sysctl.d/*.conf /etc/sysctl.conf /etc/sysctl.d/*.conf Load settings from all system configuration files with the following command: $ sudo sysctl --system
Verify the operating system is configured to restrict access to the kernel message buffer with the following commands. Check the status of the "kernel.dmesg_restrict" kernel parameter: $ sudo sysctl kernel.dmesg_restrict kernel.dmesg_restrict = 1 If "kernel.dmesg_restrict" is not set to "1" or is missing, this is a finding. Check that the configuration files are present to enable this kernel parameter: $ sudo grep -r kernel.dmesg_restrict /run/sysctl.d/*.conf /usr/local/lib/sysctl.d/*.conf /usr/lib/sysctl.d/*.conf /lib/sysctl.d/*.conf /etc/sysctl.conf /etc/sysctl.d/*.conf /etc/sysctl.d/99-sysctl.conf:kernel.dmesg_restrict = 1 If "kernel.dmesg_restrict" is not set to "1" or is missing or commented out, this is a finding. If conflicting results are returned, this is a finding.
Configure OL 8 to restrict access to the kernel message buffer. Add or edit the following line in a system configuration file in the "/etc/sysctl.d/" directory: kernel.dmesg_restrict = 1 Remove any configurations that conflict with the above from the following locations: /run/sysctl.d/*.conf /usr/local/lib/sysctl.d/*.conf /usr/lib/sysctl.d/*.conf /lib/sysctl.d/*.conf /etc/sysctl.conf /etc/sysctl.d/*.conf Load settings from all system configuration files with the following command: $ sudo sysctl --system
Verify the operating system is configured to prevent kernel profiling by unprivileged users with the following commands. Check the status of the "kernel.perf_event_paranoid" kernel parameter: $ sudo sysctl kernel.perf_event_paranoid kernel.perf_event_paranoid = 2 If "kernel.perf_event_paranoid" is not set to "2" or is missing, this is a finding. Check that the configuration files are present to enable this kernel parameter: $ sudo grep -r kernel.perf_event_paranoid /run/sysctl.d/*.conf /usr/local/lib/sysctl.d/*.conf /usr/lib/sysctl.d/*.conf /lib/sysctl.d/*.conf /etc/sysctl.conf /etc/sysctl.d/*.conf /etc/sysctl.d/99-sysctl.conf:kernel.perf_event_paranoid = 2 If "kernel.perf_event_paranoid" is not set to "2" or is missing or commented out, this is a finding. If conflicting results are returned, this is a finding.
Configure OL 8 to prevent kernel profiling by unprivileged users. Add or edit the following line in a system configuration file in the "/etc/sysctl.d/" directory: kernel.perf_event_paranoid = 2 Remove any configurations that conflict with the above from the following locations: /run/sysctl.d/*.conf /usr/local/lib/sysctl.d/*.conf /usr/lib/sysctl.d/*.conf /lib/sysctl.d/*.conf /etc/sysctl.conf /etc/sysctl.d/*.conf Load settings from all system configuration files with the following command: $ sudo sysctl --system
Verify that "/etc/sudoers" has no occurrences of "NOPASSWD". Check that the "/etc/sudoers" file has no occurrences of "NOPASSWD" by running the following command: $ sudo grep -ir nopasswd /etc/sudoers /etc/sudoers.d %admin ALL=(ALL) NOPASSWD: ALL If any occurrences of "NOPASSWD" are returned from the command and have not been documented with the information system security officer (ISSO) as an organizationally defined administrative group using multifactor authentication (MFA), this is a finding.
Configure the operating system to require users to supply a password for privilege escalation. Check the configuration of the "/etc/sudoers" file with the following command: $ sudo visudo Remove any occurrences of "NOPASSWD" tags in the file. Check the configuration of the /etc/sudoers.d/* files with the following command: $ sudo grep -ir nopasswd /etc/sudoers.d Remove any occurrences of "NOPASSWD" tags in the file.
Verify that the "/etc/sudoers" file has no occurrences of "!authenticate" by running the following command: $ sudo grep -Ei !authenticate /etc/sudoers /etc/sudoers.d/* If any occurrences of "!authenticate" return from the command, this is a finding.
Remove any occurrence of "!authenticate" found in the "/etc/sudoers" file or files in the "/etc/sudoers.d" directory.
Verify the "sudoers" file restricts sudo access to authorized personnel. $ sudo grep -iw 'ALL' /etc/sudoers /etc/sudoers.d/* If the either of the following entries are returned, this is a finding: ALL ALL=(ALL) ALL ALL ALL=(ALL:ALL) ALL
Remove the following entries from the sudoers file: ALL ALL=(ALL) ALL ALL ALL=(ALL:ALL) ALL
Verify that the sudoers security policy is configured to use the invoking user's password for privilege escalation. $ sudo grep -Eir '(rootpw|targetpw|runaspw)' /etc/sudoers /etc/sudoers.d* | grep -v '#' /etc/sudoers:Defaults !targetpw /etc/sudoers:Defaults !rootpw /etc/sudoers:Defaults !runaspw If conflicting results are returned, this is a finding. If "Defaults !targetpw" is not defined, this is a finding. If "Defaults !rootpw" is not defined, this is a finding. If "Defaults !runaspw" is not defined, this is a finding.
Define the following in the Defaults section of the /etc/sudoers file or a configuration file in the /etc/sudoers.d/ directory: Defaults !targetpw Defaults !rootpw Defaults !runaspw Remove any configurations that conflict with the above from the following locations: /etc/sudoers /etc/sudoers.d/
Verify the operating system requires re-authentication when using the "sudo" command to elevate privileges. $ sudo grep -Eir 'timestamp_timeout' /etc/sudoers /etc/sudoers.d* /etc/sudoers:Defaults timestamp_timeout=0 If conflicting results are returned, this is a finding. If "timestamp_timeout" is set to a negative number, is commented out, or no results are returned, this is a finding.
Configure the "sudo" command to require re-authentication. Edit the /etc/sudoers file: $ sudo visudo Add or modify the following line: Defaults timestamp_timeout=[value] Note: The "[value]" must be a number that is greater than or equal to "0". Remove any duplicate or conflicting lines from /etc/sudoers and /etc/sudoers.d/ files.
Verify the operating system has the package required for multifactor authentication installed with the following command: $ sudo yum list installed openssl-pkcs11 openssl-pkcs11.x86_64 0.4.8-2.el8 @anaconda If the "openssl-pkcs11" package is not installed, ask the administrator to indicate what type of multifactor authentication is being used and what packages are installed to support it. If there is no evidence of multifactor authentication being used, this is a finding.
Configure OL 8 to implement multifactor authentication by installing the required package with the following command: $ sudo yum install openssl-pkcs11
Verify the operating system implements certificate status checking for multifactor authentication. Note: If the system administrator (SA) demonstrates the use of an approved alternate multifactor authentication method, this requirement is not applicable. Determine if Online Certificate Status Protocol (OCSP) is enabled and using the proper digest value on the system with the following command: $ sudo grep certificate_verification /etc/sssd/sssd.conf /etc/sssd/conf.d/*.conf | grep -v "^#" certificate_verification = ocsp_dgst=sha1 If the certificate_verification line is missing from the [sssd] section, or is missing "ocsp_dgst=sha1", ask the administrator to indicate what type of multifactor authentication is being used and how the system implements certificate status checking. If there is no evidence of certificate status checking being used, this is a finding.
Configure OL 8 to implement certificate status checking for multifactor authentication. Review the "/etc/sssd/sssd.conf" file to determine if the system is configured to prevent OCSP or certificate verification. Add the following line to the [sssd] section of the "/etc/sssd/sssd.conf" file: certificate_verification = ocsp_dgst=sha1 The "sssd" service must be restarted for the changes to take effect. To restart the "sssd" service, run the following command: $ sudo systemctl restart sssd.service
Verify OL 8 accepts PIV credentials. Check that the "opensc" package is installed on the system with the following command: $ sudo yum list installed opensc opensc.x86_64 0.19.0-5.el8 @anaconda Check that "opensc" accepts PIV cards with the following command: $ sudo opensc-tool --list-drivers | grep -i piv PIV-II Personal Identity Verification Card If the "opensc" package is not installed and the "opensc-tool" driver list does not include "PIV-II", this is a finding.
Configure OL 8 to accept PIV credentials. Install the "opensc" package using the following command: $ sudo yum install opensc
Verify the NX (no-execution) bit flag is set on the system with the following commands: $ sudo dmesg | grep NX [ 0.000000] NX (Execute Disable) protection: active If "dmesg" does not show "NX (Execute Disable) protection" active, check the "cpuinfo" settings with the following command: $ sudo less /proc/cpuinfo | grep -i flags flags : fpu vme de pse tsc ms nx rdtscp lm constant_tsc If "flags" does not contain the "nx" flag, this is a finding.
Enable the NX bit execute protection in the system BIOS.
Verify that GRUB 2 is configured to enable page poisoning to mitigate use-after-free vulnerabilities with the following commands: $ sudo grub2-editenv list | grep page_poison kernelopts=root=/dev/mapper/ol-root ro crashkernel=auto resume=/dev/mapper/ol-swap rd.lvm.lv=ol/root rd.lvm.lv=ol/swap rhgb quiet fips=1 page_poison=1 vsyscall=none audit=1 audit_backlog_limit=8192 boot=UUID=8d171156-cd61-421c-ba41-1c021ac29e82 If "page_poison" is not set to "1" or is missing, this is a finding. Check that page poisoning is enabled by default to persist in kernel updates: $ sudo grep page_poison /etc/default/grub GRUB_CMDLINE_LINUX="page_poison=1" If "page_poison" is not set to "1" or is missing or commented out, this is a finding.
Configure OL 8 to enable page poisoning with the following commands: $ sudo grubby --update-kernel=ALL --args="page_poison=1" Add or modify the following line in "/etc/default/grub" to ensure the configuration survives kernel updates: GRUB_CMDLINE_LINUX="page_poison=1"
Verify that GRUB 2 is configured to disable vsyscalls with the following commands: $ sudo grub2-editenv list | grep vsyscall kernelopts=root=/dev/mapper/ol-root ro crashkernel=auto resume=/dev/mapper/ol-swap rd.lvm.lv=ol/root rd.lvm.lv=ol/swap rhgb quiet fips=1 page_poison=1 vsyscall=none audit=1 audit_backlog_limit=8192 boot=UUID=8d171156-cd61-421c-ba41-1c021ac29e82 If "vsyscall" is not set to "none" or is missing, this is a finding. Check that vsyscalls are disabled by default to persist in kernel updates: $ sudo grep vsyscall /etc/default/grub GRUB_CMDLINE_LINUX="vsyscall=none" If "vsyscall" is not set to "none", is missing or commented out and is not documented with the Information System Security Officer (ISSO) as an operational requirement, this is a finding.
Document the use of vsyscalls with the ISSO as an operational requirement or disable them with the following command: $ sudo grubby --update-kernel=ALL --args="vsyscall=none" Add or modify the following line in "/etc/default/grub" to ensure the configuration survives kernel updates: GRUB_CMDLINE_LINUX="vsyscall=none"
Verify that GRUB 2 is configured to enable poisoning of SLUB/SLAB objects to mitigate use-after-free vulnerabilities with the following commands: Check that the current GRUB 2 configuration has poisoning of SLUB/SLAB objects enabled: $ sudo grub2-editenv list | grep slub_debug kernelopts=root=/dev/mapper/ol-root ro crashkernel=auto resume=/dev/mapper/ol-swap rd.lvm.lv=ol/root rd.lvm.lv=ol/swap rhgb quiet fips=1 slub_debug=P page_poison=1 vsyscall=none audit=1 audit_backlog_limit=8192 boot=UUID=8d171156-cd61-421c-ba41-1c021ac29e82 If "slub_debug" does not contain "P" or is missing, this is a finding. Check that poisoning of SLUB/SLAB objects is enabled by default to persist in kernel updates: $ sudo grep slub_debug /etc/default/grub GRUB_CMDLINE_LINUX="slub_debug=P" If "slub_debug" does not contain "P", is missing, or is commented out, this is a finding.
Configure OL 8 to enable poisoning of SLUB/SLAB objects with the following commands: $ sudo grubby --update-kernel=ALL --args="slub_debug=P" Add or modify the following line in "/etc/default/grub" to ensure the configuration survives kernel updates: GRUB_CMDLINE_LINUX="slub_debug=P"
Determine the default kernel: $ sudo grubby --default-kernel /boot/vmlinuz-5.4.17-2011.1.2.el8uek.x86_64 Using the default kernel, verify that Meltdown mitigations are not disabled: $ sudo grubby --info=<path-to-default-kernel> | grep mitigations If the "mitigations" parameter is set to "off", this is a finding.
Determine the default kernel: $ sudo grubby --default-kernel /boot/vmlinuz-5.4.17-2011.1.2.el8uek.x86_64 Using the default kernel, remove the argument that sets the Meltdown mitigations to "off": $ sudo grubby --update-kernel=<path-to-default-kernel> --remove-args=mitigations=off Reboot the system for the change to take effect.
Verify that OL 8 implements ASLR with the following command: $ sudo sysctl kernel.randomize_va_space kernel.randomize_va_space = 2 If "kernel.randomize_va_space" is not set to "2", this is a finding. Check that the configuration files are present to enable this kernel parameter. $ sudo grep -r kernel.randomize_va_space /run/sysctl.d/*.conf /usr/local/lib/sysctl.d/*.conf /usr/lib/sysctl.d/*.conf /lib/sysctl.d/*.conf /etc/sysctl.conf /etc/sysctl.d/*.conf /etc/sysctl.d/99-sysctl.conf:kernel.randomize_va_space = 2 If "kernel.randomize_va_space" is not set to "2", is missing or commented out, this is a finding. If conflicting results are returned, this is a finding.
Configure OL 8 to implement virtual address space randomization. Set the system to the required kernel parameter by adding the following line to "/etc/sysctl.d/*.conf" (or modify the line to have the required value): kernel.randomize_va_space=2 Remove any configurations that conflict with the above from the following locations: /run/sysctl.d/*.conf /usr/local/lib/sysctl.d/*.conf /usr/lib/sysctl.d/*.conf /lib/sysctl.d/*.conf /etc/sysctl.conf /etc/sysctl.d/*.conf Issue the following command to make the changes take effect: $ sudo sysctl --system
Verify the operating system removes all software components after updated versions have been installed. Check if YUM is configured to remove unneeded packages with the following command: $ sudo grep -i clean_requirements_on_remove /etc/yum.conf clean_requirements_on_remove=True If "clean_requirements_on_remove" is not set to "True", commented out, or missing from "/etc/yum.conf", this is a finding.
Configure OL 8 to remove all software components after updated versions have been installed. Set the "clean_requirements_on_remove" option to "True" in the "/etc/yum.conf" file: clean_requirements_on_remove=True
Ensure the operating system verifies correct operation of all security functions. Verify that "SELinux" is active and is enforcing the targeted policy with the following command: $ sudo sestatus SELinux status: enabled SELinuxfs mount: /sys/fs/selinux SELinux root directory: /etc/selinux Loaded policy name: targeted Current mode: enforcing Mode from config file: enforcing Policy MLS status: enabled Policy deny_unknown status: allowed Memory protection checking: actual (secure) Max kernel policy version: 31 If the "Loaded policy name" is not set to "targeted", this is a finding. Verify that the "/etc/selinux/config" file is configured to the "SELINUXTYPE" as "targeted": $ sudo grep -i "selinuxtype" /etc/selinux/config | grep -v '^#' SELINUXTYPE = targeted If no results are returned or "SELINUXTYPE" is not set to "targeted", this is a finding.
Configure OL 8 to verify correct operation of all security functions. Set the "SELinuxtype" to the "targeted" policy by modifying the "/etc/selinux/config" file to have the following line: SELINUXTYPE=targeted A reboot is required for the changes to take effect.
Verify there are no "shosts.equiv" files on OL 8 with the following command: $ sudo find / -name shosts.equiv If an "shosts.equiv" file is found, this is a finding.
Remove any found "shosts.equiv" files from the system. $ sudo rm /etc/ssh/shosts.equiv
Verify there are no ".shosts" files on OL 8 with the following command: $ sudo find / -name '*.shosts' If any ".shosts" files are found, this is a finding.
Remove any found ".shosts" files from the system. $ sudo rm /[path]/[to]/[file]/.shosts
Note: For OL versions 8.4 and above running with kernel FIPS mode enabled as specified by OL08-00-010020, this requirement is Not Applicable. Check that OL 8 has enabled the hardware random number generator entropy gatherer service. Verify the rngd service is enabled and active with the following commands: $ sudo systemctl is-enabled rngd enabled $ sudo systemctl is-active rngd active If the service is not "enabled" and "active", this is a finding.
Start the rngd service and enable it with the following commands: $ sudo systemctl start rngd.service $ sudo systemctl enable rngd.service
Check that OL 8 has the packages required to enabled the hardware random number generator entropy gatherer service with the following command: $ sudo yum list installed rng-tools rng-tools.x86_64 6.8-3.el8 @anaconda If the "rng-tools" package is not installed, this is a finding.
Install the packages required to enabled the hardware random number generator entropy gatherer service with the following command: $ sudo yum install rng-tools
Verify the SSH public host key files have mode "0644" or less permissive with the following command: $ sudo ls -l /etc/ssh/*.pub -rw-r--r-- 1 root wheel 618 Nov 28 06:43 ssh_host_dsa_key.pub -rw-r--r-- 1 root wheel 347 Nov 28 06:43 ssh_host_key.pub -rw-r--r-- 1 root wheel 238 Nov 28 06:43 ssh_host_rsa_key.pub If any "key.pub" file has a mode more permissive than "0644", this is a finding. Note: SSH public key files may be found in other directories on the system depending on the installation.
Change the mode of public host key files under "/etc/ssh" to "0644" with the following command: $ sudo chmod 0644 /etc/ssh/*key.pub The SSH daemon must be restarted for the changes to take effect. To restart the SSH daemon, run the following command: $ sudo systemctl restart sshd.service
Verify the SSH private host key files have mode "0640" or less permissive with the following command: $ sudo ls -alL /etc/ssh/ssh_host*key -rw-r----- 1 root wheel 668 Nov 28 06:43 ssh_host_dsa_key -rw-r----- 1 root wheel 582 Nov 28 06:43 ssh_host_key -rw-r----- 1 root wheel 887 Nov 28 06:43 ssh_host_rsa_key If any private host key file has a mode more permissive than "0640", this is a finding.
Configure the mode of SSH private host key files under "/etc/ssh" to "0640" with the following command: $ sudo chmod 0640 /etc/ssh/ssh_host*key The SSH daemon must be restarted for the changes to take effect. To restart the SSH daemon, run the following command: $ sudo systemctl restart sshd.service
Verify the SSH daemon performs strict mode checking of home directory configuration files with the following command: $ sudo /usr/sbin/sshd -dd 2>&1 | awk '/filename/ {print $4}' | tr -d '\r' | tr '\n' ' ' | xargs sudo grep -iH '^\s*strictmodes' StrictModes yes If "StrictModes" is set to "no" or is missing, or if the returned line is commented out, this is a finding. If conflicting results are returned, this is a finding.
Configure SSH to perform strict mode checking of home directory configuration files. Uncomment the "StrictModes" keyword in "/etc/ssh/sshd_config" and set the value to "yes": StrictModes yes The SSH daemon must be restarted for the changes to take effect. To restart the SSH daemon, run the following command: $ sudo systemctl restart sshd.service
Verify the SSH daemon does not allow authentication using known host’s authentication with the following command: $ sudo /usr/sbin/sshd -dd 2>&1 | awk '/filename/ {print $4}' | tr -d '\r' | tr '\n' ' ' | xargs sudo grep -iH '^\s*ignoreuserknownhosts' IgnoreUserKnownHosts yes If the value is returned as "no", the returned line is commented out, or no output is returned, this is a finding. If conflicting results are returned, this is a finding.
Configure the SSH daemon to not allow authentication using known host’s authentication. Add the following line in "/etc/ssh/sshd_config", or uncomment the line and set the value to "yes": IgnoreUserKnownHosts yes The SSH daemon must be restarted for the changes to take effect. To restart the SSH daemon, run the following command: $ sudo systemctl restart sshd.service
Verify the SSH daemon does not allow Kerberos authentication with the following command: $ sudo /usr/sbin/sshd -dd 2>&1 | awk '/filename/ {print $4}' | tr -d '\r' | tr '\n' ' ' | xargs sudo grep -iH '^\s*kerberosauthentication' KerberosAuthentication no If the value is returned as "yes", the returned line is commented out, or no output is returned or has not been documented with the information system security officer (ISSO), this is a finding. If conflicting results are returned, this is a finding.
Configure the SSH daemon to not allow Kerberos authentication. Add the following line in "/etc/ssh/sshd_config", or uncomment the line and set the value to "no": KerberosAuthentication no The SSH daemon must be restarted for the changes to take effect. To restart the SSH daemon, run the following command: $ sudo systemctl restart sshd.service
Verify the SSH daemon does not allow GSSAPI authentication with the following command: $ sudo /usr/sbin/sshd -dd 2>&1 | awk '/filename/ {print $4}' | tr -d '\r' | tr '\n' ' ' | xargs sudo grep -iH '^\s*gssapiauthentication' GSSAPIAuthentication no If the value is returned as "yes", the returned line is commented out, or no output is returned or has not been documented with the information system security officer (ISSO), this is a finding. If conflicting results are returned, this is a finding.
Configure the SSH daemon to not allow GSSAPI authentication. Add the following line in "/etc/ssh/sshd_config", or uncomment the line and set the value to "no": GSSAPIAuthentication no The SSH daemon must be restarted for the changes to take effect. To restart the SSH daemon, run the following command: $ sudo systemctl restart sshd.service
Verify that a separate file system has been created for "/var" with the following command: $ sudo grep /var /etc/fstab /dev/mapper/... /var xfs defaults,nodev 0 0 If a separate entry for "/var" is not in use, this is a finding.
Migrate the "/var" path onto a separate file system.
Verify that a separate file system has been created for "/var/log". Check that a file system has been created for "/var/log" with the following command: $ sudo grep /var/log /etc/fstab /dev/mapper/... /var/log xfs defaults,nodev,noexec,nosuid 0 0 If a separate entry for "/var/log" is not in use, this is a finding.
Migrate the "/var/log" path onto a separate file system.
Verify that a separate file system/partition has been created for the system audit data path with the following command: Note: "/var/log/audit" is used as the example as it is a common location. $ sudo grep /var/log/audit /etc/fstab UUID=3645951a /var/log/audit ext4 defaults 1 2 If an entry for "/var/log/audit" does not exist, ask the System Administrator if the system audit logs are being written to a different file system/partition on the system and then grep for that file system/partition. If a separate file system/partition does not exist for the system audit data path, this is a finding.
Migrate the system audit data path onto a separate file system.
The use of separate file systems for different paths can protect the system from failures resulting from a file system becoming full or failing. Check Text: Verify that a separate file system/partition has been created for non-privileged local interactive user home directories. $ sudo grep /tmp /etc/fstab /dev/mapper/ol-tmp /tmp xfs defaults,nodev,nosuid,noexec 0 0 If a separate entry for the file system/partition "/tmp" does not exist, this is a finding.
Migrate the "/tmp" directory onto a separate file system/partition.
Verify that a separate file system has been created for "/var/tmp". Check that a file system has been created for "/var/tmp" with the following command: $ sudo grep /var/tmp /etc/fstab /dev/mapper/... /var/tmp xfs defaults,nodev,noexec,nosuid 0 0 If a separate entry for "/var/tmp" is not in use, this is a finding.
Migrate the "/var/tmp" path onto a separate file system.
Verify remote access using SSH prevents users from logging on directly as "root" with the following command: $ sudo /usr/sbin/sshd -dd 2>&1 | awk '/filename/ {print $4}' | tr -d '\r' | tr '\n' ' ' | xargs sudo grep -iH '^\s*permitrootlogin' PermitRootLogin no If the "PermitRootLogin" keyword is set to "yes", is missing, or is commented out, this is a finding. If conflicting results are returned, this is a finding.
Configure OL 8 to stop users from logging on remotely as the "root" user via SSH. Edit the appropriate "/etc/ssh/sshd_config" file to uncomment or add the line for the "PermitRootLogin" keyword and set its value to "no": PermitRootLogin no The SSH daemon must be restarted for the changes to take effect. To restart the SSH daemon, run the following command: $ sudo systemctl restart sshd.service
Verify the rsyslog service is enabled and active with the following commands: $ sudo systemctl is-enabled rsyslog enabled $ sudo systemctl is-active rsyslog active If the service is not enabled and active, this is a finding.
Start and enable the rsyslog service with the following commands: $ sudo systemctl start rsyslog.service $ sudo systemctl enable rsyslog.service
Verify that file systems containing user home directories are mounted with the "nosuid" option. Find the file system(s) that contain the user home directories with the following command: $ sudo awk -F: '($3>=1000)&&($1!="nobody"){print $1,$3,$6}' /etc/passwd smithj 1001 /home/smithj robinst 1002 /home/robinst Check the file systems that are mounted at boot time with the following command: $ sudo more /etc/fstab UUID=a411dc99-f2a1-4c87-9e05-184977be8539 /home ext4 rw,relatime,discard,data=ordered,nosuid,nodev,noexec 0 2 If a file system found in "/etc/fstab" refers to the user home directory file system and it does not have the "nosuid" option set, this is a finding.
Configure "/etc/fstab" to use the "nosuid" option on file systems that contain user home directories for interactive users.
For systems that use UEFI, this is Not Applicable. Verify the /boot directory is mounted with the "nosuid" option with the following command: $ sudo mount | grep '\s/boot\s' /dev/sda1 on /boot type xfs (rw,nosuid,relatime,seclabe,attr2,inode64,noquota) If the /boot file system does not have the "nosuid" option set, this is a finding.
Configure the "/etc/fstab" to use the "nosuid" option on the /boot directory.
For systems that use BIOS, this is Not Applicable. Verify the /boot/efi directory is mounted with the "nosuid" option with the following command: $ sudo mount | grep '\s/boot/efi\s' /dev/sda1 on /boot/efi type vfat (rw,nosuid,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=winnt,errors=remount-ro) If the /boot/efi file system does not have the "nosuid" option set, this is a finding.
Configure the "/etc/fstab" to use the "nosuid" option on the /boot/efi directory.
Verify all non-root local partitions are mounted with the "nodev" option with the following command: $ sudo mount | grep '^/dev\S* on /\S' | grep --invert-match 'nodev' If any output is produced, this is a finding.
Configure the "/etc/fstab" to use the "nodev" option on all non-root local partitions.
Verify that file systems containing user home directories are mounted with the "noexec" option. Find the file system(s) that contain the user home directories with the following command: $ sudo awk -F: '($3>=1000)&&($1!="nobody"){print $1,$3,$6}' /etc/passwd smithj 1001 /home/smithj robinst 1002 /home/robinst Check the file systems that are mounted at boot time with the following command: $ sudo more /etc/fstab UUID=a411dc99-f2a1-4c87-9e05-184977be8539 /home ext4 rw,relatime,discard,data=ordered,nosuid,nodev,noexec 0 2 If a file system found in "/etc/fstab" refers to the user home directory file system and it does not have the "noexec" option set, this is a finding.
Configure the "/etc/fstab" to use the "noexec" option on file systems that contain user home directories for interactive users.
Verify that file systems used for removable media are mounted with the "nodev" option with the following command: $ sudo more /etc/fstab UUID=2bc871e4-e2a3-4f29-9ece-3be60c835222 /mnt/usbflash vfat noauto,owner,ro,nosuid,nodev,noexec 0 0 If a file system found in "/etc/fstab" refers to removable media and it does not have the "nodev" option set, this is a finding.
Configure the "/etc/fstab" to use the "nodev" option on file systems that are associated with removable media.
Verify that file systems used for removable media are mounted with the "noexec" option with the following command: $ sudo more /etc/fstab UUID=2bc871e4-e2a3-4f29-9ece-3be60c835222 /mnt/usbflash vfat noauto,owner,ro,nosuid,nodev,noexec 0 0 If a file system found in "/etc/fstab" refers to removable media and it does not have the "noexec" option set, this is a finding.
Configure the "/etc/fstab" to use the "noexec" option on file systems that are associated with removable media.
Verify that file systems used for removable media are mounted with the "nosuid" option with the following command: $ sudo more /etc/fstab UUID=2bc871e4-e2a3-4f29-9ece-3be60c835222 /mnt/usbflash vfat noauto,owner,ro,nosuid,nodev,noexec 0 0 If a file system found in "/etc/fstab" refers to removable media and it does not have the "nosuid" option set, this is a finding.
Configure the "/etc/fstab" to use the "nosuid" option on file systems that are associated with removable media.
Verify that file systems being imported via NFS are mounted with the "noexec" option with the following command: $ sudo grep nfs /etc/fstab | grep noexec UUID=e06097bb-cfcd-437b-9e4d-a691f5662a7d /store nfs rw,nosuid,nodev,noexec 0 0 If a file system found in "/etc/fstab" refers to NFS and it does not have the "noexec" option set, this is a finding.
Configure the "/etc/fstab" to use the "noexec" option on file systems that are being imported via NFS.
Verify that file systems being imported via NFS are mounted with the "nodev" option with the following command: $ sudo grep nfs /etc/fstab | grep nodev UUID=e06097bb-cfcd-437b-9e4d-a691f5662a7d /store nfs rw,nosuid,nodev,noexec 0 0 If a file system found in "/etc/fstab" refers to NFS and it does not have the "nodev" option set, this is a finding.
Configure the "/etc/fstab" to use the "nodev" option on file systems that are being imported via NFS.
Verify that file systems being imported via NFS are mounted with the "nosuid" option with the following command: $ sudo grep nfs /etc/fstab | grep nosuid UUID=e06097bb-cfcd-437b-9e4d-a691f5662a7d /store nfs rw,nosuid,nodev,noexec 0 0 If a file system found in "/etc/fstab" refers to NFS and it does not have the "nosuid" option set, this is a finding.
Configure the "/etc/fstab" to use the "nosuid" option on file systems that are being imported via NFS.
Verify that local initialization files do not execute world-writable programs. Check the system for world-writable files. The following command will discover and print world-writable files. Run it once for each local partition [PART]: $ sudo find [PART] -xdev -type f -perm -0002 -print For all files listed, check for their presence in the local initialization files with the following commands: Note: The example will be for a system that is configured to create users' home directories in the "/home" directory. $ sudo grep <file> /home/*/.* If any local initialization files are found to reference world-writable files, this is a finding.
Set the mode on files being executed by the local initialization files with the following command: $ sudo chmod 0755 <file>
Verify that kernel core dumps are disabled unless needed with the following command: $ sudo systemctl status kdump.service kdump.service - Crash recovery kernel arming Loaded: loaded (/usr/lib/systemd/system/kdump.service; disabled; vendor preset: enabled) Active: failed (Result: exit-code)since Mon 2020-05-04 16:08:09 EDT; 3min ago Main PID: 1130 (code=exited, status=0/FAILURE) If the "kdump" service is active, ask the System Administrator if the use of the service is required and documented with the Information System Security Officer (ISSO). If the service is active and is not documented, this is a finding.
If kernel core dumps are not required, disable the "kdump" service with the following command: $ sudo systemctl disable kdump.service If kernel core dumps are required, document the need with the ISSO.
Verify that OL 8 disables storing core dumps with the following commands: $ sudo sysctl kernel.core_pattern kernel.core_pattern = |/bin/false If the returned line does not have a value of "|/bin/false", or a line is not returned and the need for core dumps is not documented with the Information System Security Officer (ISSO) as an operational requirement, this is a finding. Check that the configuration files are present to enable this kernel parameter: $ sudo grep -r kernel.core_pattern /run/sysctl.d/*.conf /usr/local/lib/sysctl.d/*.conf /usr/lib/sysctl.d/*.conf /lib/sysctl.d/*.conf /etc/sysctl.conf /etc/sysctl.d/*.conf /etc/sysctl.d/99-sysctl.conf:kernel.core_pattern = |/bin/false If "kernel.core_pattern" is not set to "|/bin/false", is missing or commented out, this is a finding. If conflicting results are returned, this is a finding.
Configure OL 8 to disable storing core dumps by adding the following line to a file in the "/etc/sysctl.d" directory: kernel.core_pattern = |/bin/false Remove any configurations that conflict with the above from the following locations: /run/sysctl.d/*.conf /usr/local/lib/sysctl.d/*.conf /usr/lib/sysctl.d/*.conf /lib/sysctl.d/*.conf /etc/sysctl.conf /etc/sysctl.d/*.conf The system configuration files must be reloaded for the changes to take effect. To reload the contents of the files, run the following command: $ sudo sysctl --system
Verify OL 8 is not configured to acquire, save, or process core dumps with the following command: $ sudo systemctl status systemd-coredump.socket systemd-coredump.socket Loaded: masked (Reason: Unit systemd-coredump.socket is masked.) Active: inactive (dead) If the "systemd-coredump.socket" is loaded and not masked and the need for core dumps is not documented with the Information System Security Officer (ISSO) as an operational requirement, this is a finding.
Configure the system to disable the "systemd-coredump.socket" with the following commands: $ sudo systemctl disable --now systemd-coredump.socket $ sudo systemctl mask systemd-coredump.socket Created symlink /etc/systemd/system/systemd-coredump.socket -> /dev/null
Verify the operating system disables core dumps for all users with the following command: $ sudo grep -r -s '^[^#].*core' /etc/security/limits.conf /etc/security/limits.d/*.conf * hard core 0 This can be set as a global domain (with the * wildcard) but may be set differently for multiple domains. If the "core" item is missing or commented out or the value is anything other than "0", and the need for core dumps is not documented with the Information System Security Officer (ISSO) as an operational requirement for all domains that have the "core" item assigned, this is a finding.
Configure OL 8 to disable core dumps for all users. Add the following line to the top of "/etc/security/limits.conf" or in a ".conf" file defined in "/etc/security/limits.d/": * hard core 0
Verify the operating system disables storing core dumps for all users with the following command: $ sudo grep -i storage /etc/systemd/coredump.conf Storage=none If the "Storage" item is missing or commented out or the value is anything other than "none", and the need for core dumps is not documented with the Information System Security Officer (ISSO) as an operational requirement for all domains that have the "core" item assigned, this is a finding.
Configure OL 8 to disable storing core dumps for all users. Add or modify the following line in "/etc/systemd/coredump.conf": Storage=none
Verify the operating system disables core dump backtraces by issuing the following command: $ sudo grep -i ProcessSizeMax /etc/systemd/coredump.conf ProcessSizeMax=0 If the "ProcessSizeMax" item is missing or commented out or the value is anything other than "0", and the need for core dumps is not documented with the Information System Security Officer (ISSO) as an operational requirement for all domains that have the "core" item assigned, this is a finding.
Configure OL 8 to disable core dump backtraces. Add or modify the following line in "/etc/systemd/coredump.conf": ProcessSizeMax=0
Determine whether the system is using local or DNS name resolution with the following command: $ sudo grep hosts /etc/nsswitch.conf hosts: files dns If the DNS entry is missing from the host's line in the "/etc/nsswitch.conf" file, the "/etc/resolv.conf" file must be empty. Verify the "/etc/resolv.conf" file is empty with the following command: $ sudo ls -al /etc/resolv.conf -rw-r--r-- 1 root root 0 Aug 19 08:31 resolv.conf If local host authentication is being used and the "/etc/resolv.conf" file is not empty, this is a finding. If the DNS entry is found on the host's line of the "/etc/nsswitch.conf" file, verify the operating system is configured to use two or more name servers for DNS resolution. Determine the name servers used by the system with the following command: $ sudo grep nameserver /etc/resolv.conf nameserver 192.168.1.2 nameserver 192.168.1.3 If fewer than two lines are returned that are not commented out, this is a finding.
Configure OL 8 to use two or more name servers for DNS resolution. By default, "NetworkManager" on OL 8 dynamically updates the "/etc/resolv.conf" file with the DNS settings from active "NetworkManager" connection profiles. However, this feature can be disabled to allow manual configurations. If manually configuring DNS, edit the "/etc/resolv.conf" file to uncomment or add the two or more "nameserver" option lines with the IP address of local authoritative name servers. If local host resolution is being performed, the "/etc/resolv.conf" file must be empty. An empty "/etc/resolv.conf" file can be created as follows: $ sudo echo -n > /etc/resolv.conf
Verify that all local interactive user initialization files' executable search path statements do not contain statements that will reference a working directory other than the users' home directory with the following commands: Note: The example will be for the "smithj" user, which has a home directory of "/home/smithj". $ sudo grep -i path /home/smithj/.* /home/smithj/.bash_profile:PATH=$PATH:$HOME/.local/bin:$HOME/bin /home/smithj/.bash_profile:export PATH If any local interactive user initialization files have executable search path statements that include directories outside of their home directory, this is a finding.
Edit the local interactive user initialization files to change any PATH variable statements that reference directories other than their home directory. If a local interactive user requires path variables to reference a directory owned by the application, it must be documented with the ISSO.
The following command will discover and print world-writable directories that are not owned by a system account, given the assumption that only system accounts have a UID lower than 1000. Run it once for each local partition [PART]: $ sudo find [PART] -xdev -type d -perm -0002 -uid +999 -print If there is output, this is a finding.
Investigate any world-writable directories that are not owned by a system account and then delete the files or assign them to an appropriate group.
The following command will discover and print world-writable directories that are not group-owned by a system account, given the assumption that only system accounts have a gid lower than 1000. Run it once for each local partition [PART]: $ sudo find [PART] -xdev -type d -perm -0002 -gid +999 -print If there is output, this is a finding.
Investigate any world-writable directories that are not group-owned by a system account and then delete the files or assign them to an appropriate group.
Verify local interactive users on OL 8 have a home directory assigned with the following command: $ sudo pwck -r user 'lp': directory '/var/spool/lpd' does not exist user 'news': directory '/var/spool/news' does not exist user 'uucp': directory '/var/spool/uucp' does not exist user 'www-data': directory '/var/www' does not exist Ask the System Administrator (SA) if any users found without home directories are local interactive users. If the SA is unable to provide a response, check for users with a User Identifier (UID) of 1000 or greater with the following command: $ sudo awk -F: '($3>=1000)&&($7 !~ /nologin/){print $1, $3, $6}' /etc/passwd If any interactive users do not have a home directory assigned, this is a finding.
Assign home directories to all local interactive users on OL 8 that currently do not have a home directory assigned.
Verify the assigned home directory of all local interactive users has a mode of "0750" or less permissive with the following command. Note: This may miss interactive users that have been assigned a privileged User Identifier (UID). Evidence of interactive use may be obtained from a number of log files containing system logon information. $ sudo ls -ld $(awk -F: '($3>=1000)&&($1!="nobody"){print $6}' /etc/passwd) drwxr-x--- 2 smithj admin 4096 Jun 5 12:41 smithj If home directories of interactive users referenced in "/etc/passwd" do not have a mode of "0750" or less permissive, this is a finding.
Change the mode of interactive users' home directories to "0750" using the following command. Note: The example will be for the user "smithj". $ sudo chmod 0750 /home/smithj
Verify all files and directories contained in a local interactive user home directory, excluding local initialization files, have a mode of "0750". Files that begin with a "." are excluded from this requirement. Note: The example will be for the user "smithj", who has a home directory of "/home/smithj". $ sudo ls -lLR /home/smithj -rwxr-x--- 1 smithj smithj 18 Mar 5 17:06 file1 -rwxr----- 1 smithj smithj 193 Mar 5 17:06 file2 -rw-r-x--- 1 smithj smithj 231 Mar 5 17:06 file3 If any files or directories are found with a mode more permissive than "0750", this is a finding.
Set the mode on files and directories in the local interactive user home directory with the following command: Note: The example will be for the user smithj, who has a home directory of "/home/smithj" and is a member of the users group. $ sudo chmod 0750 /home/smithj/<file or directory>
Verify the assigned home directory of all local interactive users is group-owned by that user’s primary GID with the following command. Note: This may miss local interactive users that have been assigned a privileged User Identifier (UID). Evidence of interactive use may be obtained from a number of log files containing system logon information. The returned directory "/home/smithj" is used as an example. $ sudo ls -ld $(awk -F: '($3>=1000)&&($1!="nobody"){print $6}' /etc/passwd) drwxr-x--- 2 smithj admin 4096 Jun 5 12:41 smithj Check the user's primary group with the following command: $ sudo grep $(grep smithj /etc/passwd | awk -F: '{print $4}') /etc/group admin:x:250:smithj,jonesj,jacksons If the user home directory referenced in "/etc/passwd" is not group-owned by that user’s primary GID, this is a finding.
Change the group owner of a local interactive user’s home directory to the group found in "/etc/passwd" using the following command. Note: The example will be for the user "smithj", who has a home directory of "/home/smithj" and has a primary group of users. $ sudo chgrp users /home/smithj
Verify all files and directories in a local interactive user home directory are group-owned by a group that the user is a member. Check the group owner of all files and directories in a local interactive user's home directory with the following command: Note: The example will be for the user "smithj", who has a home directory of "/home/smithj". $ sudo ls -lLR /<home directory>/<users home directory>/ -rw-r--r-- 1 smithj smithj 18 Mar 5 17:06 file1 -rw-r--r-- 1 smithj smithj 193 Mar 5 17:06 file2 -rw-r--r-- 1 smithj sa 231 Mar 5 17:06 file3 If any files found with a group-owner different from the home directory user private group, determine if the user is a member of that group with the following command: $ sudo grep smithj /etc/group sa:x:100:juan,shelley,bob,smithj smithj:x:521:smithj If any files or directories are group owned by a group that the directory owner is not a member of, this is a finding.
Change the group of a local interactive user's files and directories to a group that the interactive user is a member. To change the group owner of a local interactive user's files and directories, use the following command: Note: The example will be for the user smithj, who has a home directory of "/home/smithj" and is a member of the users group. $ sudo chgrp smithj /home/smithj/<file or directory>
Verify that the assigned home directory of all local interactive users on OL 8 exists with the following command: $ sudo ls -ld $(awk -F: '($3>=1000)&&($1!="nobody"){print $6}' /etc/passwd) drwxr-xr-x 2 smithj admin 4096 Jun 5 12:41 smithj Note: This may miss interactive users that have been assigned a privileged User ID (UID). Evidence of interactive use may be obtained from a number of log files containing system logon information. Check that all referenced home directories exist with the following command: $ sudo pwck -r user 'smithj': directory '/home/smithj' does not exist If any home directories referenced in "/etc/passwd" are returned as not defined, this is a finding.
Create home directories to all local interactive users that currently do not have a home directory assigned. Use the following commands to create the user home directory assigned in "/etc/ passwd". Note: The example will be for the user smithj, who has a home directory of "/home/smithj", a UID of "smithj", and a Group Identifier (GID) of "users assigned" in "/etc/passwd". $ sudo mkdir /home/smithj $ sudo chown smithj /home/smithj $ sudo chgrp users /home/smithj $ sudo chmod 0750 /home/smithj
Verify all local interactive users on OL 8 are assigned a home directory upon creation with the following command: $ sudo grep -i create_home /etc/login.defs CREATE_HOME yes If the value for "CREATE_HOME" parameter is not set to "yes", the line is missing, or the line is commented out, this is a finding.
Configure OL 8 to assign home directories to all new local interactive users by setting the "CREATE_HOME" parameter in "/etc/login.defs" to "yes" as follows. CREATE_HOME yes
Verify that all local initialization files have a mode of "0740" or less permissive with the following command: Note: The example will be for the "smithj" user, who has a home directory of "/home/smithj". $ sudo ls -al /home/smithj/.* | more -rwxr----- 1 smithj users 896 Mar 10 2011 .profile -rwxr----- 1 smithj users 497 Jan 6 2007 .login -rwxr----- 1 smithj users 886 Jan 6 2007 .something If any local initialization files have a mode more permissive than "0740", this is a finding.
Set the mode of the local initialization files to "0740" with the following command: Note: The example will be for the smithj user, who has a home directory of "/home/smithj". $ sudo chmod 0740 /home/smithj/.<INIT_FILE>
Verify all files and directories on OL 8 have a valid owner with the following command: $ sudo find / -nouser If any files on the system do not have an assigned owner, this is a finding.
Either remove all files and directories from the system that do not have a valid user or assign a valid user to all unowned files and directories on OL 8 with the "chown" command: $ sudo chown <user> <file>
Verify all files and directories on OL 8 have a valid group with the following command: $ sudo find / -nogroup If any files on the system do not have an assigned group, this is a finding.
Either remove all files and directories from OL 8 that do not have a valid group, or assign a valid group to all files and directories on the system with the "chgrp" command: $ sudo chgrp <group> <file>
Verify that a separate file system has been created for non-privileged local interactive user home directories. Check the home directory assignment for all non-privileged users, users with a User Identifier (UID) greater than 1000, on the system with the following command: $ sudo awk -F: '($3>=1000)&&($1!="nobody"){print $1,$3,$6}' /etc/passwd doej 1001 /home/doej publicj 1002 /home/publicj smithj 1003 /home/smithj The output of the command will give the directory that contains the home directories for the nonprivileged users on the system (in this example, "/home") and users’ shell. All accounts with a valid shell (such as "/bin/bash") are considered interactive users. Check that a file system has been created for the nonprivileged interactive users with the following command. Note: The partition of "/home" is used in the example. $ sudo grep /home /etc/fstab /dev/mapper/... /home xfs defaults,noexec,nosuid,nodev 0 0 If a separate entry for the file system that contains the nonprivileged interactive users' home directories does not exist, this is a finding.
Migrate the "/home" directory onto a separate file system.
Note: This requirement assumes the use of the OL 8 default graphical user interface, Gnome Shell. If the system does not have any graphical user interface installed, this requirement is Not Applicable. Verify the operating system does not allow an unattended or automatic logon to the system via a graphical user interface. Check for the value of "AutomaticLoginEnable" in the "/etc/gdm/custom.conf" file with the following command: $ sudo grep -i automaticloginenable /etc/gdm/custom.conf AutomaticLoginEnable=false If the value of "AutomaticLoginEnable" is not set to "false", this is a finding.
Configure OL 8 to not allow an unattended or automatic logon to the system via a graphical user interface. Add or edit the line for the "AutomaticLoginEnable" parameter in the [daemon] section of the "/etc/gdm/custom.conf" file to "false": [daemon] AutomaticLoginEnable=false
Verify that unattended or automatic login via SSH is disabled with the following command: $ sudo /usr/sbin/sshd -dd 2>&1 | awk '/filename/ {print $4}' | tr -d '\r' | tr '\n' ' ' | xargs sudo grep -iH '^\s*permituserenvironment' PermitUserEnvironment no If "PermitUserEnvironment" is set to "yes", is missing completely, or is commented out, this is a finding. If conflicting results are returned, this is a finding.
Configure OL 8 to allow the SSH daemon to not allow unattended or automatic login to the system. Add or edit the following line in the "/etc/ssh/sshd_config" file: PermitUserEnvironment no The SSH daemon must be restarted for the changes to take effect. To restart the SSH daemon, run the following command: $ sudo systemctl restart sshd.service
Verify that temporary accounts have been provisioned with an expiration date of 72 hours. For every existing temporary account, run the following command to obtain its account expiration information. $ sudo chage -l system_account_name Verify each of these accounts has an expiration date set within 72 hours. If any temporary accounts have no expiration date set or do not expire within 72 hours, this is a finding.
If a temporary account must be created, configure the system to terminate the account after a 72-hour time period with the following command to set an expiration date on it. Substitute "system_account_name" with the account to be created. $ sudo chage -E `date -d "+3 days" +%Y-%m-%d` system_account_name
Verify the system locks an account after three unsuccessful logon attempts with the following commands. Note: If the System Administrator demonstrates the use of an approved centralized account management method that locks an account after three unsuccessful logon attempts within a period of 15 minutes, this requirement is not applicable. Note: This check applies to OL versions 8.0 and 8.1. If the system is OL version 8.2 or newer, this check is not applicable. $ sudo grep pam_faillock.so /etc/pam.d/password-auth auth required pam_faillock.so preauth dir=/var/log/faillock silent audit deny=3 even_deny_root fail_interval=900 unlock_time=0 auth required pam_faillock.so authfail dir=/var/log/faillock unlock_time=0 account required pam_faillock.so If the "deny" option is not set to "3" or less (but not "0") on the "preauth" line with the "pam_faillock.so" module or is missing from this line, this is a finding. If any line referencing the "pam_faillock.so" module is commented out, this is a finding. $ sudo grep pam_faillock.so /etc/pam.d/system-auth auth required pam_faillock.so preauth dir=/var/log/faillock silent audit deny=3 even_deny_root fail_interval=900 unlock_time=0 auth required pam_faillock.so authfail dir=/var/log/faillock unlock_time=0 account required pam_faillock.so If the "deny" option is not set to "3" or less (but not "0") on the "preauth" line with the "pam_faillock.so" module or is missing from this line, this is a finding. If any line referencing the "pam_faillock.so" module is commented out, this is a finding.
Add/modify the appropriate sections of the "/etc/pam.d/system-auth" and "/etc/pam.d/password-auth" files to match the following lines: auth required pam_faillock.so preauth dir=/var/log/faillock silent audit deny=3 even_deny_root fail_interval=900 unlock_time=0 auth required pam_faillock.so authfail dir=/var/log/faillock unlock_time=0 account required pam_faillock.so The "sssd" service must be restarted for the changes to take effect. To restart the "sssd" service, run the following command: $ sudo systemctl restart sssd.service
Note: This check applies to OL versions 8.2 or newer. If the system is OL version 8.0 or 8.1, this check is not applicable. Verify the "/etc/security/faillock.conf" file is configured to lock an account after three unsuccessful logon attempts: $ sudo grep 'deny =' /etc/security/faillock.conf deny = 3 If the "deny" option is not set to "3" or less (but not "0") or is missing or commented out, this is a finding.
Configure OL 8 to lock an account when three unsuccessful logon attempts occur. Add/modify the "/etc/security/faillock.conf" file to match the following line: deny = 3
Verify the system locks an account after three unsuccessful logon attempts within a period of 15 minutes with the following commands. Note: If the System Administrator demonstrates the use of an approved centralized account management method that locks an account after three unsuccessful logon attempts within a period of 15 minutes, this requirement is not applicable. Note: This check applies to OL versions 8.0 and 8.1. If the system is OL version 8.2 or newer, this check is not applicable. $ sudo grep pam_faillock.so /etc/pam.d/password-auth auth required pam_faillock.so preauth dir=/var/log/faillock silent audit deny=3 even_deny_root fail_interval=900 unlock_time=0 auth required pam_faillock.so authfail dir=/var/log/faillock unlock_time=0 account required pam_faillock.so If the "fail_interval" option is not set to "900" or more on the "preauth" lines with the "pam_faillock.so" module or is missing from this line, this is a finding. $ sudo grep pam_faillock.so /etc/pam.d/system-auth auth required pam_faillock.so preauth dir=/var/log/faillock silent audit deny=3 even_deny_root fail_interval=900 unlock_time=0 auth required pam_faillock.so authfail dir=/var/log/faillock unlock_time=0 account required pam_faillock.so If the "fail_interval" option is not set to "900" or more on the "preauth" lines with the "pam_faillock.so" module or is missing from this line, this is a finding.
Configure the operating system to lock an account when three unsuccessful logon attempts occur in 15 minutes. Add/modify the appropriate sections of the "/etc/pam.d/system-auth" and "/etc/pam.d/password-auth" files to match the following lines: auth required pam_faillock.so preauth dir=/var/log/faillock silent audit deny=3 even_deny_root fail_interval=900 unlock_time=0 auth required pam_faillock.so authfail dir=/var/log/faillock unlock_time=0 account required pam_faillock.so The "sssd" service must be restarted for the changes to take effect. To restart the "sssd" service, run the following command: $ sudo systemctl restart sssd.service
Note: This check applies to OL versions 8.2 or newer. If the system is OL version 8.0 or 8.1, this check is not applicable. Verify the "/etc/security/faillock.conf" file is configured to lock an account after three unsuccessful logon attempts within 15 minutes: $ sudo grep 'fail_interval =' /etc/security/faillock.conf fail_interval = 900 If the "fail_interval" option is not set to "900" or more or is missing or commented out, this is a finding.
Configure OL 8 to lock an account when three unsuccessful logon attempts occur. Add/modify the "/etc/security/faillock.conf" file to match the following line: fail_interval = 900
Verify the system locks an account after three unsuccessful logon attempts within a period of 15 minutes until released by an administrator with the following commands. Note: If the System Administrator demonstrates the use of an approved centralized account management method that locks an account after three unsuccessful logon attempts within a period of 15 minutes, this requirement is not applicable. Note: This check applies to OL versions 8.0 and 8.1. If the system is OL version 8.2 or newer, this check is not applicable. $ sudo grep pam_faillock.so /etc/pam.d/password-auth auth required pam_faillock.so preauth dir=/var/log/faillock silent audit deny=3 even_deny_root fail_interval=900 unlock_time=0 auth required pam_faillock.so authfail dir=/var/log/faillock unlock_time=0 account required pam_faillock.so If the "unlock_time" option is not set to "0" on the "preauth" and "authfail" lines with the "pam_faillock.so" module or is missing from these lines, this is a finding. $ sudo grep pam_faillock.so /etc/pam.d/system-auth auth required pam_faillock.so preauth dir=/var/log/faillock silent audit deny=3 even_deny_root fail_interval=900 unlock_time=0 auth required pam_faillock.so authfail dir=/var/log/faillock unlock_time=0 account required pam_faillock.so If the "unlock_time" option is not set to "0" on the "preauth" and "authfail" lines with the "pam_faillock.so" module or is missing from these lines, this is a finding.
Configure the operating system to lock an account until released by an administrator when three unsuccessful logon attempts occur in 15 minutes. Add/modify the appropriate sections of the "/etc/pam.d/system-auth" and "/etc/pam.d/password-auth" files to match the following lines: auth required pam_faillock.so preauth dir=/var/log/faillock silent audit deny=3 even_deny_root fail_interval=900 unlock_time=0 auth required pam_faillock.so authfail dir=/var/log/faillock unlock_time=0 account required pam_faillock.so The "sssd" service must be restarted for the changes to take effect. To restart the "sssd" service, run the following command: $ sudo systemctl restart sssd.service
Note: This check applies to OL versions 8.2 or newer. If the system is OL version 8.0 or 8.1, this check is not applicable. Verify the "/etc/security/faillock.conf" file is configured to lock an account until released by an administrator after three unsuccessful logon attempts: $ sudo grep 'unlock_time =' /etc/security/faillock.conf unlock_time = 0 If the "unlock_time" option is not set to "0" or is missing or commented out, this is a finding.
Configure OL 8 to lock an account until released by an administrator when three unsuccessful logon attempts occur in 15 minutes. Add/modify the "/etc/security/faillock.conf" file to match the following line: unlock_time = 0
Verify the faillock directory contents persist after a reboot with the following commands: Note: If the System Administrator demonstrates the use of an approved centralized account management method that locks an account after three unsuccessful logon attempts within a period of 15 minutes, this requirement is not applicable. Note: This check applies to OL versions 8.0 and 8.1. If the system is OL version 8.2 or newer, this check is not applicable. $ sudo grep pam_faillock.so /etc/pam.d/password-auth auth required pam_faillock.so preauth dir=/var/log/faillock silent audit deny=3 even_deny_root fail_interval=900 unlock_time=0 auth required pam_faillock.so authfail dir=/var/log/faillock unlock_time=0 account required pam_faillock.so If the "dir" option is not set to a non-default documented tally log directory on the "preauth" and "authfail" lines with the "pam_faillock.so" module or is missing from these lines, this is a finding. $ sudo grep pam_faillock.so /etc/pam.d/system-auth auth required pam_faillock.so preauth dir=/var/log/faillock silent audit deny=3 even_deny_root fail_interval=900 unlock_time=0 auth required pam_faillock.so authfail dir=/var/log/faillock unlock_time=0 account required pam_faillock.so If the "dir" option is not set to a non-default documented tally log directory on the "preauth" and "authfail" lines with the "pam_faillock.so" module or is missing from these lines, this is a finding.
Configure the operating system maintain the contents of the faillock directory after a reboot. Add/modify the appropriate sections of the "/etc/pam.d/system-auth" and "/etc/pam.d/password-auth" files to match the following lines. Note: Using the default faillock directory of "/var/run/faillock" will result in the contents being cleared in the event of a reboot. auth required pam_faillock.so preauth dir=/var/log/faillock silent audit deny=3 even_deny_root fail_interval=900 unlock_time=0 auth required pam_faillock.so authfail dir=/var/log/faillock unlock_time=0 account required pam_faillock.so The "sssd" service must be restarted for the changes to take effect. To restart the "sssd" service, run the following command: $ sudo systemctl restart sssd.service
Note: This check applies to OL versions 8.2 or newer. If the system is OL version 8.0 or 8.1, this check is not applicable. Verify the "/etc/security/faillock.conf" file is configured use a non-default faillock directory to ensure contents persist after reboot: $ sudo grep 'dir =' /etc/security/faillock.conf dir = /var/log/faillock If the "dir" option is not set to a non-default documented tally log directory or is missing or commented out, this is a finding.
Configure OL 8 to maintain the contents of the faillock directory after a reboot. Add/modify the "/etc/security/faillock.conf" file to match the following line: dir = /var/log/faillock
Verify the system prevents informative messages from being presented to the user pertaining to logon information with the following commands. Note: If the System Administrator demonstrates the use of an approved centralized account management method that locks an account after three unsuccessful logon attempts within a period of 15 minutes, this requirement is not applicable. Note: This check applies to OL versions 8.0 and 8.1. If the system is OL version 8.2 or newer, this check is not applicable. $ sudo grep pam_faillock.so /etc/pam.d/password-auth auth required pam_faillock.so preauth dir=/var/log/faillock silent audit deny=3 even_deny_root fail_interval=900 unlock_time=0 auth required pam_faillock.so authfail dir=/var/log/faillock unlock_time=0 account required pam_faillock.so If the "silent" option is missing from the "preauth" line with the "pam_faillock.so" module, this is a finding. $ sudo grep pam_faillock.so /etc/pam.d/system-auth auth required pam_faillock.so preauth dir=/var/log/faillock silent audit deny=3 even_deny_root fail_interval=900 unlock_time=0 auth required pam_faillock.so authfail dir=/var/log/faillock unlock_time=0 account required pam_faillock.so If the "silent" option is missing from the "preauth" line with the "pam_faillock.so" module, this is a finding.
Configure the operating system to prevent informative messages from being presented at logon attempts. Add/modify the appropriate sections of the "/etc/pam.d/system-auth" and "/etc/pam.d/password-auth" files to match the following lines: auth required pam_faillock.so preauth dir=/var/log/faillock silent audit deny=3 even_deny_root fail_interval=900 unlock_time=0 auth required pam_faillock.so authfail dir=/var/log/faillock unlock_time=0 account required pam_faillock.so The "sssd" service must be restarted for the changes to take effect. To restart the "sssd" service, run the following command: $ sudo systemctl restart sssd.service
Note: This check applies to OL versions 8.2 or newer. If the system is OL version 8.0 or 8.1, this check is not applicable. Verify the "/etc/security/faillock.conf" file is configured to prevent informative messages from being presented at logon attempts: $ sudo grep silent /etc/security/faillock.conf silent If the "silent" option is not set or is missing or commented out, this is a finding.
Configure the operating system to prevent informative messages from being presented at logon attempts. Add/modify the "/etc/security/faillock.conf" file to match the following line: silent
Verify the system logs user name information when unsuccessful logon attempts occur with the following commands. Note: If the System Administrator demonstrates the use of an approved centralized account management method that locks an account after three unsuccessful logon attempts within a period of 15 minutes, this requirement is not applicable. Note: This check applies to OL versions 8.0 and 8.1. If the system is OL version 8.2 or newer, this check is not applicable. $ sudo grep pam_faillock.so /etc/pam.d/password-auth auth required pam_faillock.so preauth dir=/var/log/faillock silent audit deny=3 even_deny_root fail_interval=900 unlock_time=0 auth required pam_faillock.so authfail dir=/var/log/faillock unlock_time=0 account required pam_faillock.so If the "audit" option is missing from the "preauth" line with the "pam_faillock.so" module, this is a finding. $ sudo grep pam_faillock.so /etc/pam.d/system-auth auth required pam_faillock.so preauth dir=/var/log/faillock silent audit deny=3 even_deny_root fail_interval=900 unlock_time=0 auth required pam_faillock.so authfail dir=/var/log/faillock unlock_time=0 account required pam_faillock.so If the "audit" option is missing from the "preauth" line with the "pam_faillock.so" module, this is a finding.
Configure the operating system to log user name information when unsuccessful logon attempts occur. Add/modify the appropriate sections of the "/etc/pam.d/system-auth" and "/etc/pam.d/password-auth" files to match the following lines: auth required pam_faillock.so preauth dir=/var/log/faillock silent audit deny=3 even_deny_root fail_interval=900 unlock_time=0 auth required pam_faillock.so authfail dir=/var/log/faillock unlock_time=0 account required pam_faillock.so The "sssd" service must be restarted for the changes to take effect. To restart the "sssd" service, run the following command: $ sudo systemctl restart sssd.service
Note: This check applies to OL versions 8.2 or newer. If the system is OL version 8.0 or 8.1, this check is not applicable. Verify the "/etc/security/faillock.conf" file is configured to log user name information when unsuccessful logon attempts occur: $ sudo grep audit /etc/security/faillock.conf audit If the "audit" option is not set, is missing or commented out, this is a finding.
Configure the operating system to log user name information when unsuccessful logon attempts occur. Add/modify the "/etc/security/faillock.conf" file to match the following line: audit
Verify the system includes the root account when locking an account after three unsuccessful logon attempts within a period of 15 minutes with the following commands. Note: If the System Administrator demonstrates the use of an approved centralized account management method that locks an account after three unsuccessful logon attempts within a period of 15 minutes, this requirement is not applicable. Note: This check applies to OL versions 8.0 and 8.1. If the system is OL version 8.2 or newer, this check is not applicable. $ sudo grep pam_faillock.so /etc/pam.d/password-auth auth required pam_faillock.so preauth dir=/var/log/faillock silent audit deny=3 even_deny_root fail_interval=900 unlock_time=0 auth required pam_faillock.so authfail dir=/var/log/faillock unlock_time=0 account required pam_faillock.so If the "even_deny_root" option is missing from the "preauth" line with the "pam_faillock.so" module, this is a finding. $ sudo grep pam_faillock.so /etc/pam.d/system-auth auth required pam_faillock.so preauth dir=/var/log/faillock silent audit deny=3 even_deny_root fail_interval=900 unlock_time=0 auth required pam_faillock.so authfail dir=/var/log/faillock unlock_time=0 account required pam_faillock.so If the "even_deny_root" option is missing from the "preauth" line with the "pam_faillock.so" module, this is a finding.
Configure the operating system to include root when locking an account after three unsuccessful logon attempts occur in 15 minutes. Add/modify the appropriate sections of the "/etc/pam.d/system-auth" and "/etc/pam.d/password-auth" files to match the following lines: auth required pam_faillock.so preauth dir=/var/log/faillock silent audit deny=3 even_deny_root fail_interval=900 unlock_time=0 auth required pam_faillock.so authfail dir=/var/log/faillock unlock_time=0 account required pam_faillock.so The "sssd" service must be restarted for the changes to take effect. To restart the "sssd" service, run the following command: $ sudo systemctl restart sssd.service
Note: This check applies to OL versions 8.2 or newer. If the system is OL version 8.0 or 8.1, this check is not applicable. Verify the "/etc/security/faillock.conf" file is configured to log user name information when unsuccessful logon attempts occur: $ sudo grep even_deny_root /etc/security/faillock.conf even_deny_root If the "even_deny_root" option is not set or is missing or commented out, this is a finding.
Configure the operating system to include root when locking an account after three unsuccessful logon attempts occur in 15 minutes. Add/modify the "/etc/security/faillock.conf" file to match the following line: even_deny_root
Verify the operating system limits the number of concurrent sessions to 10 for all accounts and/or account types by issuing the following command: $ sudo grep "maxlogins" /etc/security/limits.conf /etc/security/limits.d/*.conf * hard maxlogins 10 This can be set as a global domain (with the * wildcard) but may be set differently for multiple domains. If the "maxlogins" item is missing or commented out, or the value is not set to "10" or less for all domains that have the "maxlogins" item assigned, this is a finding.
Configure OL 8 to limit the number of concurrent sessions to 10 for all accounts and/or account types. Add the following line to the top of "/etc/security/limits.conf" or in a ".conf" file defined in "/etc/security/limits.d/": * hard maxlogins 10
Note: This check applies to OL versions 8.2 or newer, if the system is OL version 8.0 or 8.1, this check is not applicable. Verify the pam_faillock.so module is present in the "/etc/pam.d/system-auth" file: $ sudo grep pam_faillock.so /etc/pam.d/system-auth auth required pam_faillock.so preauth auth required pam_faillock.so authfail account required pam_faillock.so If the pam_faillock.so module is not present in the "/etc/pam.d/system-auth" file with the "preauth" line listed before pam_unix.so, this is a finding.
Configure the operating system to include the use of the pam_faillock.so module in the /etc/pam.d/system-auth file. Add/Modify the appropriate sections of the "/etc/pam.d/system-auth" file to match the following lines: Note: The "preauth" line must be listed before pam_unix.so. auth required pam_faillock.so preauth auth required pam_faillock.so authfail account required pam_faillock.so
Note: This check applies to OL versions 8.2 or newer, if the system is OL version 8.0 or 8.1, this check is not applicable. Verify the pam_faillock.so module is present in the "/etc/pam.d/password-auth" file: $ sudo grep pam_faillock.so /etc/pam.d/password-auth auth required pam_faillock.so preauth auth required pam_faillock.so authfail account required pam_faillock.so If the pam_faillock.so module is not present in the "/etc/pam.d/password-auth" file with the "preauth" line listed before pam_unix.so, this is a finding.
Configure the operating system to include the use of the pam_faillock.so module in the /etc/pam.d/password-auth file. Add/Modify the appropriate sections of the "/etc/pam.d/password-auth" file to match the following lines: Note: The "preauth" line must be listed before pam_unix.so. auth required pam_faillock.so preauth auth required pam_faillock.so authfail account required pam_faillock.so
If the system does not have SELinux enabled and enforcing a targeted policy, or if the pam_faillock module is not configured for use, this requirement is not applicable. Note: This check applies to OL versions 8.2 or newer. If the system is OL version 8.0 or 8.1, this check is not applicable. Verify the location of the non-default tally directory for the pam_faillock module with the following command: $ sudo grep -w dir /etc/security/faillock.conf dir = /var/log/faillock Check the security context type of the non-default tally directory with the following command: $ sudo ls -Zd /var/log/faillock unconfined_u:object_r:faillog_t:s0 /var/log/faillock If the security context type of the non-default tally directory is not "faillog_t", this is a finding.
Configure OL 8 to allow the use of a non-default faillock tally directory while SELinux enforces a targeted policy. Create a non-default faillock tally directory (if it does not already exist) with the following example: $ sudo mkdir /var/log/faillock Update the /etc/selinux/targeted/contexts/files/file_contexts.local with "faillog_t" context type for the non-default faillock tally directory with the following command: $ sudo semanage fcontext -a -t faillog_t "/var/log/faillock(/.*)?" Next, update the context type of the non-default faillock directory/subdirectories and files with the following command: $ sudo restorecon -R -v /var/log/faillock
If the system does not have SELinux enabled and enforcing a targeted policy, or if the pam_faillock module is not configured for use, this requirement is not applicable. Note: This check applies to OL versions 8.0 and 8.1. If the system is OL version 8.2 or newer, this check is not applicable. Verify the location of the non-default tally directory for the pam_faillock module with the following command: $ sudo grep -w dir /etc/pam.d/password-auth auth required pam_faillock.so preauth dir=/var/log/faillock auth required pam_faillock.so authfail dir=/var/log/faillock Check the security context type of the non-default tally directory with the following command: $ sudo ls -Zd /var/log/faillock unconfined_u:object_r:faillog_t:s0 /var/log/faillock If the security context type of the non-default tally directory is not "faillog_t", this is a finding.
Configure OL 8 to allow the use of a non-default faillock tally directory while SELinux enforces a targeted policy. Update the /etc/selinux/targeted/contexts/files/file_contexts.local with "faillog_t" context type for the non-default faillock tally directory with the following command: $ sudo semanage fcontext -a -t faillog_t "/var/log/faillock(/.*)?" Next, update the context type of the non-default faillock directory/subdirectories and files with the following command: $ sudo restorecon -R -v /var/log/faillock
Note: This requirement assumes the use of the OL 8 default graphical user interface, Gnome Shell. If the system does not have any graphical user interface installed, this requirement is Not Applicable. Verify the operating system enables a user's session lock until that user reestablishes access using established identification and authentication procedures with the following command: $ sudo gsettings get org.gnome.desktop.screensaver lock-enabled true If the setting is "false", this is a finding.
Configure OL 8 to enable a user's session lock until that user reestablishes access using established identification and authentication procedures. Create a database to contain the system-wide screensaver settings (if it does not already exist) with the following example: $ sudo vi /etc/dconf/db/local.d/00-screensaver Edit the "[org/gnome/desktop/screensaver]" section of the database file and add or update the following lines: # Set this to true to lock the screen when the screensaver activates lock-enabled=true Update the system databases: $ sudo dconf update
Note: This requirement assumes the use of the OL 8 default graphical user interface, Gnome Shell. If the system does not have any graphical user interface installed, this requirement is Not Applicable. Verify the operating system initiates a session lock a for graphical user interfaces when the screensaver is activated with the following command: $ sudo gsettings get org.gnome.desktop.screensaver lock-delay uint32 5 If the "uint32" setting is missing, or is not set to "5" or less, this is a finding.
Configure the operating system to initiate a session lock for graphical user interfaces when a screensaver is activated. Create a database to contain the system-wide screensaver settings (if it does not already exist) with the following command: Note: The example below is using the database "local" for the system, so if the system is using another database in "/etc/dconf/profile/user", the file should be created under the appropriate subdirectory. $ sudo touch /etc/dconf/db/local.d/00-screensaver [org/gnome/desktop/screensaver] lock-delay=uint32 5 The "uint32" must be included along with the integer key values as shown. Update the system databases: $ sudo dconf update
Note: This requirement assumes the use of the OL 8 default graphical user interface, Gnome Shell. If the system does not have any graphical user interface installed, this requirement is Not Applicable. Verify the operating system disables the user logon list for graphical user interfaces with the following command: $ sudo gsettings get org.gnome.login-screen disable-user-list true If the setting is "false", this is a finding.
Configure the operating system to disable the user list at logon for graphical user interfaces. Create a database to contain the system-wide screensaver settings (if it does not already exist) with the following command: Note: The example below is using the database "local" for the system, so if the system is using another database in "/etc/dconf/profile/user", the file should be created under the appropriate subdirectory. $ sudo touch /etc/dconf/db/local.d/02-login-screen [org/gnome/login-screen] disable-user-list=true Update the system databases: $ sudo dconf update
Verify OL 8 has the "tmux" package installed, by running the following command: $ sudo yum list installed tmux tmux.x86.64 2.7-1.el8 @repository If "tmux" is not installed, this is a finding.
Configure the operating system to enable a user to initiate a session lock via tmux. Install the "tmux" package, if it is not already installed, by running the following command: $ sudo yum install tmux
Verify the operating system enables the user to manually initiate a session lock with the following command: $ sudo grep -Ei 'lock-command|lock-session' /etc/tmux.conf set -g lock-command vlock bind X lock-session If the "lock-command" is not set and "lock-session" is not bound to a specific keyboard key in the global settings, this is a finding.
Configure the operating system to enable a user to manually initiate a session lock via tmux. This configuration binds the uppercase letter "X" to manually initiate a session lock after the prefix key "Ctrl + b" has been sent. The complete key sequence is thus "Ctrl + b" then "Shift + x" to lock tmux. Create a global configuration file "/etc/tmux.conf" and add the following lines: set -g lock-command vlock bind X lock-session Reload tmux configuration to take effect. This can be performed in tmux while it is running: $ tmux source-file /etc/tmux.conf
Verify the operating system shell initialization file is configured to start each shell with the tmux terminal multiplexer with the following commands: Determine if tmux is currently running: $ sudo ps all | grep tmux | grep -v grep If the command does not produce output, this is a finding. Determine the location of the tmux script: $ sudo grep tmux /etc/profile.d/* /etc/profile.d/tmux.sh: case "$name" in (sshd|login) tmux ;; esac Review the tmux script by using the following example: $ sudo cat /etc/profile.d/tmux.sh if [ "$PS1" ]; then parent=$(ps -o ppid= -p $$) name=$(ps -o comm= -p $parent) case "$name" in (sshd|login) tmux ;; esac fi If "tmux" is not configured as the example above, is commented out or missing, this is a finding.
Configure the operating system to initialize the tmux terminal multiplexer as each shell is called by adding the following lines to a custom.sh shell script in the /etc/profile.d/ directory: if [ "$PS1" ]; then parent=$(ps -o ppid= -p $$) name=$(ps -o comm= -p $parent) case "$name" in (sshd|login) tmux ;; esac fi This setting will take effect at next logon.
Verify the operating system prevents users from disabling the tmux terminal multiplexer with the following command: $ sudo grep -i tmux /etc/shells If any output is produced, this is a finding.
Configure the operating system to prevent users from disabling the tmux terminal multiplexer by editing the "/etc/shells" configuration file to remove any instances of tmux.
Verify OL 8 has the "vlock" package installed by running the following command: $ sudo grep vlock /usr/bin/* Binary file /usr/bin/vlock matches If "vlock" is not installed, this is a finding.
Install the "vlock" package, if it is not already installed, by running the following command: $ sudo yum install kbd.x86_64
Verify the operating system enables a user's session lock until that user reestablishes access using established identification and authentication procedures with the following command: This requirement assumes the use of the OL 8 default graphical user interface, Gnome Shell. If the system does not have any graphical user interface installed, this requirement is Not Applicable. $ sudo grep -r removal-action /etc/dconf/db/* /etc/dconf/db/distro.d/20-authselect:removal-action='lock-screen' If the "removal-action='lock-screen'" setting is missing or commented out from the "dconf" database files, this is a finding.
Configure OL 8 to enable a user's session lock until that user reestablishes access using established identification and authentication procedures. Select/create an "authselect" profile and incorporate the "with-smartcard-lock-on-removal" feature as in the following example: $ sudo authselect select sssd with-smartcard with-smartcard-lock-on-removal Alternatively, the "dconf" settings can be edited in the "/etc/dconf/db/*" location. Edit or add the "[org/gnome/settings-daemon/peripherals/smartcard]" section of the database file and add or update the following line: removal-action='lock-screen' Update the system databases: $ sudo dconf update
Note: This requirement assumes the use of the OL 8 default graphical user interface, Gnome Shell. If the system does not have any graphical user interface installed, this requirement is Not Applicable. Verify the operating system initiates a session lock after a 15-minute period of inactivity for graphical user interfaces with the following commands: $ sudo gsettings get org.gnome.desktop.session idle-delay uint32 900 If "idle-delay" is set to "0" or a value greater than "900", this is a finding.
Configure OL 8 to initiate a screensaver after a 15-minute period of inactivity for graphical user interfaces. Create a database to contain the system-wide screensaver settings (if it does not already exist) with the following command: $ sudo touch /etc/dconf/db/local.d/00-screensaver Edit "/etc/dconf/db/local.d/00-screensaver" and add or update the following lines: [org/gnome/desktop/session] # Set the lock time out to 900 seconds before the session is considered idle idle-delay=uint32 900 Update the system databases: $ sudo dconf update
Verify the operating system initiates a session lock after 15 minutes of inactivity. Check the value of the system inactivity timeout with the following command: $ sudo grep -i lock-after-time /etc/tmux.conf set -g lock-after-time 900 If "lock-after-time" is not set to "900" or less in the global tmux configuration file to enforce session lock after inactivity, this is a finding.
Configure the operating system to enforce session lock after a period of 15 minutes of inactivity by adding the following line to the "/etc/tmux.conf" global configuration file: set -g lock-after-time 900
Note: This requirement assumes the use of the OL 8 default graphical user interface, Gnome Shell. If the system does not have any graphical user interface installed, this requirement is Not Applicable. Verify the operating system prevents a user from overriding settings for graphical user interfaces. Determine which profile the system database is using with the following command: $ sudo grep system-db /etc/dconf/profile/user system-db:local Check that graphical settings are locked from non-privileged user modification with the following command. Note: The example below is using the database "local" for the system, so the path is "/etc/dconf/db/local.d". This path must be modified if a database other than "local" is being used. $ sudo grep -i lock-delay /etc/dconf/db/local.d/locks/* /org/gnome/desktop/screensaver/lock-delay If the command does not return at least the example result, this is a finding.
Configure OL 8 to prevent a user from overriding settings for graphical user interfaces. Create a database to contain the system-wide screensaver settings (if it does not already exist) with the following command. Note: The example below is using the database "local" for the system, so if the system is using another database in "/etc/dconf/profile/user", the file should be created under the appropriate subdirectory. $ sudo touch /etc/dconf/db/local.d/locks/session Add the following setting to prevent non-privileged users from modifying it: /org/gnome/desktop/screensaver/lock-delay
Note: This requirement assumes the use of the OL 8 default graphical user interface, Gnome Shell. If the system does not have any graphical user interface installed, this requirement is Not Applicable. Verify the operating system prevents a user from overriding settings for graphical user interfaces. Determine which profile the system database is using with the following command: $ sudo grep system-db /etc/dconf/profile/user system-db:local Check that graphical settings are locked from non-privileged user modification with the following command. Note: The example below is using the database "local" for the system, so the path is "/etc/dconf/db/local.d". This path must be modified if a database other than "local" is being used. $ sudo grep -i idle /etc/dconf/db/local.d/locks/* /org/gnome/desktop/screensaver/idle-delay If the command does not return at least the example result, this is a finding.
Configure OL 8 to prevent a user from overriding settings for graphical user interfaces. Create a database to contain the system-wide screensaver settings (if it does not already exist) with the following command. Note: The example below is using the database "local" for the system, so if the system is using another database in "/etc/dconf/profile/user", the file should be created under the appropriate subdirectory. $ sudo touch /etc/dconf/db/local.d/locks/session Add the following setting to prevent non-privileged users from modifying it: /org/gnome/desktop/screensaver/idle-delay
Note: This requirement assumes the use of the OL 8 default graphical user interface, Gnome Shell. If the system does not have any graphical user interface installed, this requirement is Not Applicable. Verify the operating system prevents a user from overriding settings for graphical user interfaces. Determine which profile the system database is using with the following command: $ sudo grep system-db /etc/dconf/profile/user system-db:local Check that graphical settings are locked from non-privileged user modification with the following command. Note: The example below is using the database "local" for the system, so the path is "/etc/dconf/db/local.d". This path must be modified if a database other than "local" is being used. $ sudo grep -i lock-enabled /etc/dconf/db/local.d/locks/* /org/gnome/desktop/screensaver/lock-enabled If the command does not return at least the example result, this is a finding.
Configure OL 8 to prevent a user from overriding settings for graphical user interfaces. Create a database to contain the system-wide screensaver settings (if it does not already exist) with the following command. Note: The example below is using the database "local" for the system, so if the system is using another database in "/etc/dconf/profile/user", the file should be created under the appropriate subdirectory. $ sudo touch /etc/dconf/db/local.d/locks/session Add the following setting to prevent non-privileged users from modifying it: /org/gnome/desktop/screensaver/lock-enabled
Verify the certificate of the user or group is mapped to the corresponding user or group in the "sssd.conf" file with the following command: Note: If the System Administrator demonstrates the use of an approved alternate multifactor authentication method, this requirement is not applicable. $ sudo cat /etc/sssd/sssd.conf [sssd] config_file_version = 2 services = pam, sudo, ssh domains = testing.test [pam] pam_cert_auth = True [domain/testing.test] id_provider = ldap [certmap/testing.test/rule_name] matchrule =<SAN>.*EDIPI@mil maprule = (userCertificate;binary={cert!bin}) domains = testing.test If the "certmap" section does not exist, this is a finding.
Configure OL 8 to map the authenticated identity to the user or group account by adding or modifying the "certmap" section of the "/etc/sssd/sssd.conf" file based on the following example: [certmap/testing.test/rule_name] matchrule =<SAN>.*EDIPI@mil maprule = (userCertificate;binary={cert!bin}) domains = testing.test The "sssd" service must be restarted for the changes to take effect. To restart the "sssd" service, run the following command: $ sudo systemctl restart sssd.service
Verify the operating system uses "pwquality" to enforce the password complexity rules. Check for the use of "pwquality" in the password-auth file with the following command: $ sudo cat /etc/pam.d/password-auth | grep pam_pwquality password requisite pam_pwquality.so If the command does not return a line containing the value "pam_pwquality.so" as shown, or the line is commented out, this is a finding.
Configure the operating system to use "pwquality" to enforce password complexity rules. Add the following line to the "/etc/pam.d/password-auth" file (or modify the line to have the required value): password requisite pam_pwquality.so
Verify the value for "ucredit" in "/etc/security/pwquality.conf" or "/etc/security/pwquality.conf.d/*.conf" files with the following command: $ sudo grep -r ucredit /etc/security/pwquality.conf* /etc/security/pwquality.conf:ucredit = -1 If the value of "ucredit" is a positive number or is commented out, this is a finding. If conflicting results are returned, this is a finding.
Configure OL 8 to enforce password complexity by requiring that at least one uppercase character be used by setting the "ucredit" option. Add or update the following line in the "/etc/security/pwquality.conf" file or a configuration file in the "/etc/security/pwquality.conf.d/" directory: ucredit = -1 Remove any configurations that conflict with the above value.
Verify the value for "lcredit" in "/etc/security/pwquality.conf" or "/etc/security/pwquality.conf.d/*.conf" files with the following command: $ sudo grep -r lcredit /etc/security/pwquality.conf* /etc/security/pwquality.conf:lcredit = -1 If the value of "lcredit" is a positive number or is commented out, this is a finding. If conflicting results are returned, this is a finding.
Configure OL 8 to enforce password complexity by requiring that at least one lowercase character be used by setting the "lcredit" option. Add or update the following line in the "/etc/security/pwquality.conf" file or a configuration file in the "/etc/security/pwquality.conf.d/" directory: lcredit = -1 Remove any configurations that conflict with the above value.
Verify the value for "dcredit" in "/etc/security/pwquality.conf" or "/etc/security/pwquality.conf.d/*.conf" files with the following command: $ sudo grep -r dcredit /etc/security/pwquality.conf* /etc/security/pwquality.conf:dcredit = -1 If the value of "dcredit" is a positive number or is commented out, this is a finding. If conflicting results are returned, this is a finding.
Configure OL 8 to enforce password complexity by requiring that at least one numeric character be used by setting the "dcredit" option. Add or update the following line in the "/etc/security/pwquality.conf" file or a configuration file in the "/etc/security/pwquality.conf.d/" directory: dcredit = -1 Remove any configurations that conflict with the above value.
Check for the value of the "maxclassrepeat" option in "/etc/security/pwquality.conf" or "/etc/security/pwquality.conf.d/*.conf" files with the following command: $ sudo grep -r maxclassrepeat /etc/security/pwquality.conf* /etc/security/pwquality.conf:maxclassrepeat = 4 If the value of "maxclassrepeat" is set to "0", more than "4" or is commented out, this is a finding. If conflicting results are returned, this is a finding.
Configure OL 8 to require the change of the number of repeating characters of the same character class when passwords are changed by setting the "maxclassrepeat" option. Add or update the following line in the "/etc/security/pwquality.conf" file or a configuration file in the "/etc/security/pwquality.conf.d/" directory: maxclassrepeat = 4 Remove any configurations that conflict with the above value.
Check for the value of the "maxrepeat" option in "/etc/security/pwquality.conf" or "/etc/security/pwquality.conf.d/*.conf" files with the following command: $ sudo grep -r maxrepeat /etc/security/pwquality.conf* /etc/security/pwquality.conf:maxrepeat = 3 If the value of "maxrepeat" is set to more than "3" or is commented out, this is a finding. If conflicting results are returned, this is a finding.
Configure OL 8 to require the change of the number of repeating consecutive characters when passwords are changed by setting the "maxrepeat" option. Add or update the following line in the "/etc/security/pwquality.conf" file or a configuration file in the "/etc/security/pwquality.conf.d/" directory: maxrepeat = 3 Remove any configurations that conflict with the above value.
Verify the value of the "minclass" option in "/etc/security/pwquality.conf" or "/etc/security/pwquality.conf.d/*.conf" files with the following command: $ sudo grep -r minclass /etc/security/pwquality.conf* /etc/security/pwquality.conf:minclass = 4 If the value of "minclass" is set to less than "4" or is commented out, this is a finding. If conflicting results are returned, this is a finding.
Configure OL 8 to require the change of at least four character classes when passwords are changed by setting the "minclass" option. Add or update the following line in the "/etc/security/pwquality.conf" file or a configuration file in the "/etc/security/pwquality.conf.d/" directory: minclass = 4 Remove any configurations that conflict with the above value.
Verify the value of the "difok" option in "/etc/security/pwquality.conf" or "/etc/security/pwquality.conf.d/*.conf" files with the following command: $ sudo grep -r difok /etc/security/pwquality.conf* /etc/security/pwquality.conf:difok = 8 If the value of "difok" is set to less than "8" or is commented out, this is a finding. If conflicting results are returned, this is a finding.
Configure OL 8 to require the change of at least eight of the total number of characters when passwords are changed by setting the "difok" option. Add or update the following line in the "/etc/security/pwquality.conf" file or a configuration file in the "/etc/security/pwquality.conf.d/" directory: difok = 8 Remove any configurations that conflict with the above value.
Verify the minimum time period between password changes for each user account is one day or greater. $ sudo awk -F: '$4 < 1 {print $1 " " $4}' /etc/shadow If any results are returned that are not associated with a system account, this is a finding.
Configure non-compliant accounts to enforce a 24 hours/one day minimum password lifetime: $ sudo chage -m 1 [user]
Verify the operating system enforces 24 hours/one day as the minimum password lifetime for new user accounts. Check for the value of "PASS_MIN_DAYS" in "/etc/login.defs" with the following command: $ sudo grep -i pass_min_days /etc/login.defs PASS_MIN_DAYS 1 If the "PASS_MIN_DAYS" parameter value is not "1" or greater or is commented out, this is a finding.
Configure OL 8 to enforce 24 hours/one day as the minimum password lifetime. Add the following line in "/etc/login.defs" (or modify the line to have the required value): PASS_MIN_DAYS 1
Verify that OL 8 enforces a 60-day maximum password lifetime for new user accounts by running the following command: $ sudo grep -i pass_max_days /etc/login.defs PASS_MAX_DAYS 60 If the "PASS_MAX_DAYS" parameter value is greater than "60", or commented out, this is a finding.
Configure OL 8 to enforce a 60-day maximum password lifetime. Add or modify the following line in the "/etc/login.defs" file: PASS_MAX_DAYS 60
Verify the maximum time period for existing passwords is restricted to 60 days with the following commands: $ sudo awk -F: '$5 > 60 {print $1 " " $5}' /etc/shadow $ sudo awk -F: '$5 <= 0 {print $1 " " $5}' /etc/shadow If any results are returned that are not associated with a system account, this is a finding.
Configure non-compliant accounts to enforce a 60-day maximum password lifetime restriction. $ sudo chage -M 60 [user]