DISA STIG for Oracle Linux 9


This profile contains configuration checks that align to the DISA STIG for Oracle Linux 9 V1R3.


ID Severity Title Discussion (Rationale) Fix Text (Description) Check Text (OCIL Check) SRG Refs CCI Refs 800-53 Refs
xccdf_org.ssgproject.content_rule_account_disable_post_pw_expiration medium Set Account Expiration Following Inactivity Inactive identifiers pose a risk to systems and applications because attackers may exploit an inactive identifier and potentially obtain undetected access to the system. Disabling inactive accounts ensures that accounts which may not have been responsibly removed are not available to attackers who may have compromised their credentials. Owners of inactive accounts will not notice if unauthorized access to their user account has been obtained. To specify the number of days after a password expires (which signifies inactivity) until an account is permanently disabled, add or correct the following line in /etc/default/useradd: 
INACTIVE=35
If a password is currently on the verge of expiration, then 35 day(s) remain(s) until the account is automatically disabled. However, if the password will not expire for another 60 days, then 60 days plus 35 day(s) could elapse until the account would be automatically disabled. See the useradd man page for more information.		 
To verify the INACTIVE setting, run the following command:

$ grep "INACTIVE" /etc/default/useradd

The output should indicate the INACTIVE configuration option is set
to an appropriate integer as shown in the example below:

$ grep "INACTIVE" /etc/default/useradd
INACTIVE=35

      Is it the case that the value of INACTIVE is greater than the expected value or is -1?
 SRG-OS-000118-GPOS-00060 IA-4(e), AC-2(3), CM-6(a)
xccdf_org.ssgproject.content_rule_account_password_pam_faillock_password_auth medium Configure the Use of the pam_faillock.so Module in the /etc/pam.d/password-auth File. If the pam_faillock.so module is not loaded the system will not correctly lockout accounts to prevent password guessing attacks. The pam_faillock.so module must be loaded in preauth in /etc/pam.d/password-auth. 
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
      Is it the case that 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?
 SRG-OS-000021-GPOS-00005 AC-7 (a)
xccdf_org.ssgproject.content_rule_account_password_pam_faillock_system_auth medium Configure the Use of the pam_faillock.so Module in the /etc/pam.d/system-auth File. If the pam_faillock.so module is not loaded the system will not correctly lockout accounts to prevent password guessing attacks. The pam_faillock.so module must be loaded in preauth in /etc/pam.d/system-auth. 
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
      Is it the case that 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?
 SRG-OS-000021-GPOS-00005 AC-7 (a)
xccdf_org.ssgproject.content_rule_account_password_selinux_faillock_dir medium An SELinux Context must be configured for the pam_faillock.so records directory Not having the correct SELinux context on the pam_faillock.so records directory may lead to unauthorized access to the directory. The dir configuration option in PAM pam_faillock.so module defines where the lockout records is stored. The configured directory must have the correct SELinux context. 
If the system does not have SELinux enabled and enforcing a targeted policy, or if the
pam_faillock.so module is not configured for use, this requirement is not applicable.

Verify the location of the non-default tally directory for the pam_faillock.so 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
      Is it the case that the security context type of the non-default tally directory is not "faillog_t"?
 SRG-OS-000021-GPOS-00005 AC-7 (a)
xccdf_org.ssgproject.content_rule_account_temp_expire_date medium Assign Expiration Date to Temporary Accounts If temporary user accounts remain active when no longer needed or for an excessive period, these accounts may be used to gain unauthorized access. To mitigate this risk, automated termination of all temporary accounts must be set upon account creation.
Temporary accounts are established as part of normal account activation procedures when there is a need for short-term accounts. In the event temporary accounts are required, configure the system to terminate them after a documented time period. For every temporary account, run the following command to set an expiration date on it, substituting USER and YYYY-MM-DD appropriately: 
$ sudo chage -E YYYY-MM-DD USER
YYYY-MM-DD indicates the documented expiration date for the account. For U.S. Government systems, the operating system must be configured to automatically terminate these types of accounts after a period of 72 hours.		 
Verify that temporary accounts have been provisioned with an expiration date
of 72 hours. For every temporary account, run the following command to
obtain its account aging and expiration information:

$ sudo chage -l temporary_account_name

Verify each of these accounts has an expiration date set within 72 hours or
as documented.
      Is it the case that any temporary accounts have no expiration date set or do not expire within 72 hours?
 SRG-OS-000123-GPOS-00064, SRG-OS-000002-GPOS-00002 AC-2(2), AC-2(3), CM-6(a)
xccdf_org.ssgproject.content_rule_account_unique_id medium Ensure All Accounts on the System Have Unique User IDs To assure accountability and prevent unauthenticated access, interactive users must be identified and authenticated to prevent potential misuse and compromise of the system. Change user IDs (UIDs), or delete accounts, so each has a unique name. 
Verify that Oracle Linux 9 contains no duplicate User IDs (UIDs) for interactive users.

Check that the operating system contains no duplicate UIDs for interactive users with the following command:


$ sudo awk -F ":" 'list[$3]++{print $1, $3}' /etc/passwd

      Is it the case that output is produced and the accounts listed are interactive user accounts?
 SRG-OS-000104-GPOS-00051, SRG-OS-000121-GPOS-00062
xccdf_org.ssgproject.content_rule_accounts_authorized_local_users medium Only Authorized Local User Accounts Exist on Operating System Accounts providing no operational purpose provide additional opportunities for system compromise. Unnecessary accounts include user accounts for individuals not requiring access to the system and application accounts for applications not installed on the system. Enterprise Application tends to use the server or virtual machine exclusively. Besides the default operating system user, there should be only authorized local users required by the installed software groups and applications that exist on the operating system. The authorized user list can be customized in the refine value variable var_accounts_authorized_local_users_regex. OVAL regular expression is used for the user list. Configure the system so all accounts on the system are assigned to an active system, application, or user account. Remove accounts that do not support approved system activities or that allow for a normal user to perform administrative-level actions. To remove unauthorized system accounts, use the following command: 
$ sudo userdel unauthorized_user
 
To verify that there are no unauthorized local user accounts, run the following command:

$ less /etc/passwd 

Inspect the results, and if unauthorized local user accounts exist, remove them by running
the following command:

$ sudo userdel unauthorized_user

      Is it the case that there are unauthorized local user accounts on the system?
 SRG-OS-000480-GPOS-00227
xccdf_org.ssgproject.content_rule_accounts_have_homedir_login_defs medium Ensure Home Directories are Created for New Users If local interactive users are not assigned a valid home directory, there is no place for the storage and control of files they should own. All local interactive user accounts, upon creation, should be assigned a home directory.

Configure the operating system 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 all local interactive users on Oracle Linux 9 are assigned a home
directory upon creation with the following command:

$ grep -i create_home /etc/login.defs


CREATE_HOME yes

      Is it the case that the value for "CREATE_HOME" parameter is not set to "yes", the line is missing, or the line is commented out?
 SRG-OS-000480-GPOS-00227
xccdf_org.ssgproject.content_rule_accounts_logon_fail_delay medium Ensure the Logon Failure Delay is Set Correctly in login.defs Increasing the time between a failed authentication attempt and re-prompting to enter credentials helps to slow a single-threaded brute force attack. To ensure the logon failure delay controlled by /etc/login.defs is set properly, add or correct the FAIL_DELAY setting in /etc/login.defs to read as follows: 
FAIL_DELAY 4
 
Verify Oracle Linux 9 enforces a delay of at least 4 seconds between console logon prompts following a failed logon attempt with the following command:


$ sudo grep -i "FAIL_DELAY" /etc/login.defs
FAIL_DELAY 4

      Is it the case that the value of "FAIL_DELAY" is not set to "4" or greater, or the line is commented out?
 SRG-OS-000480-GPOS-00226 AC-7(b), CM-6(a)
xccdf_org.ssgproject.content_rule_accounts_max_concurrent_login_sessions low Limit the Number of Concurrent Login Sessions Allowed Per User Limiting simultaneous user logins can insulate the system from denial of service problems caused by excessive logins. Automated login processes operating improperly or maliciously may result in an exceptional number of simultaneous login sessions. Limiting the number of allowed users and sessions per user can limit risks related to Denial of Service attacks. This addresses concurrent sessions for a single account and does not address concurrent sessions by a single user via multiple accounts. To set the number of concurrent sessions per user add the following line in /etc/security/limits.conf or a file under /etc/security/limits.d/: 
* hard maxlogins 10
 
Verify Oracle Linux 9 limits the number of concurrent sessions to
"10" for all
accounts and/or account types with the following command:

$ grep -r -s maxlogins /etc/security/limits.conf /etc/security/limits.d/*.conf


/etc/security/limits.conf:* hard maxlogins 10

This can be set as a global domain (with the * wildcard) but may be set differently for multiple domains.
      Is it the case that the "maxlogins" item is missing, commented out, or the value is set greater
than "10" and
is not documented with the Information System Security Officer (ISSO) as an
operational requirement for all domains that have the "maxlogins" item
assigned'?
 SRG-OS-000027-GPOS-00008 AC-10, CM-6(a)
xccdf_org.ssgproject.content_rule_accounts_maximum_age_login_defs medium Set Password Maximum Age Any password, no matter how complex, can eventually be cracked. Therefore, passwords need to be changed periodically. If the operating system does not limit the lifetime of passwords and force users to change their passwords, there is the risk that the operating system passwords could be compromised.

Setting the password maximum age ensures users are required to periodically change their passwords. Requiring shorter password lifetimes increases the risk of users writing down the password in a convenient location subject to physical compromise.		 To specify password maximum age for new accounts, edit the file /etc/login.defs and add or correct the following line: 
PASS_MAX_DAYS 60
The profile requirement is 60.		 
Verify that Oracle Linux 9 enforces a 60-day maximum password lifetime for new user accounts by running the following command:


$ grep -i pass_max_days /etc/login.defs

PASS_MAX_DAYS 60

      Is it the case that the "PASS_MAX_DAYS" parameter value is greater than "60", or commented out?
 SRG-OS-000076-GPOS-00044 IA-5(f), IA-5(1)(d), CM-6(a)
xccdf_org.ssgproject.content_rule_accounts_minimum_age_login_defs medium Set Password Minimum Age Enforcing a minimum password lifetime helps to prevent repeated password changes to defeat the password reuse or history enforcement requirement. If users are allowed to immediately and continually change their password, then the password could be repeatedly changed in a short period of time to defeat the organization's policy regarding password reuse.

Setting the minimum password age protects against users cycling back to a favorite password after satisfying the password reuse requirement.		 To specify password minimum age for new accounts, edit the file /etc/login.defs and add or correct the following line: 
PASS_MIN_DAYS 1
A value of 1 day is considered sufficient for many environments. The profile requirement is 1.		 
Verify Oracle Linux 9 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:


$ grep -i pass_min_days /etc/login.defs

PASS_MIN_DAYS 1

      Is it the case that the "PASS_MIN_DAYS" parameter value is not "1" or greater, or is commented out?
 SRG-OS-000075-GPOS-00043 IA-5(f), IA-5(1)(d), CM-6(a)
xccdf_org.ssgproject.content_rule_accounts_no_uid_except_zero high Verify Only Root Has UID 0 An account has root authority if it has a UID of 0. Multiple accounts with a UID of 0 afford more opportunity for potential intruders to guess a password for a privileged account. Proper configuration of sudo is recommended to afford multiple system administrators access to root privileges in an accountable manner. If any account other than root has a UID of 0, this misconfiguration should be investigated and the accounts other than root should be removed or have their UID changed.
If the account is associated with system commands or applications the UID should be changed to one greater than "0" but less than "1000." Otherwise assign a UID greater than "1000" that has not already been assigned.		 
Verify that only the "root" account has a UID "0" assignment with the
following command:

$ awk -F: '$3 == 0 {print $1}' /etc/passwd


root

      Is it the case that any accounts other than "root" have a UID of "0"?
 SRG-OS-000480-GPOS-00227 IA-2, AC-6(5), IA-4(b)
xccdf_org.ssgproject.content_rule_accounts_password_all_shadowed_sha512 medium Verify All Account Password Hashes are Shadowed with SHA512 Passwords need to be protected at all times, and encryption is the standard method for protecting passwords. If passwords are not encrypted, they can be plainly read (i.e., clear text) and easily compromised. Verify the operating system requires the shadow password suite configuration be set to encrypt interactive user passwords using a strong cryptographic hash. Check 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.		 
Verify 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.
      Is it the case that any interactive user password hash does not begin with "$6"?
 SRG-OS-000073-GPOS-00041, SRG-OS-000120-GPOS-00061 IA-5(1)(c), IA-5(1).1(v), IA-7, IA-7.1
xccdf_org.ssgproject.content_rule_accounts_password_pam_dcredit medium Ensure PAM Enforces Password Requirements - Minimum Digit Characters Use of a complex password helps to increase the time and resources required to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks.

Password complexity is one factor of several that determines how long it takes to crack a password. The more complex the password, the greater the number of possible combinations that need to be tested before the password is compromised. Requiring digits makes password guessing attacks more difficult by ensuring a larger search space.		 The pam_pwquality module's dcredit parameter controls requirements for usage of digits in a password. When set to a negative number, any password will be required to contain that many digits. When set to a positive number, pam_pwquality will grant +1 additional length credit for each digit. Modify the dcredit setting in /etc/security/pwquality.conf to require the use of a digit in passwords. 
Verify that Oracle Linux 9 enforces password complexity by requiring that at least one numeric character be used.

Check the value for "dcredit" with the following command:


$ sudo grep dcredit /etc/security/pwquality.conf /etc/security/pwquality.conf.d/*.conf

/etc/security/pwquality.conf:dcredit = 

      Is it the case that the value of "dcredit" is a positive number or is commented out?
 SRG-OS-000071-GPOS-00039 IA-5(c), IA-5(1)(a), CM-6(a), IA-5(4)
xccdf_org.ssgproject.content_rule_accounts_password_pam_dictcheck medium Ensure PAM Enforces Password Requirements - Prevent the Use of Dictionary Words Use of a complex password helps to increase the time and resources required to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks.

Password complexity is one factor of several that determines how long it takes to crack a password. The more complex the password, the greater the number of possible combinations that need to be tested before the password is compromised.

Passwords with dictionary words may be more vulnerable to password-guessing attacks.		 The pam_pwquality module's dictcheck check if passwords contains dictionary words. When dictcheck is set to 1 passwords will be checked for dictionary words. 
Verify Oracle Linux 9 prevents the use of dictionary words for passwords with the following command:


$ sudo grep dictcheck /etc/security/pwquality.conf /etc/pwquality.conf.d/*.conf

/etc/security/pwquality.conf:dictcheck=1

      Is it the case that "dictcheck" does not have a value other than "0", or is commented out?
 SRG-OS-000480-GPOS-00225, SRG-OS-000072-GPOS-00040 IA-5(c), IA-5(1)(a), CM-6(a), IA-5(4)
xccdf_org.ssgproject.content_rule_accounts_password_pam_difok medium Ensure PAM Enforces Password Requirements - Minimum Different Characters Use of a complex password helps to increase the time and resources required to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute–force attacks.

Password complexity is one factor of several that determines how long it takes to crack a password. The more complex the password, the greater the number of possible combinations that need to be tested before the password is compromised.

Requiring a minimum number of different characters during password changes ensures that newly changed passwords should not resemble previously compromised ones. Note that passwords which are changed on compromised systems will still be compromised, however.		 The pam_pwquality module's difok parameter sets the number of characters in a password that must not be present in and old password during a password change.

Modify the difok setting in /etc/security/pwquality.conf to equal 8 to require differing characters when changing passwords.		 
Verify the value of the "difok" option in "/etc/security/pwquality.conf" with the following command:


$ sudo grep difok /etc/security/pwquality.conf

difok = 8

      Is it the case that the value of "difok" is set to less than "8", or is commented out?
 SRG-OS-000072-GPOS-00040 IA-5(c), IA-5(1)(b), CM-6(a), IA-5(4)
xccdf_org.ssgproject.content_rule_accounts_password_pam_enforce_root medium Ensure PAM Enforces Password Requirements - Enforce for root User Use of a complex password helps to increase the time and resources required to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. Password complexity is one factor of several that determines how long it takes to crack a password. The more complex the password, the greater the number of possible combinations that need to be tested before the password is compromised. The pam_pwquality module's enforce_for_root parameter controls requirements for enforcing password complexity for the root user. Enable the enforce_for_root setting in /etc/security/pwquality.conf to require the root user to use complex passwords. 
Verify that Oracle Linux 9 enforces password complexity rules for the root account.

Check if root user is required to use complex passwords with the following command:


$ grep enforce_for_root /etc/security/pwquality.conf /etc/security/pwquality.conf.d/*.conf

/etc/security/pwquality.conf:enforce_for_root

      Is it the case that "enforce_for_root" is commented or missing?
 SRG-OS-000072-GPOS-00040, SRG-OS-000071-GPOS-00039, SRG-OS-000070-GPOS-00038, SRG-OS-000266-GPOS-00101, SRG-OS-000078-GPOS-00046, SRG-OS-000480-GPOS-00225, SRG-OS-000069-GPOS-00037 IA-5(c), IA-5(1)(a), CM-6(a), IA-5(4)
xccdf_org.ssgproject.content_rule_accounts_password_pam_lcredit medium Ensure PAM Enforces Password Requirements - Minimum Lowercase Characters Use of a complex password helps to increase the time and resources required to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks.
Password complexity is one factor of several that determines how long it takes to crack a password. The more complex the password, the greater the number of possible combinations that need to be tested before the password is compromised. Requiring a minimum number of lowercase characters makes password guessing attacks more difficult by ensuring a larger search space.		 The pam_pwquality module's lcredit parameter controls requirements for usage of lowercase letters in a password. When set to a negative number, any password will be required to contain that many lowercase characters. When set to a positive number, pam_pwquality will grant +1 additional length credit for each lowercase character. Modify the lcredit setting in /etc/security/pwquality.conf to require the use of a lowercase character in passwords. 
Verify that Oracle Linux 9 enforces password complexity by requiring that at least one lower-case character.

Check the value for "lcredit" with the following command:


$ sudo grep lcredit /etc/security/pwquality.conf /etc/security/pwquality.conf.d/*.conf

/etc/security/pwquality.conf:lcredit = -1

      Is it the case that the value of "lcredit" is a positive number or is commented out?
 SRG-OS-000070-GPOS-00038 IA-5(c), IA-5(1)(a), CM-6(a), IA-5(4)
xccdf_org.ssgproject.content_rule_accounts_password_pam_maxclassrepeat medium Ensure PAM Enforces Password Requirements - Maximum Consecutive Repeating Characters from Same Character Class Use of a complex password helps to increase the time and resources required to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks.
Password complexity is one factor of several that determines how long it takes to crack a password. The more complex a password, the greater the number of possible combinations that need to be tested before the password is compromised.		 The pam_pwquality module's maxclassrepeat parameter controls requirements for consecutive repeating characters from the same character class. When set to a positive number, it will reject passwords which contain more than that number of consecutive characters from the same character class. Modify the maxclassrepeat setting in /etc/security/pwquality.conf to equal 4 to prevent a run of (4 + 1) or more identical characters. 
Verify the value of the "maxclassrepeat" option in "/etc/security/pwquality.conf" with the following command:


$ grep maxclassrepeat /etc/security/pwquality.conf

maxclassrepeat = 4

      Is it the case that the value of "maxclassrepeat" is set to "0", more than "4" or is commented out?
 SRG-OS-000072-GPOS-00040, SRG-OS-000730-GPOS-00190 IA-5(c), IA-5(1)(a), CM-6(a), IA-5(4)
xccdf_org.ssgproject.content_rule_accounts_password_pam_maxrepeat medium Set Password Maximum Consecutive Repeating Characters Use of a complex password helps to increase the time and resources required to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks.

Password complexity is one factor of several that determines how long it takes to crack a password. The more complex the password, the greater the number of possible combinations that need to be tested before the password is compromised.

Passwords with excessive repeating characters may be more vulnerable to password-guessing attacks.		 The pam_pwquality module's maxrepeat parameter controls requirements for consecutive repeating characters. When set to a positive number, it will reject passwords which contain more than that number of consecutive characters. Modify the maxrepeat setting in /etc/security/pwquality.conf to equal 3 to prevent a run of (3 + 1) or more identical characters. 
Verify the value of the "maxrepeat" option in "/etc/security/pwquality.conf" with the following command:


$ grep maxrepeat /etc/security/pwquality.conf

maxrepeat = 3

      Is it the case that the value of "maxrepeat" is set to more than "3" or is commented out?
 SRG-OS-000072-GPOS-00040 IA-5(c), CM-6(a), IA-5(4)
xccdf_org.ssgproject.content_rule_accounts_password_pam_minclass medium Ensure PAM Enforces Password Requirements - Minimum Different Categories Use of a complex password helps to increase the time and resources required to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks.

Password complexity is one factor of several that determines how long it takes to crack a password. The more complex the password, the greater the number of possible combinations that need to be tested before the password is compromised.

Requiring a minimum number of character categories makes password guessing attacks more difficult by ensuring a larger search space.		 The pam_pwquality module's minclass parameter controls requirements for usage of different character classes, or types, of character that must exist in a password before it is considered valid. For example, setting this value to three (3) requires that any password must have characters from at least three different categories in order to be approved. The default value is zero (0), meaning there are no required classes. There are four categories available: 
* Upper-case characters
* Lower-case characters
* Digits
* Special characters (for example, punctuation)
Modify the minclass setting in /etc/security/pwquality.conf entry to require 4 differing categories of characters when changing passwords.		 
Verify the value of the "minclass" option in "/etc/security/pwquality.conf" with the following command:


$ grep minclass /etc/security/pwquality.conf

minclass = 4

      Is it the case that the value of "minclass" is set to less than "4" or is commented out?
 SRG-OS-000072-GPOS-00040 IA-5(c), IA-5(1)(a), CM-6(a), IA-5(4)
xccdf_org.ssgproject.content_rule_accounts_password_pam_minlen medium Ensure PAM Enforces Password Requirements - Minimum Length The shorter the password, the lower the number of possible combinations that need to be tested before the password is compromised.
Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. Password length is one factor of several that helps to determine strength and how long it takes to crack a password. Use of more characters in a password helps to exponentially increase the time and/or resources required to compromise the password.		 The pam_pwquality module's minlen parameter controls requirements for minimum characters required in a password. Add minlen=15 after pam_pwquality to set minimum password length requirements. 
Verify that Oracle Linux 9 enforces a minimum 15-character password length with the following command:


$ grep minlen /etc/security/pwquality.conf

minlen = 15

      Is it the case that the command does not return a "minlen" value of "15" or greater, does not return a line, or the line is commented out?
 SRG-OS-000078-GPOS-00046 IA-5(c), IA-5(1)(a), CM-6(a), IA-5(4)
xccdf_org.ssgproject.content_rule_accounts_password_pam_ocredit medium Ensure PAM Enforces Password Requirements - Minimum Special Characters Use of a complex password helps to increase the time and resources required to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks.

Password complexity is one factor of several that determines how long it takes to crack a password. The more complex the password, the greater the number of possible combinations that need to be tested before the password is compromised. Requiring a minimum number of special characters makes password guessing attacks more difficult by ensuring a larger search space.		 The pam_pwquality module's ocredit= parameter controls requirements for usage of special (or "other") characters in a password. When set to a negative number, any password will be required to contain that many special characters. When set to a positive number, pam_pwquality will grant +1 additional length credit for each special character. Modify the ocredit setting in /etc/security/pwquality.conf to equal -1 to require use of a special character in passwords. 
Verify that Oracle Linux 9 enforces password complexity by requiring that at least one special character with the following command:


$ sudo grep ocredit /etc/security/pwquality.conf /etc/security/pwquality.conf.d/*.conf

ocredit = -1

      Is it the case that value of "ocredit" is a positive number or is commented out?
 SRG-OS-000266-GPOS-00101 IA-5(c), IA-5(1)(a), CM-6(a), IA-5(4)
xccdf_org.ssgproject.content_rule_accounts_password_pam_pwquality_password_auth medium Ensure PAM password complexity module is enabled in password-auth Enabling PAM password complexity permits to enforce strong passwords and consequently makes the system less prone to dictionary attacks. To enable PAM password complexity in password-auth file: Edit the password section in /etc/pam.d/password-auth to show password requisite pam_pwquality.so. 
To check if pam_pwquality.so is enabled in password-auth, run the following command:

$ grep pam_pwquality /etc/pam.d/password-auth

The output should be similar to the following:

password requisite pam_pwquality.so

      Is it the case that pam_pwquality.so is not enabled in password-auth?
 SRG-OS-000069-GPOS-00037, SRG-OS-000070-GPOS-00038, SRG-OS-000480-GPOS-00227
xccdf_org.ssgproject.content_rule_accounts_password_pam_pwquality_retry medium Ensure PAM Enforces Password Requirements - Authentication Retry Prompts Permitted Per-Session in /etc/security/pwquality.conf Setting the password retry prompts that are permitted on a per-session basis to a low value requires some software, such as SSH, to re-connect. This can slow down and draw additional attention to some types of password-guessing attacks. Note that this is different from account lockout, which is provided by the pam_faillock module. To configure the number of retry prompts that are permitted per-session: Edit the /etc/security/pwquality.conf to include retry=3, or a lower value if site policy is more restrictive. The profile requirement is a maximum of retry=3 prompts per session. 
Verify Oracle Linux 9 is configured to limit the "pwquality" retry option to 3.

Check for the use of the "pwquality" retry option in the pwquality.conf file with the following command:

$ grep retry /etc/security/pwquality.conf

      Is it the case that the value of "retry" is set to "0" or greater than "3", or is missing?
 SRG-OS-000069-GPOS-00037
xccdf_org.ssgproject.content_rule_accounts_password_pam_pwquality_system_auth medium Ensure PAM password complexity module is enabled in system-auth Enabling PAM password complexity permits to enforce strong passwords and consequently makes the system less prone to dictionary attacks. To enable PAM password complexity in system-auth file: Edit the password section in /etc/pam.d/system-auth to show password requisite pam_pwquality.so. 
To check if pam_pwquality.so is enabled in system-auth, run the following command:

$ grep pam_pwquality /etc/pam.d/system-auth

The output should be similar to the following:

password requisite pam_pwquality.so

      Is it the case that pam_pwquality.so is not enabled in system-auth?
 SRG-OS-000480-GPOS-00227
xccdf_org.ssgproject.content_rule_accounts_password_pam_ucredit medium Ensure PAM Enforces Password Requirements - Minimum Uppercase Characters Use of a complex password helps to increase the time and resources required to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks.

Password complexity is one factor of several that determines how long it takes to crack a password. The more complex the password, the greater the number of possible combinations that need to be tested before the password is compromised.		 The pam_pwquality module's ucredit= parameter controls requirements for usage of uppercase letters in a password. When set to a negative number, any password will be required to contain that many uppercase characters. When set to a positive number, pam_pwquality will grant +1 additional length credit for each uppercase character. Modify the ucredit setting in /etc/security/pwquality.conf to require the use of an uppercase character in passwords. 
Verify that Oracle Linux 9 enforces password complexity by requiring that at least one upper-case character.

Check the value for "ucredit" with the following command:

$ sudo grep ucredit /etc/security/pwquality.conf /etc/security/pwquality.conf.d/*.conf

ucredit = -1
      Is it the case that the value of "ucredit" is a positive number or is commented out?
 SRG-OS-000069-GPOS-00037, SRG-OS-000070-GPOS-00038 IA-5(c), IA-5(1)(a), CM-6(a), IA-5(4)
xccdf_org.ssgproject.content_rule_accounts_password_pam_unix_rounds_password_auth medium Set number of Password Hashing Rounds - password-auth Using a higher number of rounds makes password cracking attacks more difficult. Configure the number or rounds for the password hashing algorithm. This can be accomplished by using the rounds option for the pam_unix PAM module.

In file /etc/pam.d/password-auth append rounds=100000 to the pam_unix.so entry, as shown below: 
password sufficient pam_unix.so ...existing_options... rounds=100000
The system's default number of rounds is 5000.		 
To verify the number of rounds for the password hashing algorithm is configured, run the following command:

$ sudo grep rounds /etc/pam.d/password-auth

The output should show the following match:


password sufficient pam_unix.so sha512 rounds=100000

      Is it the case that rounds is not set to 100000 or is commented out?
 SRG-OS-000073-GPOS-00041
xccdf_org.ssgproject.content_rule_accounts_password_pam_unix_rounds_system_auth medium Set number of Password Hashing Rounds - system-auth Using a higher number of rounds makes password cracking attacks more difficult. Configure the number or rounds for the password hashing algorithm. This can be accomplished by using the rounds option for the pam_unix PAM module.

In file /etc/pam.d/system-auth append rounds=100000 to the pam_unix.so entry, as shown below: 
password sufficient pam_unix.so ...existing_options... rounds=100000
The system's default number of rounds is 5000.		 
To verify the number of rounds for the password hashing algorithm is configured, run the following command:

$ sudo grep rounds /etc/pam.d/system-auth

The output should show the following match:

password sufficient pam_unix.so sha512 rounds=100000

      Is it the case that rounds is not set to 100000 or is commented out?
 SRG-OS-000073-GPOS-00041
xccdf_org.ssgproject.content_rule_accounts_password_set_max_life_existing medium Set Existing Passwords Maximum Age Any password, no matter how complex, can eventually be cracked. Therefore, passwords need to be changed periodically. If the operating system does not limit the lifetime of passwords and force users to change their passwords, there is the risk that the operating system passwords could be compromised. Configure non-compliant accounts to enforce a 60-day maximum password lifetime restriction by running the following command: 
$ sudo chage -M 60 USER
 
Check whether 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
      Is it the case that any results are returned that are not associated with a system account?
 SRG-OS-000076-GPOS-00044 IA-5(f), IA-5(1)(d), CM-6(a)
xccdf_org.ssgproject.content_rule_accounts_password_set_min_life_existing medium Set Existing Passwords Minimum Age Enforcing a minimum password lifetime helps to prevent repeated password changes to defeat the password reuse or history enforcement requirement. If users are allowed to immediately and continually change their password, the password could be repeatedly changed in a short period of time to defeat the organization's policy regarding password reuse. Configure non-compliant accounts to enforce a 24 hours/1 day minimum password lifetime by running the following command: 
$ sudo chage -m 1 USER
 
Verify that Oracle Linux 9 has configured the minimum time period between password changes for each user account is one day or greater with the following command:

$ sudo awk -F: '$4 < 1 {print $1 " " $4}' /etc/shadow
      Is it the case that any results are returned that are not associated with a system account?
 SRG-OS-000075-GPOS-00043 IA-5(f), IA-5(1)(d), CM-6(a)
xccdf_org.ssgproject.content_rule_accounts_passwords_pam_faillock_audit medium Account Lockouts Must Be Logged Without auditing of these events it may be harder or impossible to identify what an attacker did after an attack. PAM faillock locks an account due to excessive password failures, this event must be logged. 
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
      Is it the case that the "audit" option is not set, is missing or commented out?
 SRG-OS-000021-GPOS-00005 AC-7 (a)
xccdf_org.ssgproject.content_rule_accounts_passwords_pam_faillock_deny medium Lock Accounts After Failed Password Attempts By limiting the number of failed logon attempts, the risk of unauthorized system access via user password guessing, also known as brute-forcing, is reduced. Limits are imposed by locking the account. This rule configures the system to lock out accounts after a number of incorrect login attempts using pam_faillock.so. pam_faillock.so module requires multiple entries in pam files. These entries must be carefully defined to work as expected. Ensure that the file /etc/security/faillock.conf contains the following entry: deny = <count> Where count should be less than or equal to 3 and greater than 0. In order to avoid errors when manually editing these files, it is recommended to use the appropriate tools, such as authselect or authconfig, depending on the OS version. 
Verify Oracle Linux 9 is configured to lock an account after 3
unsuccessful logon attempts with the command:


$ grep 'deny =' /etc/security/faillock.conf

deny = 3.
      Is it the case that the "deny" option is not set to "3"
or less (but not "0"), is missing or commented out?
 SRG-OS-000329-GPOS-00128, SRG-OS-000021-GPOS-00005 CM-6(a), AC-7(a)
xccdf_org.ssgproject.content_rule_accounts_passwords_pam_faillock_deny_root medium Configure the root Account for Failed Password Attempts By limiting the number of failed logon attempts, the risk of unauthorized system access via user password guessing, also known as brute-forcing, is reduced. Limits are imposed by locking the account. This rule configures the system to lock out the root account after a number of incorrect login attempts using pam_faillock.so. pam_faillock.so module requires multiple entries in pam files. These entries must be carefully defined to work as expected. In order to avoid errors when manually editing these files, it is recommended to use the appropriate tools, such as authselect or authconfig, depending on the OS version. 
Verify Oracle Linux 9 is configured to lock the root account after 
unsuccessful logon attempts with the command:


$ grep even_deny_root /etc/security/faillock.conf

even_deny_root
      Is it the case that the "even_deny_root" option is not set, is missing or commented out?
 SRG-OS-000329-GPOS-00128, SRG-OS-000021-GPOS-00005 CM-6(a), AC-7(b), IA-5(c)
xccdf_org.ssgproject.content_rule_accounts_passwords_pam_faillock_dir medium Lock Accounts Must Persist Locking out user accounts after a number of incorrect attempts prevents direct password guessing attacks. In combination with the silent option, user enumeration attacks are also mitigated. This rule ensures that the system lock out accounts using pam_faillock.so persist after system reboot. From "pam_faillock" man pages: 
Note that the default directory that "pam_faillock" uses is usually cleared on system
boot so the access will be re-enabled after system reboot. If that is undesirable, a different
tally directory must be set with the "dir" option.
pam_faillock.so module requires multiple entries in pam files. These entries must be carefully defined to work as expected. In order to avoid errors when manually editing these files, it is recommended to use the appropriate tools, such as authselect or authconfig, depending on the OS version. The chosen profile expects the directory to be None. To configure the tally directory, add the following line to /etc/security/faillock.conf: 
dir = None
 
To ensure the tally directory is configured correctly, run the following command:

$ sudo grep 'dir =' /etc/security/faillock.conf

The output should show that dir is set to something other than "/var/run/faillock"
      Is it the case that the "dir" option is not set to a non-default documented tally log directory, is missing or commented out?
 SRG-OS-000021-GPOS-00005, SRG-OS-000329-GPOS-00128 AC-7(b), AC-7(a), AC-7.1(ii)
xccdf_org.ssgproject.content_rule_accounts_passwords_pam_faillock_interval medium Set Interval For Counting Failed Password Attempts By limiting the number of failed logon attempts the risk of unauthorized system access via user password guessing, otherwise known as brute-forcing, is reduced. Limits are imposed by locking the account. Utilizing pam_faillock.so, the fail_interval directive configures the system to lock out an account after a number of incorrect login attempts within a specified time period. Ensure that the file /etc/security/faillock.conf contains the following entry: fail_interval = <interval-in-seconds> where interval-in-seconds is 900 or greater. In order to avoid errors when manually editing these files, it is recommended to use the appropriate tools, such as authselect or authconfig, depending on the OS version. 
To ensure the failed password attempt policy is configured correctly, run the following command:


$ grep fail_interval /etc/security/faillock.conf

The output should show fail_interval = <interval-in-seconds> where interval-in-seconds is 900 or greater.
      Is it the case that the "fail_interval" option is not set to "900"
or less (but not "0"), the line is commented out, or the line is missing?
 SRG-OS-000329-GPOS-00128, SRG-OS-000021-GPOS-00005 CM-6(a), AC-7(a)
xccdf_org.ssgproject.content_rule_accounts_passwords_pam_faillock_unlock_time medium Set Lockout Time for Failed Password Attempts By limiting the number of failed logon attempts the risk of unauthorized system access via user password guessing, otherwise known as brute-forcing, is reduced. Limits are imposed by locking the account. This rule configures the system to lock out accounts during a specified time period after a number of incorrect login attempts using pam_faillock.so. Ensure that the file /etc/security/faillock.conf contains the following entry: unlock_time=<interval-in-seconds> where interval-in-seconds is 0 or greater. pam_faillock.so module requires multiple entries in pam files. These entries must be carefully defined to work as expected. In order to avoid any errors when manually editing these files, it is recommended to use the appropriate tools, such as authselect or authconfig, depending on the OS version. If unlock_time is set to 0, manual intervention by an administrator is required to unlock a user. This should be done using the faillock tool. 
Verify Oracle Linux 9 is configured to lock an account until released by an administrator
after  unsuccessful logon
attempts with the command:


$ grep 'unlock_time =' /etc/security/faillock.conf

unlock_time = 0
      Is it the case that the "unlock_time" option is not set to "0",
the line is missing, or commented out?
 SRG-OS-000329-GPOS-00128, SRG-OS-000021-GPOS-00005 CM-6(a), AC-7(b)
xccdf_org.ssgproject.content_rule_accounts_tmout medium Set Interactive Session Timeout Terminating an idle session within a short time period reduces the window of opportunity for unauthorized personnel to take control of a management session enabled on the console or console port that has been left unattended. Setting the TMOUT option in /etc/profile ensures that all user sessions will terminate based on inactivity. A value of 0 (zero) disables the automatic logout feature and is therefore not a compliant setting. The value of TMOUT should be a positive integer, exported, and read only. The TMOUT setting in a file loaded by /etc/profile, e.g. /etc/profile.d/tmout.sh should read as follows: 
typeset -xr TMOUT=900
or 
declare -xr TMOUT=900
Using the typeset keyword is preferred for wider compatibility with ksh and other shells.		 
Run the following command to ensure the TMOUT value is configured for all users
on the system:


$ sudo grep TMOUT /etc/profile /etc/profile.d/*.sh


The output should return the following:

TMOUT=900

      Is it the case that the TMOUT value is not configured, is set to 0, or is not less than or equal to the expected setting?
 SRG-OS-000163-GPOS-00072, SRG-OS-000029-GPOS-00010 AC-12, SC-10, AC-2(5), CM-6(a)
xccdf_org.ssgproject.content_rule_accounts_umask_etc_bashrc medium Ensure the Default Bash Umask is Set Correctly The umask value influences the permissions assigned to files when they are created. A misconfigured umask value could result in files with excessive permissions that can be read or written to by unauthorized users. To ensure the default umask for users of the Bash shell is set properly, add or correct the umask setting in /etc/bashrc to read as follows: 
umask 077
 
Verify the umask setting is configured correctly in the /etc/bashrc file with the following command:


$ sudo grep "umask" /etc/bashrc

umask 077

      Is it the case that the value for the "umask" parameter is not "077", or the "umask" parameter is missing or is commented out?
 SRG-OS-000480-GPOS-00228, SRG-OS-000480-GPOS-00227 AC-6(1), CM-6(a)
xccdf_org.ssgproject.content_rule_accounts_umask_etc_csh_cshrc medium Ensure the Default C Shell Umask is Set Correctly The umask value influences the permissions assigned to files when they are created. A misconfigured umask value could result in files with excessive permissions that can be read or written to by unauthorized users. To ensure the default umask for users of the C shell is set properly, add or correct the umask setting in /etc/csh.cshrc to read as follows: 
umask 077
 
Verify the "umask" setting is configured correctly in the "/etc/csh.cshrc" file with the following command:

$ grep umask /etc/csh.cshrc

umask 077
umask 077
      Is it the case that the value for the "umask" parameter is not "077", or the "umask" parameter is missing or is commented out?
 SRG-OS-000480-GPOS-00228, SRG-OS-000480-GPOS-00227 AC-6(1), CM-6(a)
xccdf_org.ssgproject.content_rule_accounts_umask_etc_login_defs medium Ensure the Default Umask is Set Correctly in login.defs The umask value influences the permissions assigned to files when they are created. A misconfigured umask value could result in files with excessive permissions that can be read and written to by unauthorized users. To ensure the default umask controlled by /etc/login.defs is set properly, add or correct the UMASK setting in /etc/login.defs to read as follows: 
UMASK 077
 
Verify Oracle Linux 9 defines default permissions for all authenticated users in such a way that the user can only read and modify their own files with the following command:


# grep -i umask /etc/login.defs

UMASK 077

      Is it the case that the value for the "UMASK" parameter is not "077", or the "UMASK" parameter is missing or is commented out?
 SRG-OS-000480-GPOS-00228 AC-6(1), CM-6(a)
xccdf_org.ssgproject.content_rule_accounts_umask_etc_profile medium Ensure the Default Umask is Set Correctly in /etc/profile The umask value influences the permissions assigned to files when they are created. A misconfigured umask value could result in files with excessive permissions that can be read or written to by unauthorized users. To ensure the default umask controlled by /etc/profile is set properly, add or correct the umask setting in /etc/profile to read as follows: 
umask 077
Note that /etc/profile also reads scripts within /etc/profile.d directory. These scripts are also valid files to set umask value. Therefore, they should also be considered during the check and properly remediated, if necessary.		 
Verify the umask setting is configured correctly in the /etc/profile file
or scripts within /etc/profile.d directory with the following command:

$ grep "umask" /etc/profile*


umask 077

      Is it the case that the value for the "umask" parameter is not "077",
or the "umask" parameter is missing or is commented out?
 SRG-OS-000480-GPOS-00228, SRG-OS-000480-GPOS-00227 AC-6(1), CM-6(a)
xccdf_org.ssgproject.content_rule_accounts_umask_interactive_users medium Ensure the Default Umask is Set Correctly For Interactive Users The umask controls the default access mode assigned to newly created files. A umask of 077 limits new files to mode 700 or less permissive. Although umask can be represented as a four-digit number, the first digit representing special access modes is typically ignored or required to be 0. This requirement applies to the globally configured system defaults and the local interactive user defaults for each account on the system. Remove the UMASK environment variable from all interactive users initialization files. 
Verify that the default umask for all local interactive users is "077".

Identify the locations of all local interactive user home directories by looking at the "/etc/passwd" file.

Check all local interactive user initialization files for interactive users with the following command:

Note: The example is for a system that is configured to create users home directories in the "/home" directory.

$ sudo find /home -maxdepth 2 -type f -name ".[^.]*" -exec grep -iH -d skip --exclude=.bash_history umask {} \;

/home/wadea/.bash_history:grep -i umask /etc/bashrc /etc/csh.cshrc /etc/profile
/home/wadea/.bash_history:grep -i umask /etc/login.defs
      Is it the case that any local interactive user initialization files are found to have a umask statement that sets a value less restrictive than "077"?
 SRG-OS-000480-GPOS-00227, SRG-OS-000480-GPOS-00228
xccdf_org.ssgproject.content_rule_accounts_user_dot_no_world_writable_programs medium User Initialization Files Must Not Run World-Writable Programs If user start-up files execute world-writable programs, especially in unprotected directories, they could be maliciously modified to destroy user files or otherwise compromise the system at the user level. If the system is compromised at the user level, it is easier to elevate privileges to eventually compromise the system at the root and network level. Set the mode on files being executed by the user initialization files with the following command: 
$ sudo chmod o-w FILE
 
Verify that local initialization files do not execute world-writable programs with the following command:

Note: The example will be for a system that is configured to create user home directories in the "/home" directory.


$ sudo find /home -perm -002 -type f -name ".[^.]*" -exec ls -ld {} \;

      Is it the case that any local initialization files are found to reference world-writable files?
 SRG-OS-000480-GPOS-00227
xccdf_org.ssgproject.content_rule_accounts_user_home_paths_only medium Ensure that Users Path Contains Only Local Directories The executable search path (typically the PATH environment variable) contains a list of directories for the shell to search to find executables. If this path includes the current working directory (other than the users home directory), executables in these directories may be executed instead of system commands. This variable is formatted as a colon-separated list of directories. If there is an empty entry, such as a leading or trailing colon or two consecutive colons, this is interpreted as the current working directory. If deviations from the default system search path for the local interactive user are required, they must be documented with the Information System Security Officer (ISSO). Ensure that all interactive user initialization files executable search path statements do not contain statements that will reference a working directory other than the users home directory. 
Verify that all local interactive user initialization file executable search path statements do not contain statements that will reference a working directory other than user home directories with the following commands:


$ sudo grep -i path= /home/*/.*

/home/[localinteractiveuser]/.bash_profile:PATH=$PATH:$HOME/.local/bin:$HOME/bin

      Is it the case that any local interactive user initialization files have executable search path statements that include directories outside of their home directory and is not documented with the ISSO as an operational requirement?
 SRG-OS-000480-GPOS-00227
xccdf_org.ssgproject.content_rule_accounts_user_interactive_home_directory_defined medium All Interactive Users Must Have A Home Directory Defined If local interactive users are not assigned a valid home directory, there is no place for the storage and control of files they should own. Assign home directories to all interactive users that currently do not have a home directory assigned. This rule checks if the home directory is properly defined in a folder which has at least one parent folder, like "user" in "/home/user" or "/remote/users/user". Therefore, this rule will report a finding for home directories like /users, /tmp or /. 
Verify that interactive users on the system have a home directory assigned with the following command:


$ sudo awk -F: '($3>=1000)&&($7 !~ /nologin/){print $1, $3, $6}' /etc/passwd


Inspect the output and verify that all interactive users (normally users with a UID greater than 1000) have a home directory defined.
      Is it the case that users home directory is not defined?
 SRG-OS-000480-GPOS-00227
xccdf_org.ssgproject.content_rule_accounts_user_interactive_home_directory_exists medium All Interactive Users Home Directories Must Exist If a local interactive user has a home directory defined that does not exist, the user may be given access to the / directory as the current working directory upon logon. This could create a Denial of Service because the user would not be able to access their logon configuration files, and it may give them visibility to system files they normally would not be able to access. 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: 
$ sudo mkdir /home/USER
 
Verify the assigned home directories of all interactive users on the system exist with the following command:


$ sudo pwck -r

user 'mailnull': directory 'var/spool/mqueue' does not exist


The output should not return any interactive users.
      Is it the case that users home directory does not exist?
 SRG-OS-000480-GPOS-00227
xccdf_org.ssgproject.content_rule_aide_check_audit_tools medium Configure AIDE to Verify the Audit Tools Protecting the integrity of the tools used for auditing purposes is a critical step toward ensuring the integrity of audit information. Audit information includes all information (e.g., audit records, audit settings, and audit reports) needed to successfully audit information system activity. Audit tools include but are not limited to vendor-provided and open-source audit tools needed to successfully view and manipulate audit information system activity and records. Audit tools include custom queries and report generators. It is not uncommon for attackers to replace the audit tools or inject code into the existing tools to provide the capability to hide or erase system activity from the audit logs. To address this risk, audit tools must be cryptographically signed to provide the capability to identify when the audit tools have been modified, manipulated, or replaced. An example is a checksum hash of the file or files. The operating system file integrity tool must be configured to protect the integrity of the audit tools. 
Check that AIDE is properly configured to protect the integrity of the
audit tools by running the following command:


# sudo cat /etc/aide.conf | grep /usr/sbin/au

/usr/sbin/auditctl p+i+n+u+g+s+b+acl+xattrs+sha512
/usr/sbin/auditd p+i+n+u+g+s+b+acl+xattrs+sha512
/usr/sbin/ausearch p+i+n+u+g+s+b+acl+xattrs+sha512
/usr/sbin/aureport p+i+n+u+g+s+b+acl+xattrs+sha512
/usr/sbin/autrace p+i+n+u+g+s+b+acl+xattrs+sha512

/usr/sbin/rsyslogd p+i+n+u+g+s+b+acl+xattrs+sha512
/usr/sbin/augenrules p+i+n+u+g+s+b+acl+xattrs+sha512



If AIDE is configured properly to protect the integrity of the audit tools,
all lines listed above will be returned from the command.

If one or more lines are missing, this is a finding.
      Is it the case that integrity checks of the audit tools are missing or incomplete?
 SRG-OS-000278-GPOS-00108 AU-9(3), AU-9(3).1
xccdf_org.ssgproject.content_rule_aide_periodic_cron_checking medium Configure Periodic Execution of AIDE By default, AIDE does not install itself for periodic execution. Periodically running AIDE is necessary to reveal unexpected changes in installed files.

Unauthorized changes to the baseline configuration could make the system vulnerable to various attacks or allow unauthorized access to the operating system. Changes to operating system configurations can have unintended side effects, some of which may be relevant to security.

Detecting such changes and providing an automated response can help avoid unintended, negative consequences that could ultimately affect the security state of the operating system. The operating system's Information Management Officer (IMO)/Information System Security Officer (ISSO) and System Administrators (SAs) must be notified via email and/or monitoring system trap when there is an unauthorized modification of a configuration item.		 At a minimum, AIDE should be configured to run a weekly scan. To implement a daily execution of AIDE at 4:05am using cron, add the following line to /etc/crontab: 
05 4 * * * root /usr/sbin/aide --check
To implement a weekly execution of AIDE at 4:05am using cron, add the following line to /etc/crontab: 
05 4 * * 0 root /usr/sbin/aide --check
AIDE can be executed periodically through other means; this is merely one example. The usage of cron's special time codes, such as @daily and @weekly is acceptable.		 
Verify the operating system routinely checks the baseline configuration for unauthorized changes.

To determine that periodic AIDE execution has been scheduled, run the following command:

$ grep aide /etc/crontab

The output should return something similar to the following:

05 4 * * * root /usr/sbin/aide --check


NOTE: The usage of special cron times, such as @daily or @weekly, is acceptable.
      Is it the case that AIDE is not configured to scan periodically?
 SRG-OS-000363-GPOS-00150, SRG-OS-000446-GPOS-00200, SRG-OS-000447-GPOS-00201 SI-7, SI-7(1), CM-6(a)
xccdf_org.ssgproject.content_rule_aide_scan_notification medium Configure Notification of Post-AIDE Scan Details Unauthorized changes to the baseline configuration could make the system vulnerable to various attacks or allow unauthorized access to the operating system. Changes to operating system configurations can have unintended side effects, some of which may be relevant to security.

Detecting such changes and providing an automated response can help avoid unintended, negative consequences that could ultimately affect the security state of the operating system. The operating system's Information Management Officer (IMO)/Information System Security Officer (ISSO) and System Administrators (SAs) must be notified via email and/or monitoring system trap when there is an unauthorized modification of a configuration item.		 AIDE should notify appropriate personnel of the details of a scan after the scan has been run. If AIDE has already been configured for periodic execution in /etc/crontab, append the following line to the existing AIDE line: 
 | /bin/mail -s "$(hostname) - AIDE Integrity Check" root@localhost
Otherwise, add the following line to /etc/crontab: 
05 4 * * * root /usr/sbin/aide --check | /bin/mail -s "$(hostname) - AIDE Integrity Check" root@localhost
AIDE can be executed periodically through other means; this is merely one example.		 
To determine that periodic AIDE execution has been scheduled, run the following command:


$ grep aide /etc/crontab

The output should return something similar to the following:

05 4 * * * root /usr/sbin/aide --check | /bin/mail -s "$(hostname) - AIDE Integrity Check" root@localhost

The email address that the notifications are sent to can be changed by overriding

.
      Is it the case that AIDE has not been configured or has not been configured to notify personnel of scan details?
 SRG-OS-000363-GPOS-00150, SRG-OS-000446-GPOS-00200, SRG-OS-000447-GPOS-00201 CM-6(a), CM-3(5)
xccdf_org.ssgproject.content_rule_aide_use_fips_hashes medium Configure AIDE to Use FIPS 140-2 for Validating Hashes File integrity tools use cryptographic hashes for verifying file contents and directories have not been altered. These hashes must be FIPS 140-2 approved cryptographic hashes. By default, the sha512 option is added to the NORMAL ruleset in AIDE. If using a custom ruleset or the sha512 option is missing, add sha512 to the appropriate ruleset. For example, add sha512 to the following line in /etc/aide.conf: 
NORMAL = FIPSR+sha512
AIDE rules can be configured in multiple ways; this is merely one example that is already configured by default.		 
To determine that AIDE is configured for FIPS 140-2 file hashing, run the following command:

$ grep sha512 /etc/aide.conf

Verify that the sha512 option is added to the correct ruleset.
      Is it the case that the sha512 option is missing or not added to the correct ruleset?
 SRG-OS-000480-GPOS-00227 SI-7, SI-7(1), CM-6(a)
xccdf_org.ssgproject.content_rule_aide_verify_acls low Configure AIDE to Verify Access Control Lists (ACLs) ACLs can provide permissions beyond those permitted through the file mode and must be verified by the file integrity tools. By default, the acl option is added to the FIPSR ruleset in AIDE. If using a custom ruleset or the acl option is missing, add acl to the appropriate ruleset. For example, add acl to the following line in /etc/aide.conf: 
FIPSR = p+i+n+u+g+s+m+c+acl+selinux+xattrs+sha256
AIDE rules can be configured in multiple ways; this is merely one example that is already configured by default. The remediation provided with this rule adds acl to all rule sets available in /etc/aide.conf		 
To determine that AIDE is verifying ACLs, run the following command:

$ grep acl /etc/aide.conf

Verify that the acl option is added to the correct ruleset.
      Is it the case that the acl option is missing or not added to the correct ruleset?
 SRG-OS-000480-GPOS-00227 SI-7, SI-7(1), CM-6(a)
xccdf_org.ssgproject.content_rule_aide_verify_ext_attributes low Configure AIDE to Verify Extended Attributes Extended attributes in file systems are used to contain arbitrary data and file metadata with security implications. By default, the xattrs option is added to the FIPSR ruleset in AIDE. If using a custom ruleset or the xattrs option is missing, add xattrs to the appropriate ruleset. For example, add xattrs to the following line in /etc/aide.conf: 
FIPSR = p+i+n+u+g+s+m+c+acl+selinux+xattrs+sha256
AIDE rules can be configured in multiple ways; this is merely one example that is already configured by default. The remediation provided with this rule adds xattrs to all rule sets available in /etc/aide.conf		 
To determine that AIDE is verifying extended file attributes, run the following command:

$ grep xattrs /etc/aide.conf

Verify that the xattrs option is added to the correct ruleset.
      Is it the case that the xattrs option is missing or not added to the correct ruleset?
 SRG-OS-000480-GPOS-00227 SI-7, SI-7(1), CM-6(a)
xccdf_org.ssgproject.content_rule_audit_privileged_commands_init medium Ensure auditd Collects Information on the Use of Privileged Commands - init Misuse of the init command may cause availability issues for the system. At a minimum, the audit system should collect the execution of privileged commands for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add a line of the following form to a file with suffix .rules in the directory /etc/audit/rules.d: 
-a always,exit -F path=/usr/sbin/init -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged
If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules: 
-a always,exit -F path=/usr/sbin/init -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged
 
Verify that Oracle Linux 9 is configured to audit the execution of the "init" command with the following command:

$ sudo auditctl -l | grep init

-a always,exit -F path={{{ path }}}/init -F perm=x -F auid>=1000 -F auid!=unset -k privileged-init
      Is it the case that the command does not return a line, or the line is commented out?
 SRG-OS-000477-GPOS-00222 AU-12(c)
xccdf_org.ssgproject.content_rule_audit_privileged_commands_poweroff medium Ensure auditd Collects Information on the Use of Privileged Commands - poweroff Misuse of the poweroff command may cause availability issues for the system. At a minimum, the audit system should collect the execution of privileged commands for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add a line of the following form to a file with suffix .rules in the directory /etc/audit/rules.d: 
-a always,exit -F path=/usr/sbin/poweroff -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged
If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules: 
-a always,exit -F path=/usr/sbin/poweroff -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged
 
Verify that Oracle Linux 9 is configured to audit the execution of the "poweroff" command with the following command:

$ sudo auditctl -l | grep poweroff

-a always,exit -F path={{{ path }}}/poweroff -F perm=x -F auid>=1000 -F auid!=unset -k privileged-poweroff
      Is it the case that the command does not return a line, or the line is commented out?
 SRG-OS-000477-GPOS-00222 AU-12(c)
xccdf_org.ssgproject.content_rule_audit_privileged_commands_reboot medium Ensure auditd Collects Information on the Use of Privileged Commands - reboot Misuse of the reboot command may cause availability issues for the system. At a minimum, the audit system should collect the execution of privileged commands for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add a line of the following form to a file with suffix .rules in the directory /etc/audit/rules.d: 
-a always,exit -F path=/usr/sbin/reboot -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged
If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules: 
-a always,exit -F path=/usr/sbin/reboot -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged
 
Verify that Oracle Linux 9 is configured to audit the execution of the "reboot" command with the following command:

$ sudo auditctl -l | grep reboot

-a always,exit -F path={{{ path }}}/reboot -F perm=x -F auid>=1000 -F auid!=unset -k privileged-reboot
      Is it the case that the command does not return a line, or the line is commented out?
 SRG-OS-000477-GPOS-00222 AU-12(c)
xccdf_org.ssgproject.content_rule_audit_privileged_commands_shutdown medium Ensure auditd Collects Information on the Use of Privileged Commands - shutdown Misuse of the shutdown command may cause availability issues for the system. At a minimum, the audit system should collect the execution of privileged commands for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add a line of the following form to a file with suffix .rules in the directory /etc/audit/rules.d: 
-a always,exit -F path=/usr/sbin/shutdown -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged
If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules: 
-a always,exit -F path=/usr/sbin/shutdown -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged
 
Verify that Oracle Linux 9 is configured to audit the execution of the "shutdown" command with the following command:

$ sudo auditctl -l | grep shutdown

-a always,exit -F path={{{ path }}}/shutdown -F perm=x -F auid>=1000 -F auid!=unset -k privileged-shutdown
      Is it the case that the command does not return a line, or the line is commented out?
 SRG-OS-000477-GPOS-00222 AU-12(c)
xccdf_org.ssgproject.content_rule_audit_rules_dac_modification_chmod medium Record Events that Modify the System's Discretionary Access Controls - chmod The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users. At a minimum, the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d: 
-a always,exit -F arch=b32 -S chmod -F auid>=1000 -F auid!=unset -F key=perm_mod
If the system is 64 bit then also add the following line: 
-a always,exit -F arch=b64 -S chmod -F auid>=1000 -F auid!=unset -F key=perm_mod
If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file: 
-a always,exit -F arch=b32 -S chmod -F auid>=1000 -F auid!=unset -F key=perm_mod
If the system is 64 bit then also add the following line: 
-a always,exit -F arch=b64 -S chmod -F auid>=1000 -F auid!=unset -F key=perm_mod
 
To determine if the system is configured to audit calls to the
chmod system call, run the following command:

$ sudo grep "chmod" /etc/audit/audit.*

If the system is configured to audit this activity, it will return a line.

      Is it the case that no line is returned?
 SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215, SRG-OS-000064-GPOS-00033, SRG-OS-000466-GPOS-00210, SRG-OS-000458-GPOS-00203, SRG-APP-000091-CTR-000160, SRG-APP-000492-CTR-001220, SRG-APP-000493-CTR-001225, SRG-APP-000494-CTR-001230, SRG-APP-000500-CTR-001260, SRG-APP-000507-CTR-001295, SRG-APP-000495-CTR-001235, SRG-APP-000499-CTR-001255 AU-2(d), AU-12(c), CM-6(a)
xccdf_org.ssgproject.content_rule_audit_rules_dac_modification_chown medium Record Events that Modify the System's Discretionary Access Controls - chown The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users. At a minimum, the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d: 
-a always,exit -F arch=b32 -S chown -F auid>=1000 -F auid!=unset -F key=perm_mod
If the system is 64 bit then also add the following line: 
-a always,exit -F arch=b64 -S chown -F auid>=1000 -F auid!=unset -F key=perm_mod
If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file: 
-a always,exit -F arch=b32 -S chown -F auid>=1000 -F auid!=unset -F key=perm_mod
If the system is 64 bit then also add the following line: 
-a always,exit -F arch=b64 -S chown -F auid>=1000 -F auid!=unset -F key=perm_mod
 
To determine if the system is configured to audit calls to the
chown system call, run the following command:

$ sudo grep "chown" /etc/audit/audit.*

If the system is configured to audit this activity, it will return a line.

      Is it the case that no line is returned?
 SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215, SRG-OS-000064-GPOS-00033, SRG-OS-000466-GPOS-00210, SRG-OS-000458-GPOS-00203, SRG-OS-000474-GPOS-00219, SRG-APP-000091-CTR-000160, SRG-APP-000492-CTR-001220, SRG-APP-000493-CTR-001225, SRG-APP-000494-CTR-001230, SRG-APP-000500-CTR-001260, SRG-APP-000507-CTR-001295, SRG-APP-000495-CTR-001235, SRG-APP-000499-CTR-001255 AU-2(d), AU-12(c), CM-6(a)
xccdf_org.ssgproject.content_rule_audit_rules_dac_modification_fchmod medium Record Events that Modify the System's Discretionary Access Controls - fchmod The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users. At a minimum, the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d: 
-a always,exit -F arch=b32 -S fchmod -F auid>=1000 -F auid!=unset -F key=perm_mod
If the system is 64 bit then also add the following line: 
-a always,exit -F arch=b64 -S fchmod -F auid>=1000 -F auid!=unset -F key=perm_mod
If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file: 
-a always,exit -F arch=b32 -S fchmod -F auid>=1000 -F auid!=unset -F key=perm_mod
If the system is 64 bit then also add the following line: 
-a always,exit -F arch=b64 -S fchmod -F auid>=1000 -F auid!=unset -F key=perm_mod
 
To determine if the system is configured to audit calls to the
fchmod system call, run the following command:

$ sudo grep "fchmod" /etc/audit/audit.*

If the system is configured to audit this activity, it will return a line.

      Is it the case that no line is returned?
 SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215, SRG-OS-000064-GPOS-00033, SRG-OS-000466-GPOS-00210, SRG-OS-000458-GPOS-00203, SRG-APP-000091-CTR-000160, SRG-APP-000492-CTR-001220, SRG-APP-000493-CTR-001225, SRG-APP-000494-CTR-001230, SRG-APP-000500-CTR-001260, SRG-APP-000507-CTR-001295, SRG-APP-000495-CTR-001235, SRG-APP-000499-CTR-001255 AU-2(d), AU-12(c), CM-6(a)
xccdf_org.ssgproject.content_rule_audit_rules_dac_modification_fchmodat medium Record Events that Modify the System's Discretionary Access Controls - fchmodat The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users. At a minimum, the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d: 
-a always,exit -F arch=b32 -S fchmodat -F auid>=1000 -F auid!=unset -F key=perm_mod
If the system is 64 bit then also add the following line: 
-a always,exit -F arch=b64 -S fchmodat -F auid>=1000 -F auid!=unset -F key=perm_mod
If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file: 
-a always,exit -F arch=b32 -S fchmodat -F auid>=1000 -F auid!=unset -F key=perm_mod
If the system is 64 bit then also add the following line: 
-a always,exit -F arch=b64 -S fchmodat -F auid>=1000 -F auid!=unset -F key=perm_mod
 
To determine if the system is configured to audit calls to the
fchmodat system call, run the following command:

$ sudo grep "fchmodat" /etc/audit/audit.*

If the system is configured to audit this activity, it will return a line.

      Is it the case that no line is returned?
 SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215, SRG-OS-000064-GPOS-00033, SRG-OS-000466-GPOS-00210, SRG-OS-000458-GPOS-00203, SRG-APP-000091-CTR-000160, SRG-APP-000492-CTR-001220, SRG-APP-000493-CTR-001225, SRG-APP-000494-CTR-001230, SRG-APP-000500-CTR-001260, SRG-APP-000507-CTR-001295, SRG-APP-000495-CTR-001235, SRG-APP-000499-CTR-001255 AU-2(d), AU-12(c), CM-6(a)
xccdf_org.ssgproject.content_rule_audit_rules_dac_modification_fchown medium Record Events that Modify the System's Discretionary Access Controls - fchown The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users. At a minimum, the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d: 
-a always,exit -F arch=b32 -S fchown -F auid>=1000 -F auid!=unset -F key=perm_mod
If the system is 64 bit then also add the following line: 
-a always,exit -F arch=b64 -S fchown -F auid>=1000 -F auid!=unset -F key=perm_mod
If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file: 
-a always,exit -F arch=b32 -S fchown -F auid>=1000 -F auid!=unset -F key=perm_mod
If the system is 64 bit then also add the following line: 
-a always,exit -F arch=b64 -S fchown -F auid>=1000 -F auid!=unset -F key=perm_mod
 
To determine if the system is configured to audit calls to the
fchown system call, run the following command:

$ sudo grep "fchown" /etc/audit/audit.*

If the system is configured to audit this activity, it will return a line.

      Is it the case that no line is returned?
 SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215, SRG-OS-000064-GPOS-00033, SRG-OS-000466-GPOS-00210, SRG-OS-000458-GPOS-00203, SRG-OS-000474-GPOS-00219, SRG-APP-000091-CTR-000160, SRG-APP-000492-CTR-001220, SRG-APP-000493-CTR-001225, SRG-APP-000494-CTR-001230, SRG-APP-000500-CTR-001260, SRG-APP-000507-CTR-001295, SRG-APP-000495-CTR-001235, SRG-APP-000499-CTR-001255 AU-2(d), AU-12(c), CM-6(a)
xccdf_org.ssgproject.content_rule_audit_rules_dac_modification_fchownat medium Record Events that Modify the System's Discretionary Access Controls - fchownat The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users. At a minimum, the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d: 
-a always,exit -F arch=b32 -S fchownat -F auid>=1000 -F auid!=unset -F key=perm_mod
If the system is 64 bit then also add the following line: 
-a always,exit -F arch=b64 -S fchownat -F auid>=1000 -F auid!=unset -F key=perm_mod
If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file: 
-a always,exit -F arch=b32 -S fchownat -F auid>=1000 -F auid!=unset -F key=perm_mod
If the system is 64 bit then also add the following line: 
-a always,exit -F arch=b64 -S fchownat -F auid>=1000 -F auid!=unset -F key=perm_mod
 
To determine if the system is configured to audit calls to the
fchownat system call, run the following command:

$ sudo grep "fchownat" /etc/audit/audit.*

If the system is configured to audit this activity, it will return a line.

      Is it the case that no line is returned?
 SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215, SRG-OS-000064-GPOS-00033, SRG-OS-000466-GPOS-00210, SRG-OS-000458-GPOS-00203, SRG-OS-000474-GPOS-00219, SRG-APP-000091-CTR-000160, SRG-APP-000492-CTR-001220, SRG-APP-000493-CTR-001225, SRG-APP-000494-CTR-001230, SRG-APP-000500-CTR-001260, SRG-APP-000507-CTR-001295, SRG-APP-000495-CTR-001235, SRG-APP-000499-CTR-001255 AU-2(d), AU-12(c), CM-6(a)
xccdf_org.ssgproject.content_rule_audit_rules_dac_modification_fremovexattr medium Record Events that Modify the System's Discretionary Access Controls - fremovexattr The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users. At a minimum, the audit system should collect file permission changes for all users and root.

If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d: 
-a always,exit -F arch=b32 -S fremovexattr -F auid>=1000 -F auid!=unset -F key=perm_mod
-a always,exit -F arch=b32 -S fremovexattr -F auid=0 -F key=perm_mod


If the system is 64 bit then also add the following line: 
-a always,exit -F arch=b64 -S fremovexattr -F auid>=1000 -F auid!=unset -F key=perm_mod
-a always,exit -F arch=b64 -S fremovexattr -F auid=0 -F key=perm_mod


If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file: 
-a always,exit -F arch=b32 -S fremovexattr -F auid>=1000 -F auid!=unset -F key=perm_mod
-a always,exit -F arch=b32 -S fremovexattr -F auid=0 -F key=perm_mod


If the system is 64 bit then also add the following line: 
-a always,exit -F arch=b64 -S fremovexattr -F auid>=1000 -F auid!=unset -F key=perm_mod
-a always,exit -F arch=b64 -S fremovexattr -F auid=0 -F key=perm_mod
 
To determine if the system is configured to audit calls to the
fremovexattr system call, run the following command:

$ sudo grep "fremovexattr" /etc/audit/audit.*

If the system is configured to audit this activity, it will return a line.

      Is it the case that no line is returned?
 SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000458-GPOS-00203, SRG-OS-000462-GPOS-00206, SRG-OS-000463-GPOS-00207, SRG-OS-000471-GPOS-00215, SRG-OS-000474-GPOS-00219, SRG-OS-000466-GPOS-00210, SRG-OS-000468-GPOS-00212, SRG-OS-000064-GPOS-00033, SRG-APP-000091-CTR-000160, SRG-APP-000492-CTR-001220, SRG-APP-000493-CTR-001225, SRG-APP-000494-CTR-001230, SRG-APP-000500-CTR-001260, SRG-APP-000507-CTR-001295, SRG-APP-000495-CTR-001235, SRG-APP-000496-CTR-001240, SRG-APP-000497-CTR-001245, SRG-APP-000498-CTR-001250, SRG-APP-000499-CTR-001255 AU-2(d), AU-12(c), CM-6(a)
xccdf_org.ssgproject.content_rule_audit_rules_dac_modification_fsetxattr medium Record Events that Modify the System's Discretionary Access Controls - fsetxattr The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users. At a minimum, the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d: 
-a always,exit -F arch=b32 -S fsetxattr -F auid>=1000 -F auid!=unset -F key=perm_mod
-a always,exit -F arch=b32 -S fsetxattr -F auid=0 -F key=perm_mod
If the system is 64 bit then also add the following line: 
-a always,exit -F arch=b64 -S fsetxattr -F auid>=1000 -F auid!=unset -F key=perm_mod
-a always,exit -F arch=b64 -S fsetxattr -F auid=0 -F key=perm_mod
If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file: 
-a always,exit -F arch=b32 -S fsetxattr -F auid>=1000 -F auid!=unset -F key=perm_mod
-a always,exit -F arch=b32 -S fsetxattr -F auid=0 -F key=perm_mod
If the system is 64 bit then also add the following line: 
-a always,exit -F arch=b64 -S fsetxattr -F auid>=1000 -F auid!=unset -F key=perm_mod
-a always,exit -F arch=b64 -S fsetxattr -F auid=0 -F key=perm_mod
 
To determine if the system is configured to audit calls to the
fsetxattr system call, run the following command:

$ sudo grep "fsetxattr" /etc/audit/audit.*

If the system is configured to audit this activity, it will return a line.

      Is it the case that no line is returned?
 SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000458-GPOS-00203, SRG-OS-000462-GPOS-00206, SRG-OS-000463-GPOS-00207, SRG-OS-000466-GPOS-00210, SRG-OS-000468-GPOS-00212, SRG-OS-000471-GPOS-00215, SRG-OS-000474-GPOS-00219, SRG-OS-000064-GPOS-00033, SRG-APP-000091-CTR-000160, SRG-APP-000492-CTR-001220, SRG-APP-000493-CTR-001225, SRG-APP-000494-CTR-001230, SRG-APP-000500-CTR-001260, SRG-APP-000507-CTR-001295, SRG-APP-000495-CTR-001235, SRG-APP-000496-CTR-001240, SRG-APP-000497-CTR-001245, SRG-APP-000498-CTR-001250, SRG-APP-000501-CTR-001265, SRG-APP-000502-CTR-001270 AU-2(d), AU-12(c), CM-6(a)
xccdf_org.ssgproject.content_rule_audit_rules_dac_modification_lchown medium Record Events that Modify the System's Discretionary Access Controls - lchown The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users. At a minimum, the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d: 
-a always,exit -F arch=b32 -S lchown -F auid>=1000 -F auid!=unset -F key=perm_mod
If the system is 64 bit then also add the following line: 
-a always,exit -F arch=b64 -S lchown -F auid>=1000 -F auid!=unset -F key=perm_mod
If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file: 
-a always,exit -F arch=b32 -S lchown -F auid>=1000 -F auid!=unset -F key=perm_mod
If the system is 64 bit then also add the following line: 
-a always,exit -F arch=b64 -S lchown -F auid>=1000 -F auid!=unset -F key=perm_mod
 
To determine if the system is configured to audit calls to the
lchown system call, run the following command:

$ sudo grep "lchown" /etc/audit/audit.*

If the system is configured to audit this activity, it will return a line.

      Is it the case that no line is returned?
 SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215, SRG-OS-000064-GPOS-00033, SRG-OS-000466-GPOS-00210, SRG-OS-000458-GPOS-00203, SRG-OS-000474-GPOS-00219, SRG-APP-000091-CTR-000160, SRG-APP-000492-CTR-001220, SRG-APP-000493-CTR-001225, SRG-APP-000494-CTR-001230, SRG-APP-000500-CTR-001260, SRG-APP-000507-CTR-001295, SRG-APP-000495-CTR-001235, SRG-APP-000499-CTR-001255 AU-2(d), AU-12(c), CM-6(a)
xccdf_org.ssgproject.content_rule_audit_rules_dac_modification_lremovexattr medium Record Events that Modify the System's Discretionary Access Controls - lremovexattr The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users. At a minimum, the audit system should collect file permission changes for all users and root.

If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d: 
-a always,exit -F arch=b32 -S lremovexattr -F auid>=1000 -F auid!=unset -F key=perm_mod
-a always,exit -F arch=b32 -S lremovexattr -F auid=0 -F key=perm_mod


If the system is 64 bit then also add the following line: 
-a always,exit -F arch=b64 -S lremovexattr -F auid>=1000 -F auid!=unset -F key=perm_mod
-a always,exit -F arch=b64 -S lremovexattr -F auid=0 -F key=perm_mod


If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file: 
-a always,exit -F arch=b32 -S lremovexattr -F auid>=1000 -F auid!=unset -F key=perm_mod
-a always,exit -F arch=b32 -S lremovexattr -F auid=0 -F key=perm_mod


If the system is 64 bit then also add the following line: 
-a always,exit -F arch=b64 -S lremovexattr -F auid>=1000 -F auid!=unset -F key=perm_mod
-a always,exit -F arch=b64 -S lremovexattr -F auid=0 -F key=perm_mod
 
To determine if the system is configured to audit calls to the
lremovexattr system call, run the following command:

$ sudo grep "lremovexattr" /etc/audit/audit.*

If the system is configured to audit this activity, it will return a line.

      Is it the case that no line is returned?
 SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000458-GPOS-00203, SRG-OS-000462-GPOS-00206, SRG-OS-000463-GPOS-00207, SRG-OS-000468-GPOS-00212, SRG-OS-000471-GPOS-00215, SRG-OS-000474-GPOS-00219, SRG-OS-000466-GPOS-00210, SRG-OS-000064-GPOS-00033, SRG-APP-000091-CTR-000160, SRG-APP-000492-CTR-001220, SRG-APP-000493-CTR-001225, SRG-APP-000494-CTR-001230, SRG-APP-000500-CTR-001260, SRG-APP-000507-CTR-001295, SRG-APP-000495-CTR-001235, SRG-APP-000496-CTR-001240, SRG-APP-000497-CTR-001245, SRG-APP-000498-CTR-001250, SRG-APP-000499-CTR-001255, SRG-APP-000501-CTR-001265, SRG-APP-000502-CTR-001270 AU-2(d), AU-12(c), CM-6(a)
xccdf_org.ssgproject.content_rule_audit_rules_dac_modification_lsetxattr medium Record Events that Modify the System's Discretionary Access Controls - lsetxattr The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users. At a minimum, the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d: 
-a always,exit -F arch=b32 -S lsetxattr -F auid>=1000 -F auid!=unset -F key=perm_mod
-a always,exit -F arch=b32 -S lsetxattr -F auid=0 -F key=perm_mod
If the system is 64 bit then also add the following line: 
-a always,exit -F arch=b64 -S lsetxattr -F auid>=1000 -F auid!=unset -F key=perm_mod
-a always,exit -F arch=b64 -S lsetxattr -F auid=0 -F key=perm_mod
If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file: 
-a always,exit -F arch=b32 -S lsetxattr -F auid>=1000 -F auid!=unset -F key=perm_mod
-a always,exit -F arch=b32 -S lsetxattr -F auid=0 -F key=perm_mod
If the system is 64 bit then also add the following line: 
-a always,exit -F arch=b64 -S lsetxattr -F auid>=1000 -F auid!=unset -F key=perm_mod
-a always,exit -F arch=b64 -S lsetxattr -F auid=0 -F key=perm_mod
 
To determine if the system is configured to audit calls to the
lsetxattr system call, run the following command:

$ sudo grep "lsetxattr" /etc/audit/audit.*

If the system is configured to audit this activity, it will return a line.

      Is it the case that no line is returned?
 SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000458-GPOS-00203, SRG-OS-000462-GPOS-00206, SRG-OS-000463-GPOS-00207, SRG-OS-000466-GPOS-00210, SRG-OS-000468-GPOS-00212, SRG-OS-000471-GPOS-00215, SRG-OS-000474-GPOS-00219, SRG-OS-000064-GPOS-00033, SRG-APP-000091-CTR-000160, SRG-APP-000492-CTR-001220, SRG-APP-000493-CTR-001225, SRG-APP-000494-CTR-001230, SRG-APP-000500-CTR-001260, SRG-APP-000507-CTR-001295, SRG-APP-000495-CTR-001235, SRG-APP-000496-CTR-001240, SRG-APP-000497-CTR-001245, SRG-APP-000498-CTR-001250, SRG-APP-000501-CTR-001265, SRG-APP-000502-CTR-001270 AU-2(d), AU-12(c), CM-6(a)
xccdf_org.ssgproject.content_rule_audit_rules_dac_modification_removexattr medium Record Events that Modify the System's Discretionary Access Controls - removexattr The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users. At a minimum, the audit system should collect file permission changes for all users and root.

If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d: 
-a always,exit -F arch=b32 -S removexattr -F auid>=1000 -F auid!=unset -F key=perm_mod
-a always,exit -F arch=b32 -S removexattr -F auid=0 -F key=perm_mod


If the system is 64 bit then also add the following line: 
-a always,exit -F arch=b64 -S removexattr -F auid>=1000 -F auid!=unset -F key=perm_mod
-a always,exit -F arch=b64 -S removexattr -F auid=0 -F key=perm_mod


If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file: 
-a always,exit -F arch=b32 -S removexattr -F auid>=1000 -F auid!=unset -F key=perm_mod
-a always,exit -F arch=b32 -S removexattr -F auid=0 -F key=perm_mod


If the system is 64 bit then also add the following line: 
-a always,exit -F arch=b64 -S removexattr -F auid>=1000 -F auid!=unset -F key=perm_mod
-a always,exit -F arch=b64 -S removexattr -F auid=0 -F key=perm_mod
 
To determine if the system is configured to audit calls to the
removexattr system call, run the following command:

$ sudo grep "removexattr" /etc/audit/audit.*

If the system is configured to audit this activity, it will return a line.

      Is it the case that no line is returned?
 SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000458-GPOS-00203, SRG-OS-000462-GPOS-00206, SRG-OS-000463-GPOS-00207, SRG-OS-000468-GPOS-00212, SRG-OS-000471-GPOS-00215, SRG-OS-000474-GPOS-00219, SRG-OS-000466-GPOS-00210, SRG-OS-000064-GPOS-00033, SRG-APP-000091-CTR-000160, SRG-APP-000492-CTR-001220, SRG-APP-000493-CTR-001225, SRG-APP-000494-CTR-001230, SRG-APP-000500-CTR-001260, SRG-APP-000507-CTR-001295, SRG-APP-000495-CTR-001235, SRG-APP-000496-CTR-001240, SRG-APP-000497-CTR-001245, SRG-APP-000498-CTR-001250, SRG-APP-000499-CTR-001255, SRG-APP-000501-CTR-001265, SRG-APP-000502-CTR-001270 AU-2(d), AU-12(c), CM-6(a)
xccdf_org.ssgproject.content_rule_audit_rules_dac_modification_setxattr medium Record Events that Modify the System's Discretionary Access Controls - setxattr The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users. At a minimum, the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d: 
-a always,exit -F arch=b32 -S setxattr -F auid>=1000 -F auid!=unset -F key=perm_mod
-a always,exit -F arch=b32 -S setxattr -F auid=0 -F key=perm_mod
If the system is 64 bit then also add the following line: 
-a always,exit -F arch=b64 -S setxattr -F auid>=1000 -F auid!=unset -F key=perm_mod
-a always,exit -F arch=b64 -S setxattr -F auid=0 -F key=perm_mod
If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file: 
-a always,exit -F arch=b32 -S setxattr -F auid>=1000 -F auid!=unset -F key=perm_mod
-a always,exit -F arch=b32 -S setxattr -F auid=0 -F key=perm_mod
If the system is 64 bit then also add the following line: 
-a always,exit -F arch=b64 -S setxattr -F auid>=1000 -F auid!=unset -F key=perm_mod
-a always,exit -F arch=b64 -S setxattr -F auid=0 -F key=perm_mod
 
To determine if the system is configured to audit calls to the
setxattr system call, run the following command:

$ sudo grep "setxattr" /etc/audit/audit.*

If the system is configured to audit this activity, it will return a line.

      Is it the case that no line is returned?
 SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000466-GPOS-00210, SRG-OS-000471-GPOS-00215, SRG-OS-000064-GPOS-00033, SRG-OS-000458-GPOS-00203, SRG-APP-000091-CTR-000160, SRG-APP-000492-CTR-001220, SRG-APP-000493-CTR-001225, SRG-APP-000494-CTR-001230, SRG-APP-000500-CTR-001260, SRG-APP-000507-CTR-001295, SRG-APP-000495-CTR-001235 AU-2(d), AU-12(c), CM-6(a)
xccdf_org.ssgproject.content_rule_audit_rules_dac_modification_umount medium Record Events that Modify the System's Discretionary Access Controls - umount The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users. At a minimum, the audit system should collect file system umount changes. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d: 
-a always,exit -F arch=b32 -S umount -F auid>=1000 -F auid!=unset -F key=perm_mod
If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file: 
-a always,exit -F arch=b32 -S umount -F auid>=1000 -F auid!=unset -F key=perm_mod
 
Verify that Oracle Linux 9 generates an audit record for all uses of the "umount" and system call.
To determine if the system is configured to audit calls to the
"umount" system call, run the following command:

$ sudo grep "umount" /etc/audit/audit.*

If the system is configured to audit this activity, it will return a line like the following.
-a always,exit -F arch=b32 -S umount -F auid>=1000 -F auid!=unset -k privileged-umount
      Is it the case that the command does not return a line, or the line is commented out?
 SRG-OS-000037-GPOS-00015, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215, SRG-APP-000495-CTR-001235
xccdf_org.ssgproject.content_rule_audit_rules_dac_modification_umount2 medium Record Events that Modify the System's Discretionary Access Controls - umount2 The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users. At a minimum, the audit system should collect file system umount2 changes. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d: 
-a always,exit -F arch=b32 -S umount2 -F auid>=1000 -F auid!=unset -F key=perm_mod
If the system is 64 bit then also add the following line: 
-a always,exit -F arch=b64 -S umount2 -F auid>=1000 -F auid!=unset -F key=perm_mod
If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file: 
-a always,exit -F arch=b32 -S umount2 -F auid>=1000 -F auid!=unset -F key=perm_mod
If the system is 64 bit then also add the following line: 
-a always,exit -F arch=b64 -S umount2 -F auid>=1000 -F auid!=unset -F key=perm_mod
 
To determine if the system is configured to audit calls to the
umount2 system call, run the following command:

$ sudo grep "umount2" /etc/audit/audit.*

If the system is configured to audit this activity, it will return a line.

      Is it the case that no line is returned?
 SRG-OS-000037-GPOS-00015, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215, SRG-APP-000495-CTR-001235
xccdf_org.ssgproject.content_rule_audit_rules_etc_cron_d medium Ensure auditd Collects Changes to Cron Jobs - /etc/cron.d/ The actions taken by system administrators should be audited to keep a record of what was executed on the system, as well as, for accountability purposes. Editing the sudoers file may be sign of an attacker trying to establish persistent methods to a system, auditing the editing of the sudoers files mitigates this risk. At a minimum, the audit system should collect administrator actions for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following lines to a file with suffix .rules in the directory /etc/audit/rules.d: 
-w /etc/cron.d/ -p wa -k cronjobs
If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules: 
-w /etc/cron.d/ -p wa -k cronjobs
 
Verify Oracle Linux 9 generates audit records for all events that affect "/etc/cron.d/" with the following command:

$ sudo auditctl -l | grep /etc/cron.d/

-w /etc/cron.d/ -p wa -k cronjobs
      Is it the case that the command does not return a line, or the line is commented out?
 SRG-OS-000471-GPOS-00215
xccdf_org.ssgproject.content_rule_audit_rules_execution_chacl medium Record Any Attempts to Run chacl Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). At a minimum, the audit system should collect the execution of privileged commands for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add a line of the following form to a file with suffix .rules in the directory /etc/audit/rules.d: 
-a always,exit -F path=/usr/bin/chacl -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged
If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules: 
-a always,exit -F path=/usr/bin/chacl -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged
 
Verify that Oracle Linux 9 is configured to audit the execution of the "chacl" command with the following command:

$ sudo auditctl -l | grep chacl

-a always,exit -F path=/usr/bin/chacl -F perm=x -F auid>=1000 -F auid!=unset -k perm_mod
      Is it the case that the command does not return a line, or the line is commented out?
 SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215, SRG-OS-000466-GPOS-00210, SRG-APP-000495-CTR-001235, SRG-APP-000499-CTR-001255
xccdf_org.ssgproject.content_rule_audit_rules_execution_chcon medium Record Any Attempts to Run chcon Misuse of privileged functions, either intentionally or unintentionally by authorized users, or by unauthorized external entities that have compromised system accounts, is a serious and ongoing concern and can have significant adverse impacts on organizations. Auditing the use of privileged functions is one way to detect such misuse and identify the risk from insider and advanced persistent threats.

Privileged programs are subject to escalation-of-privilege attacks, which attempt to subvert their normal role of providing some necessary but limited capability. As such, motivation exists to monitor these programs for unusual activity.		 At a minimum, the audit system should collect the execution of privileged commands for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add a line of the following form to a file with suffix .rules in the directory /etc/audit/rules.d: 
-a always,exit -F path=/usr/bin/chcon -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged
If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules: 
-a always,exit -F path=/usr/bin/chcon -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged
 
Verify that Oracle Linux 9 is configured to audit the execution of the "chcon" command with the following command:

$ sudo auditctl -l | grep chcon

-a always,exit -F path=/usr/bin/chcon -F perm=x -F auid>=1000 -F auid!=unset -k perm_mod
      Is it the case that the command does not return a line, or the line is commented out?
 SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000468-GPOS-00212, SRG-OS-000471-GPOS-00215, SRG-OS-000463-GPOS-00207, SRG-OS-000465-GPOS-00209, SRG-APP-000495-CTR-001235, SRG-APP-000496-CTR-001240, SRG-APP-000497-CTR-001245, SRG-APP-000498-CTR-001250, SRG-APP-000501-CTR-001265, SRG-APP-000502-CTR-001270 AU-2(d), AU-12(c), AC-6(9), CM-6(a)
xccdf_org.ssgproject.content_rule_audit_rules_execution_semanage medium Record Any Attempts to Run semanage Misuse of privileged functions, either intentionally or unintentionally by authorized users, or by unauthorized external entities that have compromised system accounts, is a serious and ongoing concern and can have significant adverse impacts on organizations. Auditing the use of privileged functions is one way to detect such misuse and identify the risk from insider and advanced persistent threats.

Privileged programs are subject to escalation-of-privilege attacks, which attempt to subvert their normal role of providing some necessary but limited capability. As such, motivation exists to monitor these programs for unusual activity.		 At a minimum, the audit system should collect the execution of privileged commands for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add a line of the following form to a file with suffix .rules in the directory /etc/audit/rules.d: 
-a always,exit -F path=/usr/sbin/semanage -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged
If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules: 
-a always,exit -F path=/usr/sbin/semanage -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged
 
Verify that Oracle Linux 9 is configured to audit the execution of the "semanage" command with the following command:

$ sudo auditctl -l | grep semanage

-a always,exit -F path=/usr/sbin/semanage -F perm=x -F auid>=1000 -F auid!=unset -k privileged-unix-update
      Is it the case that the command does not return a line, or the line is commented out?
 SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215, SRG-OS-000463-GPOS-00207, SRG-OS-000465-GPOS-00209, SRG-APP-000495-CTR-001235, SRG-APP-000496-CTR-001240, SRG-APP-000497-CTR-001245, SRG-APP-000498-CTR-001250 AC-2(4), AU-2(d), AU-12(c), AC-6(9), CM-6(a)
xccdf_org.ssgproject.content_rule_audit_rules_execution_setfacl medium Record Any Attempts to Run setfacl Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). At a minimum, the audit system should collect the execution of privileged commands for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add a line of the following form to a file with suffix .rules in the directory /etc/audit/rules.d: 
-a always,exit -F path=/usr/bin/setfacl -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged
If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules: 
-a always,exit -F path=/usr/bin/setfacl -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged
 
Verify that Oracle Linux 9 is configured to audit the execution of the "setfacl" command with the following command:

$ sudo auditctl -l | grep setfacl

-a always,exit -F path=/usr/bin/setfacl -F perm=x -F auid>=1000 -F auid!=unset -k perm_mod
      Is it the case that the command does not return a line, or the line is commented out?
 SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215, SRG-APP-000495-CTR-001235
xccdf_org.ssgproject.content_rule_audit_rules_execution_setfiles medium Record Any Attempts to Run setfiles Misuse of privileged functions, either intentionally or unintentionally by authorized users, or by unauthorized external entities that have compromised system accounts, is a serious and ongoing concern and can have significant adverse impacts on organizations. Auditing the use of privileged functions is one way to detect such misuse and identify the risk from insider and advanced persistent threats.

Privileged programs are subject to escalation-of-privilege attacks, which attempt to subvert their normal role of providing some necessary but limited capability. As such, motivation exists to monitor these programs for unusual activity.		 At a minimum, the audit system should collect the execution of privileged commands for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add a line of the following form to a file with suffix .rules in the directory /etc/audit/rules.d: 
-a always,exit -F path=/usr/sbin/setfiles -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged
If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules: 
-a always,exit -F path=/usr/sbin/setfiles -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged
 
Verify that Oracle Linux 9 is configured to audit the execution of the "setfiles" command with the following command:

$ sudo auditctl -l | grep setfiles

-a always,exit -F path=/usr/sbin/setfiles -F perm=x -F auid>=1000 -F auid!=unset -k privileged-unix-update
      Is it the case that the command does not return a line, or the line is commented out?
 SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215, SRG-OS-000463-GPOS-00207, SRG-OS-000465-GPOS-00209, SRG-APP-000495-CTR-001235, SRG-APP-000496-CTR-001240, SRG-APP-000497-CTR-001245, SRG-APP-000498-CTR-001250 AU-2(d), AU-12(c), AC-6(9), CM-6(a)
xccdf_org.ssgproject.content_rule_audit_rules_execution_setsebool medium Record Any Attempts to Run setsebool Misuse of privileged functions, either intentionally or unintentionally by authorized users, or by unauthorized external entities that have compromised system accounts, is a serious and ongoing concern and can have significant adverse impacts on organizations. Auditing the use of privileged functions is one way to detect such misuse and identify the risk from insider and advanced persistent threats.

Privileged programs are subject to escalation-of-privilege attacks, which attempt to subvert their normal role of providing some necessary but limited capability. As such, motivation exists to monitor these programs for unusual activity.		 At a minimum, the audit system should collect the execution of privileged commands for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add a line of the following form to a file with suffix .rules in the directory /etc/audit/rules.d: 
-a always,exit -F path=/usr/sbin/setsebool -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged
If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules: 
-a always,exit -F path=/usr/sbin/setsebool -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged
 
Verify that Oracle Linux 9 is configured to audit the execution of the "setsebool" command with the following command:

$ sudo auditctl -l | grep setsebool

-a always,exit -F path=/usr/sbin/setsebool -F perm=x -F auid>=1000 -F auid!=unset -k privileged
      Is it the case that the command does not return a line, or the line is commented out?
 SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215, SRG-OS-000463-GPOS-00207, SRG-OS-000465-GPOS-00209, SRG-APP-000495-CTR-001235, SRG-APP-000496-CTR-001240, SRG-APP-000497-CTR-001245, SRG-APP-000498-CTR-001250 AU-2(d), AU-12(c), AC-6(9), CM-6(a)
xccdf_org.ssgproject.content_rule_audit_rules_file_deletion_events_rename medium Ensure auditd Collects File Deletion Events by User - rename Auditing file deletions will create an audit trail for files that are removed from the system. The audit trail could aid in system troubleshooting, as well as, detecting malicious processes that attempt to delete log files to conceal their presence. At a minimum, the audit system should collect file deletion events for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d, setting ARCH to either b32 for 32-bit system, or having two lines for both b32 and b64 in case your system is 64-bit: 
-a always,exit -F arch=ARCH -S rename -F auid>=1000 -F auid!=unset -F key=delete
If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file, setting ARCH to either b32 for 32-bit system, or having two lines for both b32 and b64 in case your system is 64-bit: 
-a always,exit -F arch=ARCH -S rename -F auid>=1000 -F auid!=unset -F key=delete
 
To determine if the system is configured to audit calls to the
rename system call, run the following command:

$ sudo grep "rename" /etc/audit/audit.*

If the system is configured to audit this activity, it will return a line.

      Is it the case that no line is returned?
 SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215, SRG-OS-000466-GPOS-00210, SRG-OS-000467-GPOS-00211, SRG-OS-000468-GPOS-00212, SRG-APP-000495-CTR-001235, SRG-APP-000499-CTR-001255, SRG-APP-000501-CTR-001265, SRG-APP-000502-CTR-001270 AU-2(d), AU-12(c), CM-6(a)
xccdf_org.ssgproject.content_rule_audit_rules_file_deletion_events_renameat medium Ensure auditd Collects File Deletion Events by User - renameat Auditing file deletions will create an audit trail for files that are removed from the system. The audit trail could aid in system troubleshooting, as well as, detecting malicious processes that attempt to delete log files to conceal their presence. At a minimum, the audit system should collect file deletion events for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d, setting ARCH to either b32 for 32-bit system, or having two lines for both b32 and b64 in case your system is 64-bit: 
-a always,exit -F arch=ARCH -S renameat -F auid>=1000 -F auid!=unset -F key=delete
If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file, setting ARCH to either b32 for 32-bit system, or having two lines for both b32 and b64 in case your system is 64-bit: 
-a always,exit -F arch=ARCH -S renameat -F auid>=1000 -F auid!=unset -F key=delete
 
To determine if the system is configured to audit calls to the
renameat system call, run the following command:

$ sudo grep "renameat" /etc/audit/audit.*

If the system is configured to audit this activity, it will return a line.

      Is it the case that no line is returned?
 SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215, SRG-OS-000466-GPOS-00210, SRG-OS-000467-GPOS-00211, SRG-OS-000468-GPOS-00212, SRG-APP-000495-CTR-001235, SRG-APP-000499-CTR-001255, SRG-APP-000501-CTR-001265, SRG-APP-000502-CTR-001270 AU-2(d), AU-12(c), CM-6(a)
xccdf_org.ssgproject.content_rule_audit_rules_file_deletion_events_rmdir medium Ensure auditd Collects File Deletion Events by User - rmdir Auditing file deletions will create an audit trail for files that are removed from the system. The audit trail could aid in system troubleshooting, as well as, detecting malicious processes that attempt to delete log files to conceal their presence. At a minimum, the audit system should collect file deletion events for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d, setting ARCH to either b32 for 32-bit system, or having two lines for both b32 and b64 in case your system is 64-bit: 
-a always,exit -F arch=ARCH -S rmdir -F auid>=1000 -F auid!=unset -F key=delete
If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file, setting ARCH to either b32 for 32-bit system, or having two lines for both b32 and b64 in case your system is 64-bit: 
-a always,exit -F arch=ARCH -S rmdir -F auid>=1000 -F auid!=unset -F key=delete
 
To determine if the system is configured to audit calls to the
rmdir system call, run the following command:

$ sudo grep "rmdir" /etc/audit/audit.*

If the system is configured to audit this activity, it will return a line.

      Is it the case that no line is returned?
 SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215, SRG-OS-000466-GPOS-00210, SRG-OS-000467-GPOS-00211, SRG-OS-000468-GPOS-00212, SRG-APP-000495-CTR-001235, SRG-APP-000499-CTR-001255, SRG-APP-000501-CTR-001265, SRG-APP-000502-CTR-001270 AU-2(d), AU-12(c), CM-6(a)
xccdf_org.ssgproject.content_rule_audit_rules_file_deletion_events_unlink medium Ensure auditd Collects File Deletion Events by User - unlink Auditing file deletions will create an audit trail for files that are removed from the system. The audit trail could aid in system troubleshooting, as well as, detecting malicious processes that attempt to delete log files to conceal their presence. At a minimum, the audit system should collect file deletion events for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d, setting ARCH to either b32 for 32-bit system, or having two lines for both b32 and b64 in case your system is 64-bit: 
-a always,exit -F arch=ARCH -S unlink -F auid>=1000 -F auid!=unset -F key=delete
If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file, setting ARCH to either b32 for 32-bit system, or having two lines for both b32 and b64 in case your system is 64-bit: 
-a always,exit -F arch=ARCH -S unlink -F auid>=1000 -F auid!=unset -F key=delete
 
To determine if the system is configured to audit calls to the
unlink system call, run the following command:

$ sudo grep "unlink" /etc/audit/audit.*

If the system is configured to audit this activity, it will return a line.

      Is it the case that no line is returned?
 SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215, SRG-OS-000466-GPOS-00210, SRG-OS-000467-GPOS-00211, SRG-OS-000468-GPOS-00212, SRG-APP-000495-CTR-001235, SRG-APP-000499-CTR-001255, SRG-APP-000501-CTR-001265, SRG-APP-000502-CTR-001270 AU-2(d), AU-12(c), CM-6(a)
xccdf_org.ssgproject.content_rule_audit_rules_file_deletion_events_unlinkat medium Ensure auditd Collects File Deletion Events by User - unlinkat Auditing file deletions will create an audit trail for files that are removed from the system. The audit trail could aid in system troubleshooting, as well as, detecting malicious processes that attempt to delete log files to conceal their presence. At a minimum, the audit system should collect file deletion events for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d, setting ARCH to either b32 for 32-bit system, or having two lines for both b32 and b64 in case your system is 64-bit: 
-a always,exit -F arch=ARCH -S unlinkat -F auid>=1000 -F auid!=unset -F key=delete
If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file, setting ARCH to either b32 for 32-bit system, or having two lines for both b32 and b64 in case your system is 64-bit: 
-a always,exit -F arch=ARCH -S unlinkat -F auid>=1000 -F auid!=unset -F key=delete
 
To determine if the system is configured to audit calls to the
unlinkat system call, run the following command:

$ sudo grep "unlinkat" /etc/audit/audit.*

If the system is configured to audit this activity, it will return a line.

      Is it the case that no line is returned?
 SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215, SRG-OS-000466-GPOS-00210, SRG-OS-000467-GPOS-00211, SRG-OS-000468-GPOS-00212, SRG-APP-000495-CTR-001235, SRG-APP-000499-CTR-001255, SRG-APP-000501-CTR-001265, SRG-APP-000502-CTR-001270 AU-2(d), AU-12(c), CM-6(a)
xccdf_org.ssgproject.content_rule_audit_rules_immutable medium Make the auditd Configuration Immutable Making the audit configuration immutable prevents accidental as well as malicious modification of the audit rules, although it may be problematic if legitimate changes are needed during system operation. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d in order to make the auditd configuration immutable: 
-e 2
If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file in order to make the auditd configuration immutable: 
-e 2
With this setting, a reboot will be required to change any audit rules.		 
Verify the audit system prevents unauthorized changes with the following command:

$ sudo grep "^\s*[^#]" /etc/audit/audit.rules | tail -1
-e 2


      Is it the case that the audit system is not set to be immutable by adding the "-e 2" option to the end of "/etc/audit/audit.rules"?
 SRG-OS-000057-GPOS-00027, SRG-OS-000058-GPOS-00028, SRG-OS-000059-GPOS-00029, SRG-APP-000119-CTR-000245, SRG-APP-000120-CTR-000250 AC-6(9), CM-6(a)
xccdf_org.ssgproject.content_rule_audit_rules_immutable_login_uids medium Configure immutable Audit login UIDs If modification of login UIDs is not prevented, they can be changed by unprivileged users and make auditing complicated or impossible. Configure kernel to prevent modification of login UIDs once they are set. Changing login UIDs while this configuration is enforced requires special capabilities which are not available to unprivileged users. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d in order to make login UIDs immutable: 
--loginuid-immutable
If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file in order to make login UIDs immutable: 
--loginuid-immutable
 
To determine if the system is configured to make login UIDs immutable, run
one of the following commands.
If the auditd daemon is configured to use the
augenrules program to read audit rules during daemon startup (the
default), run the following:

sudo grep immutable /etc/audit/rules.d/*.rules

If the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, run the following command:

sudo grep immutable /etc/audit/audit.rules

The following line should be returned:

--loginuid-immutable

      Is it the case that the system is not configured to make login UIDs immutable?
 SRG-OS-000462-GPOS-00206, SRG-OS-000475-GPOS-00220, SRG-OS-000057-GPOS-00027, SRG-OS-000058-GPOS-00028, SRG-OS-000059-GPOS-00029
xccdf_org.ssgproject.content_rule_audit_rules_kernel_module_loading_delete medium Ensure auditd Collects Information on Kernel Module Unloading - delete_module The removal of kernel modules can be used to alter the behavior of the kernel and potentially introduce malicious code into kernel space. It is important to have an audit trail of modules that have been introduced into the kernel. To capture kernel module loading and unloading events, use the following line, setting ARCH to either b32 for 32-bit system, or having two lines for both b32 and b64 in case your system is 64-bit: 
-a always,exit -F arch=ARCH -S delete_module -F auid>=1000 -F auid!=unset -F key=modules
Place to add the line depends on a way auditd daemon is configured. If it is configured to use the augenrules program (the default), add the line to a file with suffix .rules in the directory /etc/audit/rules.d. If the auditd daemon is configured to use the auditctl utility, add the line to file /etc/audit/audit.rules.		 
To determine if the system is configured to audit calls to the
delete_module system call, run the following command:

$ sudo grep "delete_module" /etc/audit/audit.*

If the system is configured to audit this activity, it will return a line.

      Is it the case that no line is returned?
 SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215, SRG-OS-000471-GPOS-00216, SRG-OS-000477-GPOS-00222, SRG-APP-000495-CTR-001235, SRG-APP-000504-CTR-001280 AU-2(d), AU-12(c), AC-6(9), CM-6(a)
xccdf_org.ssgproject.content_rule_audit_rules_kernel_module_loading_finit medium Ensure auditd Collects Information on Kernel Module Loading and Unloading - finit_module The addition/removal of kernel modules can be used to alter the behavior of the kernel and potentially introduce malicious code into kernel space. It is important to have an audit trail of modules that have been introduced into the kernel. To capture kernel module loading and unloading events, use the following line, setting ARCH to either b32 for 32-bit system, or having two lines for both b32 and b64 in case your system is 64-bit: 
-a always,exit -F arch=ARCH -S finit_module -F auid>=1000 -F auid!=unset -F key=modules
Place to add the line depends on a way auditd daemon is configured. If it is configured to use the augenrules program (the default), add the line to a file with suffix .rules in the directory /etc/audit/rules.d. If the auditd daemon is configured to use the auditctl utility, add the line to file /etc/audit/audit.rules.		 
To determine if the system is configured to audit calls to the
finit_module system call, run the following command:

$ sudo grep "finit_module" /etc/audit/audit.*

If the system is configured to audit this activity, it will return a line.

      Is it the case that no line is returned?
 SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215, SRG-OS-000471-GPOS-00216, SRG-OS-000477-GPOS-00222, SRG-APP-000495-CTR-001235, SRG-APP-000504-CTR-001280 AU-2(d), AU-12(c), AC-6(9), CM-6(a)
xccdf_org.ssgproject.content_rule_audit_rules_kernel_module_loading_init medium Ensure auditd Collects Information on Kernel Module Loading - init_module The addition of kernel modules can be used to alter the behavior of the kernel and potentially introduce malicious code into kernel space. It is important to have an audit trail of modules that have been introduced into the kernel. To capture kernel module loading and unloading events, use the following line, setting ARCH to either b32 for 32-bit system, or having two lines for both b32 and b64 in case your system is 64-bit: 
-a always,exit -F arch=ARCH -S init_module -F auid>=1000 -F auid!=unset -F key=modules
Place to add the line depends on a way auditd daemon is configured. If it is configured to use the augenrules program (the default), add the line to a file with suffix .rules in the directory /etc/audit/rules.d. If the auditd daemon is configured to use the auditctl utility, add the line to file /etc/audit/audit.rules.		 
To determine if the system is configured to audit calls to the
init_module system call, run the following command:

$ sudo grep "init_module" /etc/audit/audit.*

If the system is configured to audit this activity, it will return a line.

      Is it the case that no line is returned?
 SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215, SRG-OS-000471-GPOS-00216, SRG-OS-000477-GPOS-00222, SRG-APP-000495-CTR-001235, SRG-APP-000504-CTR-001280 AU-2(d), AU-12(c), AC-6(9), CM-6(a)
xccdf_org.ssgproject.content_rule_audit_rules_login_events_faillock medium Record Attempts to Alter Logon and Logout Events - faillock Manual editing of these files may indicate nefarious activity, such as an attacker attempting to remove evidence of an intrusion. The audit system already collects login information for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following lines to a file with suffix .rules in the directory /etc/audit/rules.d: 
-w None -p wa -k logins
If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules: 
-w None -p wa -k logins
 
Verify Oracle Linux 9 generates audit records for all events that affect "None" with the following command:

$ sudo auditctl -l | grep None

-w None -p wa -k logins
      Is it the case that the command does not return a line, or the line is commented out?
 SRG-OS-000392-GPOS-00172, SRG-OS-000470-GPOS-00214, SRG-OS-000473-GPOS-00218, SRG-APP-000503-CTR-001275, SRG-APP-000506-CTR-001290 AU-2(d), AU-12(c), AC-6(9), CM-6(a)
xccdf_org.ssgproject.content_rule_audit_rules_login_events_lastlog medium Record Attempts to Alter Logon and Logout Events - lastlog Manual editing of these files may indicate nefarious activity, such as an attacker attempting to remove evidence of an intrusion. The audit system already collects login information for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following lines to a file with suffix .rules in the directory /etc/audit/rules.d: 
-w /var/log/lastlog -p wa -k logins
If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules: 
-w /var/log/lastlog -p wa -k logins
 
Verify Oracle Linux 9 generates audit records for all events that affect "/var/log/lastlog" with the following command:

$ sudo auditctl -l | grep /var/log/lastlog

-w /var/log/lastlog -p wa -k logins
      Is it the case that the command does not return a line, or the line is commented out?
 SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215, SRG-OS-000473-GPOS-00218, SRG-OS-000470-GPOS-00214, SRG-APP-000495-CTR-001235, SRG-APP-000503-CTR-001275, SRG-APP-000506-CTR-001290 AU-2(d), AU-12(c), AC-6(9), CM-6(a)
xccdf_org.ssgproject.content_rule_audit_rules_login_events_tallylog medium Record Attempts to Alter Logon and Logout Events - tallylog Manual editing of these files may indicate nefarious activity, such as an attacker attempting to remove evidence of an intrusion. The audit system already collects login information for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following lines to a file with suffix .rules in the directory /etc/audit/rules.d: 
-w /var/log/tallylog -p wa -k logins
If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules: 
-w /var/log/tallylog -p wa -k logins
 
Verify Oracle Linux 9 generates audit records for all events that affect "/var/log/tallylog" with the following command:

$ sudo auditctl -l | grep /var/log/tallylog

-w /var/log/tallylog -p wa -k logins
      Is it the case that the command does not return a line, or the line is commented out?
 SRG-OS-000392-GPOS-00172, SRG-OS-000470-GPOS-00214, SRG-OS-000473-GPOS-00218, SRG-APP-000503-CTR-001275 AU-2(d), AU-12(c), AC-6(9), CM-6(a)
xccdf_org.ssgproject.content_rule_audit_rules_privileged_commands_chage medium Ensure auditd Collects Information on the Use of Privileged Commands - chage Misuse of privileged functions, either intentionally or unintentionally by authorized users, or by unauthorized external entities that have compromised system accounts, is a serious and ongoing concern and can have significant adverse impacts on organizations. Auditing the use of privileged functions is one way to detect such misuse and identify the risk from insider and advanced persistent threats.

Privileged programs are subject to escalation-of-privilege attacks, which attempt to subvert their normal role of providing some necessary but limited capability. As such, motivation exists to monitor these programs for unusual activity.		 At a minimum, the audit system should collect the execution of privileged commands for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add a line of the following form to a file with suffix .rules in the directory /etc/audit/rules.d: 
-a always,exit -F path=/usr/bin/chage -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged
If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules: 
-a always,exit -F path=/usr/bin/chage -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged
 
Verify that Oracle Linux 9 is configured to audit the execution of the "chage" command with the following command:

$ sudo auditctl -l | grep chage

-a always,exit -F path=/usr/bin/chage -F perm=x -F auid>=1000 -F auid!=unset -k privileged-chage
      Is it the case that the command does not return a line, or the line is commented out?
 SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000468-GPOS-00212, SRG-OS-000471-GPOS-00215, SRG-APP-000029-CTR-000085, SRG-APP-000495-CTR-001235, SRG-APP-000501-CTR-001265, SRG-APP-000502-CTR-001270 AC-2(4), AU-2(d), AU-12(c), AC-6(9), CM-6(a)
xccdf_org.ssgproject.content_rule_audit_rules_privileged_commands_chsh medium Ensure auditd Collects Information on the Use of Privileged Commands - chsh Misuse of privileged functions, either intentionally or unintentionally by authorized users, or by unauthorized external entities that have compromised system accounts, is a serious and ongoing concern and can have significant adverse impacts on organizations. Auditing the use of privileged functions is one way to detect such misuse and identify the risk from insider and advanced persistent threats.

Privileged programs are subject to escalation-of-privilege attacks, which attempt to subvert their normal role of providing some necessary but limited capability. As such, motivation exists to monitor these programs for unusual activity.		 At a minimum, the audit system should collect the execution of privileged commands for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add a line of the following form to a file with suffix .rules in the directory /etc/audit/rules.d: 
-a always,exit -F path=/usr/bin/chsh -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged
If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules: 
-a always,exit -F path=/usr/bin/chsh -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged
 
Verify that Oracle Linux 9 is configured to audit the execution of the "chsh" command with the following command:

$ sudo auditctl -l | grep chsh

-a always,exit -F path=/usr/bin/chsh -F perm=x -F auid>=1000 -F auid!=unset -k privileged-chsh
      Is it the case that the command does not return a line, or the line is commented out?
 SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215, SRG-APP-000495-CTR-001235 AC-2(4), AU-2(d), AU-12(c), AC-6(9), CM-6(a)
xccdf_org.ssgproject.content_rule_audit_rules_privileged_commands_crontab medium Ensure auditd Collects Information on the Use of Privileged Commands - crontab Misuse of privileged functions, either intentionally or unintentionally by authorized users, or by unauthorized external entities that have compromised system accounts, is a serious and ongoing concern and can have significant adverse impacts on organizations. Auditing the use of privileged functions is one way to detect such misuse and identify the risk from insider and advanced persistent threats.

Privileged programs are subject to escalation-of-privilege attacks, which attempt to subvert their normal role of providing some necessary but limited capability. As such, motivation exists to monitor these programs for unusual activity.		 At a minimum, the audit system should collect the execution of privileged commands for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add a line of the following form to a file with suffix .rules in the directory /etc/audit/rules.d: 
-a always,exit -F path=/usr/bin/crontab -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged
If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules: 
-a always,exit -F path=/usr/bin/crontab -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged
 
Verify that Oracle Linux 9 is configured to audit the execution of the "crontab" command with the following command:

$ sudo auditctl -l | grep crontab

-a always,exit -F path=/usr/bin/crontab -F perm=x -F auid>=1000 -F auid!=unset -k privileged-crontab
      Is it the case that the command does not return a line, or the line is commented out?
 SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215, SRG-APP-000495-CTR-001235 AU-2(d), AU-12(c), AC-6(9), CM-6(a)
xccdf_org.ssgproject.content_rule_audit_rules_privileged_commands_gpasswd medium Ensure auditd Collects Information on the Use of Privileged Commands - gpasswd Misuse of privileged functions, either intentionally or unintentionally by authorized users, or by unauthorized external entities that have compromised system accounts, is a serious and ongoing concern and can have significant adverse impacts on organizations. Auditing the use of privileged functions is one way to detect such misuse and identify the risk from insider and advanced persistent threats.

Privileged programs are subject to escalation-of-privilege attacks, which attempt to subvert their normal role of providing some necessary but limited capability. As such, motivation exists to monitor these programs for unusual activity.		 At a minimum, the audit system should collect the execution of privileged commands for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add a line of the following form to a file with suffix .rules in the directory /etc/audit/rules.d: 
-a always,exit -F path=/usr/bin/gpasswd -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged
If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules: 
-a always,exit -F path=/usr/bin/gpasswd -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged
 
Verify that Oracle Linux 9 is configured to audit the execution of the "gpasswd" command with the following command:

$ sudo auditctl -l | grep gpasswd

-a always,exit -F path=/usr/bin/gpasswd -F perm=x -F auid>=1000 -F auid!=unset -k privileged-gpasswd
      Is it the case that the command does not return a line, or the line is commented out?
 SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215, SRG-APP-000029-CTR-000085, SRG-APP-000495-CTR-001235 AC-2(4), AU-2(d), AU-12(c), AC-6(9), CM-6(a)
xccdf_org.ssgproject.content_rule_audit_rules_privileged_commands_kmod medium Ensure auditd Collects Information on the Use of Privileged Commands - kmod Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). At a minimum, the audit system should collect the execution of privileged commands for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add a line of the following form to a file with suffix .rules in the directory /etc/audit/rules.d: 
-a always,exit -F path=/usr/bin/kmod -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged
If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules: 
-a always,exit -F path=/usr/bin/kmod -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged
 
Verify that Oracle Linux 9 is configured to audit the execution of the "kmod" command with the following command:

$ sudo auditctl -l | grep kmod

-a always,exit -F path=/usr/bin/kmod -F perm=x -F auid>=1000 -F auid!=unset -k privileged-kmod
      Is it the case that the command does not return a line, or the line is commented out?
 SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215, SRG-OS-000471-GPOS-00216, SRG-OS-000477-GPOS-00222, SRG-APP-000495-CTR-001235, SRG-APP-000504-CTR-001280 AU-3, AU-3.1, AU-12(a), AU-12.1(ii), AU-12.1(iv)AU-12(c), MA-4(1)(a)
xccdf_org.ssgproject.content_rule_audit_rules_privileged_commands_mount medium Ensure auditd Collects Information on the Use of Privileged Commands - mount Misuse of privileged functions, either intentionally or unintentionally by authorized users, or by unauthorized external entities that have compromised system accounts, is a serious and ongoing concern and can have significant adverse impacts on organizations. Auditing the use of privileged functions is one way to detect such misuse and identify the risk from insider and advanced persistent threats.

Privileged programs are subject to escalation-of-privilege attacks, which attempt to subvert their normal role of providing some necessary but limited capability. As such, motivation exists to monitor these programs for unusual activity.		 At a minimum, the audit system should collect the execution of privileged commands for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add a line of the following form to a file with suffix .rules in the directory /etc/audit/rules.d: 
-a always,exit -F path=/usr/bin/mount -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged
If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules: 
-a always,exit -F path=/usr/bin/mount -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged
 
Verify that Oracle Linux 9 is configured to audit the execution of the "mount" command with the following command:

$ sudo auditctl -l | grep mount

-a always,exit -F path=/usr/bin/mount -F perm=x -F auid>=1000 -F auid!=unset -k privileged-mount
      Is it the case that the command does not return a line, or the line is commented out?
 SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215, SRG-APP-000029-CTR-000085 AU-2(d), AU-12(c), AC-6(9), CM-6(a)
xccdf_org.ssgproject.content_rule_audit_rules_privileged_commands_newgrp medium Ensure auditd Collects Information on the Use of Privileged Commands - newgrp Misuse of privileged functions, either intentionally or unintentionally by authorized users, or by unauthorized external entities that have compromised system accounts, is a serious and ongoing concern and can have significant adverse impacts on organizations. Auditing the use of privileged functions is one way to detect such misuse and identify the risk from insider and advanced persistent threats.

Privileged programs are subject to escalation-of-privilege attacks, which attempt to subvert their normal role of providing some necessary but limited capability. As such, motivation exists to monitor these programs for unusual activity.		 At a minimum, the audit system should collect the execution of privileged commands for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add a line of the following form to a file with suffix .rules in the directory /etc/audit/rules.d: 
-a always,exit -F path=/usr/bin/newgrp -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged
If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules: 
-a always,exit -F path=/usr/bin/newgrp -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged
 
Verify that Oracle Linux 9 is configured to audit the execution of the "newgrp" command with the following command:

$ sudo auditctl -l | grep newgrp

-a always,exit -F path=/usr/bin/newgrp -F perm=x -F auid>=1000 -F auid!=unset -k privileged-newgrp
      Is it the case that the command does not return a line, or the line is commented out?
 SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215, SRG-APP-000029-CTR-000085, SRG-APP-000495-CTR-001235 AC-2(4), AU-2(d), AU-12(c), AC-6(9), CM-6(a)
xccdf_org.ssgproject.content_rule_audit_rules_privileged_commands_pam_timestamp_check medium Ensure auditd Collects Information on the Use of Privileged Commands - pam_timestamp_check Misuse of privileged functions, either intentionally or unintentionally by authorized users, or by unauthorized external entities that have compromised system accounts, is a serious and ongoing concern and can have significant adverse impacts on organizations. Auditing the use of privileged functions is one way to detect such misuse and identify the risk from insider and advanced persistent threats.

Privileged programs are subject to escalation-of-privilege attacks, which attempt to subvert their normal role of providing some necessary but limited capability. As such, motivation exists to monitor these programs for unusual activity.		 At a minimum, the audit system should collect the execution of privileged commands for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add a line of the following form to a file with suffix .rules in the directory /etc/audit/rules.d: 
-a always,exit -F path=/usr/sbin/pam_timestamp_check -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged
If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules: 
-a always,exit -F path=/usr/sbin/pam_timestamp_check -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged
 
Verify that Oracle Linux 9 is configured to audit the execution of the "pam_timestamp_check" command with the following command:

$ sudo auditctl -l | grep pam_timestamp_check

-a always,exit -F path=/usr/sbin/pam_timestamp_check -F perm=x -F auid>=1000 -F auid!=unset -k privileged-pam_timestamp_check
      Is it the case that the command does not return a line, or the line is commented out?
 SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215, SRG-APP-000029-CTR-000085, SRG-APP-000495-CTR-001235 AU-2(d), AU-12(c), AC-6(9), CM-6(a)
xccdf_org.ssgproject.content_rule_audit_rules_privileged_commands_passwd medium Ensure auditd Collects Information on the Use of Privileged Commands - passwd Misuse of privileged functions, either intentionally or unintentionally by authorized users, or by unauthorized external entities that have compromised system accounts, is a serious and ongoing concern and can have significant adverse impacts on organizations. Auditing the use of privileged functions is one way to detect such misuse and identify the risk from insider and advanced persistent threats.

Privileged programs are subject to escalation-of-privilege attacks, which attempt to subvert their normal role of providing some necessary but limited capability. As such, motivation exists to monitor these programs for unusual activity.		 At a minimum, the audit system should collect the execution of privileged commands for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add a line of the following form to a file with suffix .rules in the directory /etc/audit/rules.d: 
-a always,exit -F path=/usr/bin/passwd -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged
If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules: 
-a always,exit -F path=/usr/bin/passwd -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged
 
Verify that Oracle Linux 9 is configured to audit the execution of the "passwd" command with the following command:

$ sudo auditctl -l | grep passwd

-a always,exit -F path=/usr/bin/passwd -F perm=x -F auid>=1000 -F auid!=unset -k privileged-passwd
      Is it the case that the command does not return a line, or the line is commented out?
 SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215, SRG-APP-000029-CTR-000085, SRG-APP-000495-CTR-001235 AC-2(4), AU-2(d), AU-12(c), AC-6(9), CM-6(a)
xccdf_org.ssgproject.content_rule_audit_rules_privileged_commands_postdrop medium Ensure auditd Collects Information on the Use of Privileged Commands - postdrop Misuse of privileged functions, either intentionally or unintentionally by authorized users, or by unauthorized external entities that have compromised system accounts, is a serious and ongoing concern and can have significant adverse impacts on organizations. Auditing the use of privileged functions is one way to detect such misuse and identify the risk from insider and advanced persistent threats.

Privileged programs are subject to escalation-of-privilege attacks, which attempt to subvert their normal role of providing some necessary but limited capability. As such, motivation exists to monitor these programs for unusual activity.		 At a minimum, the audit system should collect the execution of privileged commands for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add a line of the following form to a file with suffix .rules in the directory /etc/audit/rules.d: 
-a always,exit -F path=/usr/sbin/postdrop -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged
If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules: 
-a always,exit -F path=/usr/sbin/postdrop -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged
 
Verify that Oracle Linux 9 is configured to audit the execution of the "postdrop" command with the following command:

$ sudo auditctl -l | grep postdrop

-a always,exit -F path=/usr/bin/postdrop -F perm=x -F auid>=1000 -F auid!=unset -k privileged-postdrop
      Is it the case that the command does not return a line, or the line is commented out?
 SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215, SRG-APP-000495-CTR-001235 AU-2(d), AU-12(c), AC-6(9), CM-6(a)
xccdf_org.ssgproject.content_rule_audit_rules_privileged_commands_postqueue medium Ensure auditd Collects Information on the Use of Privileged Commands - postqueue Misuse of privileged functions, either intentionally or unintentionally by authorized users, or by unauthorized external entities that have compromised system accounts, is a serious and ongoing concern and can have significant adverse impacts on organizations. Auditing the use of privileged functions is one way to detect such misuse and identify the risk from insider and advanced persistent threats.

Privileged programs are subject to escalation-of-privilege attacks, which attempt to subvert their normal role of providing some necessary but limited capability. As such, motivation exists to monitor these programs for unusual activity.		 At a minimum, the audit system should collect the execution of privileged commands for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add a line of the following form to a file with suffix .rules in the directory /etc/audit/rules.d: 
-a always,exit -F path=/usr/sbin/postqueue -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged
If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules: 
-a always,exit -F path=/usr/sbin/postqueue -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged
 
Verify that Oracle Linux 9 is configured to audit the execution of the "postqueue" command with the following command:

$ sudo auditctl -l | grep postqueue

-a always,exit -F path=/usr/bin/postqueue -F perm=x -F auid>=1000 -F auid!=unset -k privileged-postqueue
      Is it the case that the command does not return a line, or the line is commented out?
 SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215, SRG-APP-000495-CTR-001235 AU-2(d), AU-12(c), AC-6(9), CM-6(a)
xccdf_org.ssgproject.content_rule_audit_rules_privileged_commands_ssh_agent medium Record Any Attempts to Run ssh-agent Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). At a minimum, the audit system should collect the execution of privileged commands for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add a line of the following form to a file with suffix .rules in the directory /etc/audit/rules.d: 
-a always,exit -F path=/usr/bin/ssh-agent -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged
If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules: 
-a always,exit -F path=/usr/bin/ssh-agent -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged
 
Verify that Oracle Linux 9 is configured to audit the execution of the "ssh-agent" command with the following command:

$ sudo auditctl -l | grep ssh-agent

-a always,exit -F path=/usr/bin/ssh-agent -F perm=x -F auid>=1000 -F auid!=unset -k privileged-ssh-agent
      Is it the case that the command does not return a line, or the line is commented out?
 SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215, SRG-APP-000495-CTR-001235
xccdf_org.ssgproject.content_rule_audit_rules_privileged_commands_ssh_keysign medium Ensure auditd Collects Information on the Use of Privileged Commands - ssh-keysign Misuse of privileged functions, either intentionally or unintentionally by authorized users, or by unauthorized external entities that have compromised system accounts, is a serious and ongoing concern and can have significant adverse impacts on organizations. Auditing the use of privileged functions is one way to detect such misuse and identify the risk from insider and advanced persistent threats.

Privileged programs are subject to escalation-of-privilege attacks, which attempt to subvert their normal role of providing some necessary but limited capability. As such, motivation exists to monitor these programs for unusual activity.		 At a minimum, the audit system should collect the execution of privileged commands for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add a line of the following form to a file with suffix .rules in the directory /etc/audit/rules.d: 
-a always,exit -F path=/usr/libexec/openssh/ssh-keysign -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged
If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules: 
-a always,exit -F path=/usr/libexec/openssh/ssh-keysign -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged
 
Verify that Oracle Linux 9 is configured to audit the execution of the "ssh-keysign" command with the following command:

$ sudo auditctl -l | grep ssh-keysign

-a always,exit -F path=/usr/libexec/openssh/ssh-keysignssh-keysign -F perm=x -F auid>=1000 -F auid!=unset -k privileged-ssh-keysign
      Is it the case that the command does not return a line, or the line is commented out?
 SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215, SRG-APP-000029-CTR-000085, SRG-APP-000495-CTR-001235 AU-2(d), AU-12(c), AC-6(9), CM-6(a)
xccdf_org.ssgproject.content_rule_audit_rules_privileged_commands_su medium Ensure auditd Collects Information on the Use of Privileged Commands - su Misuse of privileged functions, either intentionally or unintentionally by authorized users, or by unauthorized external entities that have compromised system accounts, is a serious and ongoing concern and can have significant adverse impacts on organizations. Auditing the use of privileged functions is one way to detect such misuse and identify the risk from insider and advanced persistent threats.

Privileged programs are subject to escalation-of-privilege attacks, which attempt to subvert their normal role of providing some necessary but limited capability. As such, motivation exists to monitor these programs for unusual activity.		 At a minimum, the audit system should collect the execution of privileged commands for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add a line of the following form to a file with suffix .rules in the directory /etc/audit/rules.d: 
-a always,exit -F path=/usr/bin/su -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged
If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules: 
-a always,exit -F path=/usr/bin/su -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged
 
Verify that Oracle Linux 9 is configured to audit the execution of the "su" command with the following command:

$ sudo auditctl -l | grep su

-a always,exit -F path=/usr/bin/su -F perm=x -F auid>=1000 -F auid!=unset -k privileged-su
      Is it the case that the command does not return a line, or the line is commented out?
 SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000064-GPOS-00033, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215, SRG-OS-000466-GPOS-00210, SRG-APP-000029-CTR-000085, SRG-APP-000495-CTR-001235, SRG-APP-000499-CTR-001255, SRG-OS-000755-GPOS-00220 AU-2(d), AU-12(c), AC-6(9), CM-6(a)
xccdf_org.ssgproject.content_rule_audit_rules_privileged_commands_sudo medium Ensure auditd Collects Information on the Use of Privileged Commands - sudo Misuse of privileged functions, either intentionally or unintentionally by authorized users, or by unauthorized external entities that have compromised system accounts, is a serious and ongoing concern and can have significant adverse impacts on organizations. Auditing the use of privileged functions is one way to detect such misuse and identify the risk from insider and advanced persistent threats.

Privileged programs are subject to escalation-of-privilege attacks, which attempt to subvert their normal role of providing some necessary but limited capability. As such, motivation exists to monitor these programs for unusual activity.		 At a minimum, the audit system should collect the execution of privileged commands for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add a line of the following form to a file with suffix .rules in the directory /etc/audit/rules.d: 
-a always,exit -F path=/usr/bin/sudo -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged
If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules: 
-a always,exit -F path=/usr/bin/sudo -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged
 
Verify that Oracle Linux 9 is configured to audit the execution of the "sudo" command with the following command:

$ sudo auditctl -l | grep sudo

-a always,exit -F path=/usr/bin/sudo -F perm=x -F auid>=1000 -F auid!=unset -k privileged-sudo
      Is it the case that the command does not return a line, or the line is commented out?
 SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215, SRG-OS-000466-GPOS-00210, SRG-APP-000029-CTR-000085, SRG-APP-000495-CTR-001235, SRG-APP-000499-CTR-001255, SRG-OS-000755-GPOS-00220 AU-2(d), AU-12(c), AC-6(9), CM-6(a)
xccdf_org.ssgproject.content_rule_audit_rules_privileged_commands_sudoedit medium Ensure auditd Collects Information on the Use of Privileged Commands - sudoedit Misuse of privileged functions, either intentionally or unintentionally by authorized users, or by unauthorized external entities that have compromised system accounts, is a serious and ongoing concern and can have significant adverse impacts on organizations. Auditing the use of privileged functions is one way to detect such misuse and identify the risk from insider and advanced persistent threats.

Privileged programs are subject to escalation-of-privilege attacks, which attempt to subvert their normal role of providing some necessary but limited capability. As such, motivation exists to monitor these programs for unusual activity.		 At a minimum, the audit system should collect the execution of privileged commands for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add a line of the following form to a file with suffix .rules in the directory /etc/audit/rules.d: 
-a always,exit -F path=/usr/bin/sudoedit -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged
If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules: 
-a always,exit -F path=/usr/bin/sudoedit -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged
 
Verify that Oracle Linux 9 is configured to audit the execution of the "sudoedit" command with the following command:

$ sudo auditctl -l | grep sudoedit

-a always,exit -F path=/usr/bin/sudoedit -F perm=x -F auid>=1000 -F auid!=unset -k privileged-sudoedit
      Is it the case that the command does not return a line, or the line is commented out?
 SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215, SRG-APP-000495-CTR-001235, SRG-OS-000755-GPOS-00220 AU-2(d), AU-12(c), AC-6(9), CM-6(a)
xccdf_org.ssgproject.content_rule_audit_rules_privileged_commands_umount medium Ensure auditd Collects Information on the Use of Privileged Commands - umount Misuse of privileged functions, either intentionally or unintentionally by authorized users, or by unauthorized external entities that have compromised system accounts, is a serious and ongoing concern and can have significant adverse impacts on organizations. Auditing the use of privileged functions is one way to detect such misuse and identify the risk from insider and advanced persistent threats.

Privileged programs are subject to escalation-of-privilege attacks, which attempt to subvert their normal role of providing some necessary but limited capability. As such, motivation exists to monitor these programs for unusual activity.		 At a minimum, the audit system should collect the execution of privileged commands for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add a line of the following form to a file with suffix .rules in the directory /etc/audit/rules.d: 
-a always,exit -F path=/usr/bin/umount -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged
If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules: 
-a always,exit -F path=/usr/bin/umount -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged
 
Verify that Oracle Linux 9 is configured to audit the execution of the "umount" command with the following command:

$ sudo auditctl -l | grep umount

-a always,exit -F path=/usr/bin/umount -F perm=x -F auid>=1000 -F auid!=unset -k privileged-umount
      Is it the case that the command does not return a line, or the line is commented out?
 SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215, SRG-APP-000029-CTR-000085 AU-2(d), AU-12(c), AC-6(9), CM-6(a)
xccdf_org.ssgproject.content_rule_audit_rules_privileged_commands_unix_chkpwd medium Ensure auditd Collects Information on the Use of Privileged Commands - unix_chkpwd Misuse of privileged functions, either intentionally or unintentionally by authorized users, or by unauthorized external entities that have compromised system accounts, is a serious and ongoing concern and can have significant adverse impacts on organizations. Auditing the use of privileged functions is one way to detect such misuse and identify the risk from insider and advanced persistent threats.

Privileged programs are subject to escalation-of-privilege attacks, which attempt to subvert their normal role of providing some necessary but limited capability. As such, motivation exists to monitor these programs for unusual activity.		 At a minimum, the audit system should collect the execution of privileged commands for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add a line of the following form to a file with suffix .rules in the directory /etc/audit/rules.d: 
-a always,exit -F path=/sbin/unix_chkpwd -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged
If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules: 
-a always,exit -F path=/sbin/unix_chkpwd -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged
 
Verify that Oracle Linux 9 is configured to audit the execution of the "unix_chkpwd" command with the following command:

$ sudo auditctl -l | grep unix_chkpwd

-a always,exit -F path=/usr/bin/unix_chkpwd -F perm=x -F auid>=1000 -F auid!=unset -k privileged-unix_chkpwd
      Is it the case that the command does not return a line, or the line is commented out?
 SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215, SRG-APP-000029-CTR-000085, SRG-APP-000495-CTR-001235 AC-2(4), AU-2(d), AU-3, AU-3.1, AU-12(a), AU-12(c), AU-12.1(ii), AU-12.1(iv), AC-6(9), CM-6(a), MA-4(1)(a)
xccdf_org.ssgproject.content_rule_audit_rules_privileged_commands_unix_update medium Ensure auditd Collects Information on the Use of Privileged Commands - unix_update Misuse of privileged functions, either intentionally or unintentionally by authorized users, or by unauthorized external entities that have compromised system accounts, is a serious and ongoing concern and can have significant adverse impacts on organizations. Auditing the use of privileged functions is one way to detect such misuse and identify the risk from insider and advanced persistent threats.

Privileged programs are subject to escalation-of-privilege attacks, which attempt to subvert their normal role of providing some necessary but limited capability. As such, motivation exists to monitor these programs for unusual activity.		 At a minimum, the audit system should collect the execution of privileged commands for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add a line of the following form to a file with suffix .rules in the directory /etc/audit/rules.d: 
-a always,exit -F path=/usr/sbin/unix_update -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged
If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules: 
-a always,exit -F path=/usr/sbin/unix_update -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged
 
Verify that Oracle Linux 9 is configured to audit the execution of the "unix_update" command with the following command:

$ sudo auditctl -l | grep unix_update

-a always,exit -F path=/usr/bin/unix_update -F perm=x -F auid>=1000 -F auid!=unset -k privileged-unix_update
      Is it the case that the command does not return a line, or the line is commented out?
 SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000064-GPOS-00033, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215, SRG-APP-000495-CTR-001235
xccdf_org.ssgproject.content_rule_audit_rules_privileged_commands_userhelper medium Ensure auditd Collects Information on the Use of Privileged Commands - userhelper Misuse of privileged functions, either intentionally or unintentionally by authorized users, or by unauthorized external entities that have compromised system accounts, is a serious and ongoing concern and can have significant adverse impacts on organizations. Auditing the use of privileged functions is one way to detect such misuse and identify the risk from insider and advanced persistent threats.

Privileged programs are subject to escalation-of-privilege attacks, which attempt to subvert their normal role of providing some necessary but limited capability. As such, motivation exists to monitor these programs for unusual activity.		 At a minimum, the audit system should collect the execution of privileged commands for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add a line of the following form to a file with suffix .rules in the directory /etc/audit/rules.d: 
-a always,exit -F path=/usr/sbin/userhelper -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged
If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules: 
-a always,exit -F path=/usr/sbin/userhelper -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged
 
Verify that Oracle Linux 9 is configured to audit the execution of the "userhelper" command with the following command:

$ sudo auditctl -l | grep userhelper

-a always,exit -F path=/usr/bin/userhelper -F perm=x -F auid>=1000 -F auid!=unset -k privileged-userhelper
      Is it the case that the command does not return a line, or the line is commented out?
 SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215, SRG-APP-000495-CTR-001235 AU-2(d), AU-12(c), AC-6(9), CM-6(a)
xccdf_org.ssgproject.content_rule_audit_rules_privileged_commands_usermod medium Ensure auditd Collects Information on the Use of Privileged Commands - usermod Misuse of privileged functions, either intentionally or unintentionally by authorized users, or by unauthorized external entities that have compromised system accounts, is a serious and ongoing concern and can have significant adverse impacts on organizations. Auditing the use of privileged functions is one way to detect such misuse and identify the risk from insider and advanced persistent threats.

Privileged programs are subject to escalation-of-privilege attacks, which attempt to subvert their normal role of providing some necessary but limited capability. As such, motivation exists to monitor these programs for unusual activity.		 At a minimum, the audit system should collect the execution of privileged commands for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add a line of the following form to a file with suffix .rules in the directory /etc/audit/rules.d: 
-a always,exit -F path=/usr/sbin/usermod -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged
If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules: 
-a always,exit -F path=/usr/sbin/usermod -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged
 
Verify that Oracle Linux 9 is configured to audit the execution of the "usermod" command with the following command:

$ sudo auditctl -l | grep usermod

-a always,exit -F path=/usr/bin/usermod -F perm=x -F auid>=1000 -F auid!=unset -k privileged-usermod
      Is it the case that the command does not return a line, or the line is commented out?
 SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215, SRG-OS-000466-GPOS-00210, SRG-APP-000495-CTR-001235, SRG-APP-000499-CTR-001255
xccdf_org.ssgproject.content_rule_audit_rules_sudoers medium Ensure auditd Collects System Administrator Actions - /etc/sudoers The actions taken by system administrators should be audited to keep a record of what was executed on the system, as well as, for accountability purposes. Editing the sudoers file may be sign of an attacker trying to establish persistent methods to a system, auditing the editing of the sudoers files mitigates this risk. At a minimum, the audit system should collect administrator actions for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following lines to a file with suffix .rules in the directory /etc/audit/rules.d: 
-w /etc/sudoers -p wa -k actions
If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules: 
-w /etc/sudoers -p wa -k actions
 
Verify Oracle Linux 9 generates audit records for all events that affect "/etc/sudoers" with the following command:

$ sudo auditctl -l | grep /etc/sudoers

-w /etc/sudoers -p wa -k actions
      Is it the case that the command does not return a line, or the line is commented out?
 SRG-OS-000004-GPOS-00004, SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000304-GPOS-00121, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000470-GPOS-00214, SRG-OS-000471-GPOS-00215, SRG-OS-000239-GPOS-00089, SRG-OS-000240-GPOS-00090, SRG-OS-000241-GPOS-00091, SRG-OS-000303-GPOS-00120, SRG-OS-000466-GPOS-00210, SRG-OS-000476-GPOS-00221, SRG-APP-000495-CTR-001235, SRG-APP-000499-CTR-001255, SRG-APP-000503-CTR-001275
xccdf_org.ssgproject.content_rule_audit_rules_sudoers_d medium Ensure auditd Collects System Administrator Actions - /etc/sudoers.d/ The actions taken by system administrators should be audited to keep a record of what was executed on the system, as well as, for accountability purposes. Editing the sudoers file may be sign of an attacker trying to establish persistent methods to a system, auditing the editing of the sudoers files mitigates this risk. At a minimum, the audit system should collect administrator actions for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following lines to a file with suffix .rules in the directory /etc/audit/rules.d: 
-w /etc/sudoers.d/ -p wa -k actions
If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules: 
-w /etc/sudoers.d/ -p wa -k actions
 
Verify Oracle Linux 9 generates audit records for all events that affect "/etc/sudoers.d/" with the following command:

$ sudo auditctl -l | grep /etc/sudoers.d/

-w /etc/sudoers.d/ -p wa -k actions
      Is it the case that the command does not return a line, or the line is commented out?
 SRG-OS-000004-GPOS-00004, SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000304-GPOS-00121, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000470-GPOS-00214, SRG-OS-000471-GPOS-00215, SRG-OS-000239-GPOS-00089, SRG-OS-000240-GPOS-00090, SRG-OS-000241-GPOS-00091, SRG-OS-000303-GPOS-00120, SRG-OS-000466-GPOS-00210, SRG-OS-000476-GPOS-00221, SRG-APP-000495-CTR-001235, SRG-APP-000499-CTR-001255, SRG-APP-000503-CTR-001275
xccdf_org.ssgproject.content_rule_audit_rules_suid_privilege_function medium Record Events When Privileged Executables Are Run Misuse of privileged functions, either intentionally or unintentionally by authorized users, or by unauthorized external entities that have compromised information system accounts, is a serious and ongoing concern and can have significant adverse impacts on organizations. Auditing the use of privileged functions is one way to detect such misuse and identify the risk from insider threats and the advanced persistent threat. Verify the system generates an audit record when privileged functions are executed. If audit is using the "auditctl" tool to load the rules, run the following command: 
$ sudo grep execve /etc/audit/audit.rules
If audit is using the "augenrules" tool to load the rules, run the following command: 
$ sudo grep -r execve /etc/audit/rules.d
-a always,exit -F arch=b32 -S execve -C uid!=euid -F euid=0 -k setuid
-a always,exit -F arch=b64 -S execve -C uid!=euid -F euid=0 -k setuid
-a always,exit -F arch=b32 -S execve -C gid!=egid -F egid=0 -k setgid
-a always,exit -F arch=b64 -S execve -C gid!=egid -F egid=0 -k setgid
If both the "b32" and "b64" audit rules for "SUID" files are not defined, this is a finding. If both the "b32" and "b64" audit rules for "SGID" files are not defined, this is a finding.		 
Verify Oracle Linux 9 audits the execution of privileged functions.

Check if Oracle Linux 9 is configured to audit the execution of the "execve" system call using the following command:


$ sudo grep execve /etc/audit/audit.rules


The output should be the following:



-a always,exit -F arch=b32 -S execve -C uid!=euid -F euid=0 -k setuid


-a always,exit -F arch=b64 -S execve -C uid!=euid -F euid=0 -k setuid


-a always,exit -F arch=b32 -S execve -C gid!=egid -F egid=0 -k setgid


-a always,exit -F arch=b64 -S execve -C gid!=egid -F egid=0 -k setgid

      Is it the case that the command does not return all lines, or the lines are commented out?
 SRG-OS-000326-GPOS-00126, SRG-OS-000327-GPOS-00127, SRG-APP-000343-CTR-000780, SRG-APP-000381-CTR-000905, SRG-OS-000755-GPOS-00220 CM-5(1), AU-7(a), AU-7(b), AU-8(b), AU-12(3), AC-6(9)
xccdf_org.ssgproject.content_rule_audit_rules_system_shutdown medium Shutdown System When Auditing Failures Occur It is critical for the appropriate personnel to be aware if a system is at risk of failing to process audit logs as required. Without this notification, the security personnel may be unaware of an impending failure of the audit capability, and system operation may be adversely affected.

Audit processing failures include software/hardware errors, failures in the audit capturing mechanisms, and audit storage capacity being reached or exceeded.		 If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to to the bottom of a file with suffix .rules in the directory /etc/audit/rules.d: 
-f None
If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to the bottom of the /etc/audit/audit.rules file: 
-f None
 
To verify that the system will shutdown when auditd fails,
run the following command:

$ sudo grep "\-f None" /etc/audit/audit.rules

The output should contain:

-f None

      Is it the case that the system is not configured to shutdown on auditd failures?
 SRG-OS-000046-GPOS-00022, SRG-OS-000047-GPOS-00023 AU-5(b), SC-24, CM-6(a)
xccdf_org.ssgproject.content_rule_audit_rules_unsuccessful_file_modification_creat medium Record Unsuccessful Access Attempts to Files - creat Unsuccessful attempts to access files could be an indicator of malicious activity on a system. Auditing these events could serve as evidence of potential system compromise. At a minimum, the audit system should collect unauthorized file accesses for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following lines to a file with suffix .rules in the directory /etc/audit/rules.d: 
-a always,exit -F arch=b32 -S creat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S creat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access
If the system is 64 bit then also add the following lines: 
-a always,exit -F arch=b64 -S creat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S creat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access
If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file: 
-a always,exit -F arch=b32 -S creat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S creat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access
If the system is 64 bit then also add the following lines: 
-a always,exit -F arch=b64 -S creat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S creat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access
 
Verify Oracle Linux 9 generates an audit record for unsuccessful attempts to use the creat system call.

If the auditd daemon is configured to use the "augenrules" program to to read audit rules during daemon startup (the default), run the following command:

$ sudo grep -r creat /etc/audit/rules.d

If the auditd daemon is configured to use the "auditctl" utility to read audit rules during daemon startup, run the following command:

$ sudo grep creat /etc/audit/audit.rules

The output should be the following:

-a always,exit -F arch=b32 -S creat -F exit=-EPERM -F auid>=1000 -F auid!=unset -k access
-a always,exit -F arch=b64 -S creat -F exit=-EPERM -F auid>=1000 -F auid!=unset -k access
-a always,exit -F arch=b32 -S creat -F exit=-EACCES -F auid>=1000 -F auid!=unset -k access
-a always,exit -F arch=b64 -S creat -F exit=-EACCES -F auid>=1000 -F auid!=unset -k access
      Is it the case that the command does not return a line, or the line is commented out?
 SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215, SRG-OS-000064-GPOS-00033, SRG-OS-000458-GPOS-00203, SRG-OS-000461-GPOS-00205, SRG-APP-000495-CTR-001235 AU-2(d), AU-12(c), CM-6(a)
xccdf_org.ssgproject.content_rule_audit_rules_unsuccessful_file_modification_ftruncate medium Record Unsuccessful Access Attempts to Files - ftruncate Unsuccessful attempts to access files could be an indicator of malicious activity on a system. Auditing these events could serve as evidence of potential system compromise. At a minimum, the audit system should collect unauthorized file accesses for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following lines to a file with suffix .rules in the directory /etc/audit/rules.d: 
-a always,exit -F arch=b32 -S ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access
If the system is 64 bit then also add the following lines: 
-a always,exit -F arch=b64 -S ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access
If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file: 
-a always,exit -F arch=b32 -S ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access
If the system is 64 bit then also add the following lines: 
-a always,exit -F arch=b64 -S ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access
 
Verify Oracle Linux 9 generates an audit record for unsuccessful attempts to use the ftruncate system call.

If the auditd daemon is configured to use the "augenrules" program to to read audit rules during daemon startup (the default), run the following command:

$ sudo grep -r ftruncate /etc/audit/rules.d

If the auditd daemon is configured to use the "auditctl" utility to read audit rules during daemon startup, run the following command:

$ sudo grep ftruncate /etc/audit/audit.rules

The output should be the following:

-a always,exit -F arch=b32 -S ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -k access
-a always,exit -F arch=b64 -S ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -k access
-a always,exit -F arch=b32 -S ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -k access
-a always,exit -F arch=b64 -S ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -k access
      Is it the case that the command does not return a line, or the line is commented out?
 SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215, SRG-OS-000064-GPOS-00033, SRG-OS-000458-GPOS-00203, SRG-OS-000461-GPOS-00205, SRG-APP-000495-CTR-001235 AU-2(d), AU-12(c), CM-6(a)
xccdf_org.ssgproject.content_rule_audit_rules_unsuccessful_file_modification_open medium Record Unsuccessful Access Attempts to Files - open Unsuccessful attempts to access files could be an indicator of malicious activity on a system. Auditing these events could serve as evidence of potential system compromise. At a minimum, the audit system should collect unauthorized file accesses for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following lines to a file with suffix .rules in the directory /etc/audit/rules.d: 
-a always,exit -F arch=b32 -S open -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S open -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access
If the system is 64 bit then also add the following lines: 
-a always,exit -F arch=b64 -S open -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S open -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access
If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file: 
-a always,exit -F arch=b32 -S open -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S open -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access
If the system is 64 bit then also add the following lines: 
-a always,exit -F arch=b64 -S open -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S open -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access
 
Verify Oracle Linux 9 generates an audit record for unsuccessful attempts to use the open system call.

If the auditd daemon is configured to use the "augenrules" program to to read audit rules during daemon startup (the default), run the following command:

$ sudo grep -r open /etc/audit/rules.d

If the auditd daemon is configured to use the "auditctl" utility to read audit rules during daemon startup, run the following command:

$ sudo grep open /etc/audit/audit.rules

The output should be the following:

-a always,exit -F arch=b32 -S open -F exit=-EPERM -F auid>=1000 -F auid!=unset -k access
-a always,exit -F arch=b64 -S open -F exit=-EPERM -F auid>=1000 -F auid!=unset -k access
-a always,exit -F arch=b32 -S open -F exit=-EACCES -F auid>=1000 -F auid!=unset -k access
-a always,exit -F arch=b64 -S open -F exit=-EACCES -F auid>=1000 -F auid!=unset -k access
      Is it the case that the command does not return a line, or the line is commented out?
 SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215, SRG-OS-000064-GPOS-00033, SRG-OS-000458-GPOS-00203, SRG-OS-000461-GPOS-00205, SRG-APP-000495-CTR-001235 AU-2(d), AU-12(c), CM-6(a)
xccdf_org.ssgproject.content_rule_audit_rules_unsuccessful_file_modification_open_by_handle_at medium Record Unsuccessful Access Attempts to Files - open_by_handle_at Unsuccessful attempts to access files could be an indicator of malicious activity on a system. Auditing these events could serve as evidence of potential system compromise. At a minimum, the audit system should collect unauthorized file accesses for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following lines to a file with suffix .rules in the directory /etc/audit/rules.d: 
-a always,exit -F arch=b32 -S open_by_handle_at -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S open_by_handle_at -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access
If the system is 64 bit then also add the following lines: 
-a always,exit -F arch=b64 -S open_by_handle_at -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S open_by_handle_at -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access
If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file: 
-a always,exit -F arch=b32 -S open_by_handle_at,truncate,ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S open_by_handle_at,truncate,ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access
If the system is 64 bit then also add the following lines: 
-a always,exit -F arch=b64 -S open_by_handle_at,truncate,ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S open_by_handle_at,truncate,ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access
 
Verify Oracle Linux 9 generates an audit record for unsuccessful attempts to use the open_by_handle_at system call.

If the auditd daemon is configured to use the "augenrules" program to to read audit rules during daemon startup (the default), run the following command:

$ sudo grep -r open_by_handle_at /etc/audit/rules.d

If the auditd daemon is configured to use the "auditctl" utility to read audit rules during daemon startup, run the following command:

$ sudo grep open_by_handle_at /etc/audit/audit.rules

The output should be the following:

-a always,exit -F arch=b32 -S open_by_handle_at -F exit=-EPERM -F auid>=1000 -F auid!=unset -k access
-a always,exit -F arch=b64 -S open_by_handle_at -F exit=-EPERM -F auid>=1000 -F auid!=unset -k access
-a always,exit -F arch=b32 -S open_by_handle_at -F exit=-EACCES -F auid>=1000 -F auid!=unset -k access
-a always,exit -F arch=b64 -S open_by_handle_at -F exit=-EACCES -F auid>=1000 -F auid!=unset -k access
      Is it the case that the command does not return a line, or the line is commented out?
 SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215, SRG-OS-000064-GPOS-00033, SRG-OS-000458-GPOS-00203, SRG-OS-000461-GPOS-00205, SRG-APP-000495-CTR-001235 AU-2(d), AU-12(c), CM-6(a)
xccdf_org.ssgproject.content_rule_audit_rules_unsuccessful_file_modification_openat medium Record Unsuccessful Access Attempts to Files - openat Unsuccessful attempts to access files could be an indicator of malicious activity on a system. Auditing these events could serve as evidence of potential system compromise. At a minimum, the audit system should collect unauthorized file accesses for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following lines to a file with suffix .rules in the directory /etc/audit/rules.d: 
-a always,exit -F arch=b32 -S openat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S openat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access
If the system is 64 bit then also add the following lines: 
-a always,exit -F arch=b64 -S openat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S openat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access
If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file: 
-a always,exit -F arch=b32 -S openat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S openat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access
If the system is 64 bit then also add the following lines: 
-a always,exit -F arch=b64 -S openat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S openat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access
 
Verify Oracle Linux 9 generates an audit record for unsuccessful attempts to use the openat system call.

If the auditd daemon is configured to use the "augenrules" program to to read audit rules during daemon startup (the default), run the following command:

$ sudo grep -r openat /etc/audit/rules.d

If the auditd daemon is configured to use the "auditctl" utility to read audit rules during daemon startup, run the following command:

$ sudo grep openat /etc/audit/audit.rules

The output should be the following:

-a always,exit -F arch=b32 -S openat -F exit=-EPERM -F auid>=1000 -F auid!=unset -k access
-a always,exit -F arch=b64 -S openat -F exit=-EPERM -F auid>=1000 -F auid!=unset -k access
-a always,exit -F arch=b32 -S openat -F exit=-EACCES -F auid>=1000 -F auid!=unset -k access
-a always,exit -F arch=b64 -S openat -F exit=-EACCES -F auid>=1000 -F auid!=unset -k access
      Is it the case that the command does not return a line, or the line is commented out?
 SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215, SRG-OS-000064-GPOS-00033, SRG-OS-000458-GPOS-00203, SRG-OS-000461-GPOS-00205, SRG-APP-000495-CTR-001235 AU-2(d), AU-12(c), CM-6(a)
xccdf_org.ssgproject.content_rule_audit_rules_unsuccessful_file_modification_truncate medium Record Unsuccessful Access Attempts to Files - truncate Unsuccessful attempts to access files could be an indicator of malicious activity on a system. Auditing these events could serve as evidence of potential system compromise. At a minimum, the audit system should collect unauthorized file accesses for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following lines to a file with suffix .rules in the directory /etc/audit/rules.d: 
-a always,exit -F arch=b32 -S truncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S truncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access
If the system is 64 bit then also add the following lines: 
-a always,exit -F arch=b64 -S truncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S truncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access
If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file: 
-a always,exit -F arch=b32 -S truncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S truncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access
If the system is 64 bit then also add the following lines: 
-a always,exit -F arch=b64 -S truncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S truncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access
 
Verify Oracle Linux 9 generates an audit record for unsuccessful attempts to use the truncate system call.

If the auditd daemon is configured to use the "augenrules" program to to read audit rules during daemon startup (the default), run the following command:

$ sudo grep -r truncate /etc/audit/rules.d

If the auditd daemon is configured to use the "auditctl" utility to read audit rules during daemon startup, run the following command:

$ sudo grep truncate /etc/audit/audit.rules

The output should be the following:

-a always,exit -F arch=b32 -S truncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -k access
-a always,exit -F arch=b64 -S truncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -k access
-a always,exit -F arch=b32 -S truncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -k access
-a always,exit -F arch=b64 -S truncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -k access
      Is it the case that the command does not return a line, or the line is commented out?
 SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215, SRG-OS-000064-GPOS-00033, SRG-OS-000458-GPOS-00203, SRG-OS-000461-GPOS-00205, SRG-APP-000495-CTR-001235 AU-2(d), AU-12(c), CM-6(a)
xccdf_org.ssgproject.content_rule_audit_rules_usergroup_modification_group medium Record Events that Modify User/Group Information - /etc/group In addition to auditing new user and group accounts, these watches will alert the system administrator(s) to any modifications. Any unexpected users, groups, or modifications should be investigated for legitimacy. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following lines to a file with suffix .rules in the directory /etc/audit/rules.d: 
-w /etc/group -p wa -k audit_rules_usergroup_modification
If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules: 
-w /etc/group -p wa -k audit_rules_usergroup_modification
 
Verify Oracle Linux 9 generates audit records for all events that affect "/etc/group" with the following command:

$ sudo auditctl -l | grep /etc/group

-w /etc/group -p wa -k audit_rules_usergroup_modification
      Is it the case that the command does not return a line, or the line is commented out?
 SRG-OS-000004-GPOS-00004, SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000304-GPOS-00121, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000470-GPOS-00214, SRG-OS-000471-GPOS-00215, SRG-OS-000239-GPOS-00089, SRG-OS-000240-GPOS-00090, SRG-OS-000241-GPOS-00091, SRG-OS-000303-GPOS-00120, SRG-OS-000466-GPOS-00210, SRG-OS-000476-GPOS-00221, SRG-APP-000495-CTR-001235, SRG-APP-000499-CTR-001255, SRG-APP-000503-CTR-001275 AC-2(4), AU-2(d), AU-12(c), AC-6(9), CM-6(a)
xccdf_org.ssgproject.content_rule_audit_rules_usergroup_modification_gshadow medium Record Events that Modify User/Group Information - /etc/gshadow In addition to auditing new user and group accounts, these watches will alert the system administrator(s) to any modifications. Any unexpected users, groups, or modifications should be investigated for legitimacy. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following lines to a file with suffix .rules in the directory /etc/audit/rules.d: 
-w /etc/gshadow -p wa -k audit_rules_usergroup_modification
If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules: 
-w /etc/gshadow -p wa -k audit_rules_usergroup_modification
 
Verify Oracle Linux 9 generates audit records for all events that affect "/etc/gshadow" with the following command:

$ sudo auditctl -l | grep /etc/gshadow

-w /etc/gshadow -p wa -k audit_rules_usergroup_modification
      Is it the case that the system is not configured to audit account changes?
 SRG-OS-000004-GPOS-00004, SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000304-GPOS-00121, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000470-GPOS-00214, SRG-OS-000471-GPOS-00215, SRG-OS-000239-GPOS-00089, SRG-OS-000240-GPOS-00090, SRG-OS-000241-GPOS-00091, SRG-OS-000303-GPOS-00120, SRG-OS-000466-GPOS-00210, SRG-OS-000476-GPOS-00221, SRG-APP-000495-CTR-001235, SRG-APP-000499-CTR-001255, SRG-APP-000503-CTR-001275 AC-2(4), AU-2(d), AU-12(c), AC-6(9), CM-6(a)
xccdf_org.ssgproject.content_rule_audit_rules_usergroup_modification_opasswd medium Record Events that Modify User/Group Information - /etc/security/opasswd In addition to auditing new user and group accounts, these watches will alert the system administrator(s) to any modifications. Any unexpected users, groups, or modifications should be investigated for legitimacy. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following lines to a file with suffix .rules in the directory /etc/audit/rules.d: 
-w /etc/security/opasswd -p wa -k audit_rules_usergroup_modification
If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules: 
-w /etc/security/opasswd -p wa -k audit_rules_usergroup_modification
 
Verify Oracle Linux 9 generates audit records for all events that affect "/etc/security/opasswd" with the following command:

$ sudo auditctl -l | grep /etc/security/opasswd

-w /etc/security/opasswd -p wa -k audit_rules_usergroup_modification
      Is it the case that the command does not return a line, or the line is commented out?
 SRG-OS-000004-GPOS-00004, SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000304-GPOS-00121, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000470-GPOS-00214, SRG-OS-000471-GPOS-00215, SRG-OS-000239-GPOS-00089, SRG-OS-000240-GPOS-00090, SRG-OS-000241-GPOS-00091, SRG-OS-000303-GPOS-00120, SRG-OS-000466-GPOS-00210, SRG-OS-000476-GPOS-00221, SRG-APP-000495-CTR-001235, SRG-APP-000496-CTR-001240, SRG-APP-000497-CTR-001245, SRG-APP-000498-CTR-001250, SRG-APP-000503-CTR-001275 AC-2(4), AU-2(d), AU-12(c), AC-6(9), CM-6(a)
xccdf_org.ssgproject.content_rule_audit_rules_usergroup_modification_passwd medium Record Events that Modify User/Group Information - /etc/passwd In addition to auditing new user and group accounts, these watches will alert the system administrator(s) to any modifications. Any unexpected users, groups, or modifications should be investigated for legitimacy. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following lines to a file with suffix .rules in the directory /etc/audit/rules.d: 
-w /etc/passwd -p wa -k audit_rules_usergroup_modification
If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules: 
-w /etc/passwd -p wa -k audit_rules_usergroup_modification
 
Verify Oracle Linux 9 generates audit records for all events that affect "/etc/passwd" with the following command:

$ sudo auditctl -l | grep /etc/passwd

-w /etc/passwd -p wa -k audit_rules_usergroup_modification
      Is it the case that the command does not return a line, or the line is commented out?
 SRG-OS-000004-GPOS-00004, SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000304-GPOS-00121, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000470-GPOS-00214, SRG-OS-000471-GPOS-00215, SRG-OS-000239-GPOS-00089, SRG-OS-000240-GPOS-00090, SRG-OS-000241-GPOS-00091, SRG-OS-000303-GPOS-00120, SRG-OS-000304-GPOS-00121, SRG-OS-000466-GPOS-00210, SRG-OS-000476-GPOS-00221, SRG-OS-000274-GPOS-00104, SRG-OS-000275-GPOS-00105, SRG-OS-000276-GPOS-00106, SRG-OS-000277-GPOS-00107, SRG-APP-000495-CTR-001235, SRG-APP-000499-CTR-001255, SRG-APP-000503-CTR-001275 AC-2(4), AU-2(d), AU-12(c), AC-6(9), CM-6(a)
xccdf_org.ssgproject.content_rule_audit_rules_usergroup_modification_shadow medium Record Events that Modify User/Group Information - /etc/shadow In addition to auditing new user and group accounts, these watches will alert the system administrator(s) to any modifications. Any unexpected users, groups, or modifications should be investigated for legitimacy. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following lines to a file with suffix .rules in the directory /etc/audit/rules.d: 
-w /etc/shadow -p wa -k audit_rules_usergroup_modification
If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules: 
-w /etc/shadow -p wa -k audit_rules_usergroup_modification
 
Verify Oracle Linux 9 generates audit records for all events that affect "/etc/shadow" with the following command:

$ sudo auditctl -l | grep /etc/shadow

-w /etc/shadow -p wa -k audit_rules_usergroup_modification
      Is it the case that command does not return a line, or the line is commented out?
 SRG-OS-000004-GPOS-00004, SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000304-GPOS-00121, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000470-GPOS-00214, SRG-OS-000471-GPOS-00215, SRG-OS-000239-GPOS-00089, SRG-OS-000240-GPOS-00090, SRG-OS-000241-GPOS-00091, SRG-OS-000303-GPOS-00120, SRG-OS-000466-GPOS-00210, SRG-OS-000476-GPOS-00221, SRG-APP-000495-CTR-001235, SRG-APP-000499-CTR-001255, SRG-APP-000503-CTR-001275 AC-2(4), AU-2(d), AU-12(c), AC-6(9), CM-6(a)
xccdf_org.ssgproject.content_rule_audit_rules_var_spool_cron medium Ensure auditd Collects Changes to Cron Jobs - /var/spool/cron In addition to auditing new user and group accounts, these watches will alert the system administrator(s) to any modifications. Any unexpected users, groups, or modifications should be investigated for legitimacy. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following lines to a file with suffix .rules in the directory /etc/audit/rules.d: 
-w /var/spool/cron -p wa -k cronjobs
If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules: 
-w /var/spool/cron -p wa -k cronjobs
 
Verify Oracle Linux 9 generates audit records for all events that affect "/var/spool/cron" with the following command:

$ sudo auditctl -l | grep /var/spool/cron

-w /var/spool/cron -p wa -k cronjobs
      Is it the case that command does not return a line, or the line is commented out?
 SRG-OS-000363-GPOS-00150, SRG-OS-000363-GPOS-00150, SRG-OS-000446-GPOS-00200, SRG-OS-000447-GPOS-00201
xccdf_org.ssgproject.content_rule_auditd_audispd_configure_sufficiently_large_partition medium Configure a Sufficiently Large Partition for Audit Logs Information stored in one location is vulnerable to accidental or incidental deletion or alteration. Off-loading is a common process in information systems with limited audit storage capacity. The Oracle Linux 9 operating system must allocate audit record storage capacity to store at least one weeks worth of audit records when audit records are not immediately sent to a central audit record storage facility. The partition size needed to capture a week's worth of audit records is based on the activity level of the system and the total storage capacity available. In normal circumstances, 10.0 GB of storage space for audit records will be sufficient. Determine which partition the audit records are being written to with the following command: 
$ sudo grep log_file /etc/audit/auditd.conf
log_file = /var/log/audit/audit.log
Check the size of the partition that audit records are written to with the following command: 
$ sudo df -h /var/log/audit/
/dev/sda2 24G 10.4G 13.6G 43% /var/log/audit
 
To verify whether audispd plugin off-loads audit records onto a different
system or media from the system being audited, run the following command:


$ sudo grep -i remote_server /etc/audit/audisp-remote.conf


The output should return something similar to where REMOTE_SYSTEM
is an IP address or hostname:

remote_server = REMOTE_SYSTEM


Determine which partition the audit records are being written to with the
following command:


$ sudo grep log_file /etc/audit/auditd.conf
log_file = /var/log/audit/audit.log


Check the size of the partition that audit records are written to with the
following command and verify whether it is sufficiently large:


$ sudo df -h /var/log/audit/
/dev/sda2 24G 10.4G 13.6G 43% /var/log/audit

      Is it the case that audispd is not sending logs to a remote system and the local partition has inadequate space?
 SRG-OS-000341-GPOS-00132, SRG-OS-000342-GPOS-00133
xccdf_org.ssgproject.content_rule_auditd_audispd_syslog_plugin_activated medium Configure auditd to use audispd's syslog plugin The auditd service does not include the ability to send audit records to a centralized server for management directly. It does, however, include a plug-in for audit event multiplexor (audispd) to pass audit records to the local syslog server. To configure the auditd service to use the syslog plug-in of the audispd audit event multiplexor, set the active line in /etc/audit/plugins.d/syslog.conf to yes. Restart the auditd service: 
$ sudo service auditd restart
 
To verify the audispd's syslog plugin is active, run the following command:

$ sudo grep active /etc/audit/plugins.d/syslog.conf

If the plugin is active, the output will show yes.
      Is it the case that it is not activated?
 SRG-OS-000479-GPOS-00224, SRG-OS-000342-GPOS-00133 AU-4(1), CM-6(a)
xccdf_org.ssgproject.content_rule_auditd_data_disk_error_action_stig medium Configure auditd Disk Error Action on Disk Error Taking appropriate action in case of disk errors will minimize the possibility of losing audit records. The auditd service can be configured to take an action when there is a disk error. Edit the file /etc/audit/auditd.conf. Add or modify the following line, substituting ACTION appropriately: 
disk_error_action = ACTION
Set this value to single to cause the system to switch to single-user mode for corrective action. Acceptable values also include syslog, exec, single, and halt. For certain systems, the need for availability outweighs the need to log all actions, and a different setting should be determined. Details regarding all possible values for ACTION are described in the auditd.conf man page.		 
Verify Oracle Linux 9 takes the appropriate action when an audit processing failure occurs.

Check that Oracle Linux 9 takes the appropriate action when an audit processing failure occurs with the following command:

$ sudo grep disk_error_action /etc/audit/auditd.conf

disk_error_action = HALT

If the value of the "disk_error_action" option is not "SYSLOG", "SINGLE", or "HALT", or the line is commented out, ask the system administrator to indicate how the system takes appropriate action when an audit process failure occurs.
      Is it the case that there is no evidence of appropriate action?
 SRG-OS-000047-GPOS-00023 AU-5(b), AU-5(2), AU-5(1), AU-5(4), CM-6(a)
xccdf_org.ssgproject.content_rule_auditd_data_disk_full_action_stig medium Configure auditd Disk Full Action when Disk Space Is Full Taking appropriate action in case of a filled audit storage volume will minimize the possibility of losing audit records. The auditd service can be configured to take an action when disk space is running low but prior to running out of space completely. Edit the file /etc/audit/auditd.conf. Add or modify the following line, substituting ACTION appropriately: 
disk_full_action = ACTION
Set this value to single to cause the system to switch to single-user mode for corrective action. Acceptable values also include syslog, single, and halt. For certain systems, the need for availability outweighs the need to log all actions, and a different setting should be determined. Details regarding all possible values for ACTION are described in the auditd.conf man page.		 
Verify Oracle Linux 9 takes the appropriate action when the audit storage volume is full.

Check that Oracle Linux 9 takes the appropriate action when the audit storage volume is full with the following command:

$ sudo grep disk_full_action /etc/audit/auditd.conf

disk_full_action = 

If the value of the "disk_full_action" option is not "SYSLOG", "SINGLE", or "HALT", or the line is commented out, ask the system administrator to indicate how the system takes appropriate action when an audit storage volume is full.
      Is it the case that there is no evidence of appropriate action?
 SRG-OS-000047-GPOS-00023 AU-5(b), AU-5(2), AU-5(1), AU-5(4), CM-6(a)
xccdf_org.ssgproject.content_rule_auditd_data_retention_action_mail_acct medium Configure auditd mail_acct Action on Low Disk Space Email sent to the root account is typically aliased to the administrators of the system, who can take appropriate action. The auditd service can be configured to send email to a designated account in certain situations. Add or correct the following line in /etc/audit/auditd.conf to ensure that administrators are notified via email for those situations: 
action_mail_acct = root
 
Verify that Oracle Linux 9 is configured to notify the SA and/or ISSO (at a minimum) in the event of an audit processing failure with the following command:


$ sudo grep action_mail_acct /etc/audit/auditd.conf

action_mail_acct = root

      Is it the case that the value of the "action_mail_acct" keyword is not set to "root" and/or other accounts for security personnel, the "action_mail_acct" keyword is missing, or the returned line is commented out, ask the system administrator to indicate how they and the ISSO are notified of an audit process failure. If there is no evidence of the proper personnel being notified of an audit processing failure?
 SRG-OS-000046-GPOS-00022, SRG-OS-000343-GPOS-00134 IA-5(1), AU-5(a), AU-5(2), CM-6(a)
xccdf_org.ssgproject.content_rule_auditd_data_retention_admin_space_left_action medium Configure auditd admin_space_left Action on Low Disk Space Administrators should be made aware of an inability to record audit records. If a separate partition or logical volume of adequate size is used, running low on space for audit records should never occur. The auditd service can be configured to take an action when disk space is running low but prior to running out of space completely. Edit the file /etc/audit/auditd.conf. Add or modify the following line, substituting ACTION appropriately: 
admin_space_left_action = ACTION
Set this value to single to cause the system to switch to single user mode for corrective action. Acceptable values also include suspend and halt. For certain systems, the need for availability outweighs the need to log all actions, and a different setting should be determined. Details regarding all possible values for ACTION are described in the auditd.conf man page.		 
Verify that Oracle Linux 9 is configured to take action in the event of allocated audit record storage volume reaches 95 percent of the repository maximum audit record storage capacity with the following command:


$ sudo grep admin_space_left_action /etc/audit/auditd.conf

admin_space_left_action = single


If the value of the "admin_space_left_action" is not set to "single", or if the line is commented out, ask the System Administrator to indicate how the system is providing real-time alerts to the SA and ISSO.
      Is it the case that there is no evidence that real-time alerts are configured on the system?
 SRG-OS-000343-GPOS-00134 AU-5(b), AU-5(2), AU-5(1), AU-5(4), CM-6(a)
xccdf_org.ssgproject.content_rule_auditd_data_retention_admin_space_left_percentage medium Configure auditd admin_space_left on Low Disk Space Notifying administrators of an impending disk space problem may allow them to take corrective action prior to any disruption. The auditd service can be configured to take an action when disk space is running low but prior to running out of space completely. Edit the file /etc/audit/auditd.conf. Add or modify the following line, substituting PERCENTAGE appropriately: 
admin_space_left = PERCENTAGE%
Set this value to 5 to cause the system to perform an action.		 
Verify Oracle Linux 9 takes action when allocated audit record storage volume reaches 95 percent of the repository maximum audit record storage capacity with the following command:


$ sudo grep -w admin_space_left /etc/audit/auditd.conf

admin_space_left = 5%


If the value of the "admin_space_left" keyword is not set to 5% of the storage volume allocated to audit logs, or if the line is commented out, ask the System Administrator to indicate how the system is taking action if the allocated storage is about to reach capacity.
      Is it the case that the "admin_space_left" value is not configured to the correct value?
 SRG-OS-000343-GPOS-00134 AU-5(b), AU-5(2), AU-5(1), AU-5(4), CM-6(a)
xccdf_org.ssgproject.content_rule_auditd_data_retention_max_log_file_action_stig medium Configure auditd max_log_file_action Upon Reaching Maximum Log Size Automatically rotating logs (by setting this to rotate) minimizes the chances of the system unexpectedly running out of disk space by being overwhelmed with log data. However, for systems that must never discard log data, or which use external processes to transfer it and reclaim space, keep_logs can be employed. The default action to take when the logs reach their maximum size is to rotate the log files, discarding the oldest one. To configure the action taken by auditd, add or correct the line in /etc/audit/auditd.conf: 
max_log_file_action = ACTION
Possible values for ACTION are described in the auditd.conf man page. These include:
  • ignore
  • syslog
  • suspend
  • rotate
  • keep_logs
Set the ACTION to rotate to ensure log rotation occurs. This is the default. The setting is case-insensitive.		 
Verify Oracle Linux 9 takes the appropriate action when the audit files have reached maximum size.

Check that Oracle Linux 9 takes the appropriate action when the audit files have reached maximum size with the following command:


$ sudo grep max_log_file_action /etc/audit/auditd.conf

max_log_file_action = 

      Is it the case that the value of the "max_log_file_action" option is not "ROTATE", "SINGLE", or the line is commented out, ask the system administrator to indicate how the system takes appropriate action when an audit storage volume is full. If there is no evidence of appropriate action?
 SRG-OS-000047-GPOS-00023, SRG-APP-000098-CTR-000185, SRG-APP-000099-CTR-000190, SRG-APP-000100-CTR-000195, SRG-APP-000100-CTR-000200, SRG-APP-000109-CTR-000215, SRG-APP-000290-CTR-000670, SRG-APP-000357-CTR-000800 AU-5(b), AU-5(2), AU-5(1), AU-5(4), CM-6(a)
xccdf_org.ssgproject.content_rule_auditd_data_retention_space_left_action medium Configure auditd space_left Action on Low Disk Space Notifying administrators of an impending disk space problem may allow them to take corrective action prior to any disruption. The auditd service can be configured to take an action when disk space starts to run low. Edit the file /etc/audit/auditd.conf. Modify the following line, substituting ACTION appropriately: 
space_left_action = ACTION
Possible values for ACTION are described in the auditd.conf man page. These include:
  • syslog
  • email
  • exec
  • suspend
  • single
  • halt
Set this to email (instead of the default, which is suspend) as it is more likely to get prompt attention. Acceptable values also include suspend, single, and halt.		 
Verify Oracle Linux 9 notifies the SA and ISSO (at a minimum) when allocated audit record storage volume reaches 75 percent of the repository maximum audit record storage capacity with the following command:


$ sudo grep -w space_left_action /etc/audit/auditd.conf

space_left_action = 


If the value of the "space_left_action" is not set to "", or if the line is commented out, ask the System Administrator to indicate how the system is providing real-time alerts to the SA and ISSO.
      Is it the case that there is no evidence that real-time alerts are configured on the system?
 SRG-OS-000343-GPOS-00134 AU-5(b), AU-5(2), AU-5(1), AU-5(4), CM-6(a)
xccdf_org.ssgproject.content_rule_auditd_data_retention_space_left_percentage medium Configure auditd space_left on Low Disk Space Notifying administrators of an impending disk space problem may allow them to take corrective action prior to any disruption. The auditd service can be configured to take an action when disk space is running low but prior to running out of space completely. Edit the file /etc/audit/auditd.conf. Add or modify the following line, substituting PERCENTAGE appropriately: 
space_left = PERCENTAGE%
Set this value to at least 25 to cause the system to notify the user of an issue.		 
Verify Oracle Linux 9 takes action when allocated audit record storage volume reaches 75 percent of the repository maximum audit record storage capacity with the following command:


$ sudo grep -w space_left /etc/audit/auditd.conf



space_left = %

      Is it the case that the value of the "space_left" keyword is not set to % of the storage volume allocated to audit logs, or if the line is commented out, ask the System Administrator to indicate how the system is providing real-time alerts to the SA and ISSO. If the "space_left" value is not configured to the correct value?
 SRG-OS-000343-GPOS-00134 AU-5(b), AU-5(2), AU-5(1), AU-5(4), CM-6(a)
xccdf_org.ssgproject.content_rule_auditd_freq medium Set number of records to cause an explicit flush to audit logs If option freq isn't set to , the flush to disk may happen after higher number of records, increasing the danger of audit loss. To configure Audit daemon to issue an explicit flush to disk command after writing 100 records, set freq to 100 in /etc/audit/auditd.conf. 
To verify that Audit Daemon is configured to flush to disk after
every 100 records, run the following command:

$ sudo grep freq /etc/audit/auditd.conf

The output should return the following:

freq = 100

      Is it the case that freq isn't set to 100?
 SRG-OS-000051-GPOS-00024 CM-6
xccdf_org.ssgproject.content_rule_auditd_local_events medium Include Local Events in Audit Logs If option local_events isn't set to yes only events from network will be aggregated. To configure Audit daemon to include local events in Audit logs, set local_events to yes in /etc/audit/auditd.conf. This is the default setting. 
To verify that Audit Daemon is configured to include local events, run the
following command:

$ sudo grep local_events /etc/audit/auditd.conf

The output should return the following:

local_events = yes

      Is it the case that local_events isn't set to yes?
 SRG-OS-000062-GPOS-00031, SRG-OS-000480-GPOS-00227 CM-6
xccdf_org.ssgproject.content_rule_auditd_log_format low Resolve information before writing to audit logs If option log_format isn't set to ENRICHED, the audit records will be stored in a format exactly as the kernel sends them. To configure Audit daemon to resolve all uid, gid, syscall, architecture, and socket address information before writing the events to disk, set log_format to ENRICHED in /etc/audit/auditd.conf. 
To verify that Audit Daemon is configured to resolve all uid, gid, syscall,
architecture, and socket address information before writing the event to disk,
run the following command:

$ sudo grep log_format /etc/audit/auditd.conf

The output should return the following:

log_format = ENRICHED

      Is it the case that log_format isn't set to ENRICHED?
 SRG-OS-000255-GPOS-00096, SRG-OS-000480-GPOS-00227, SRG-APP-000096-CTR-000175, SRG-APP-000097-CTR-000180, SRG-APP-000098-CTR-000185, SRG-APP-000099-CTR-000190, SRG-APP-000100-CTR-000195, SRG-APP-000100-CTR-000200, SRG-APP-000109-CTR-000215, SRG-APP-000290-CTR-000670, SRG-APP-000357-CTR-000800 CM-6, AU-3
xccdf_org.ssgproject.content_rule_auditd_name_format medium Set type of computer node name logging in audit logs If option name_format is left at its default value of none, audit events from different computers may be hard to distinguish. To configure Audit daemon to use a unique identifier as computer node name in the audit events, set name_format to hostname|fqd|numeric in /etc/audit/auditd.conf. 
To verify that Audit Daemon is configured to record the computer node
name in the audit events, run the following command:

$ sudo grep name_format /etc/audit/auditd.conf

The output should return the following:

name_format = hostname|fqd|numeric

      Is it the case that name_format isn't set to hostname|fqd|numeric?
 SRG-OS-000039-GPOS-00017, SRG-OS-000342-GPOS-00133, SRG-OS-000479-GPOS-00224 CM-6, AU-3
xccdf_org.ssgproject.content_rule_auditd_overflow_action medium Appropriate Action Must be Setup When the Internal Audit Event Queue is Full The audit system should have an action setup in the event the internal event queue becomes full so that no data is lost. The audit system should have an action setup in the event the internal event queue becomes full. To setup an overflow action edit /etc/audit/auditd.conf. Set overflow_action to one of the following values: syslog, single, halt. 
Verify the audit system is configured to take an appropriate action when the internal event queue is full:

$ sudo grep -i overflow_action /etc/audit/auditd.conf


The output should contain overflow_action = syslog

If the value of the "overflow_action" option is not set to syslog,
single, halt or the line is commented out, ask the System Administrator
to indicate how the audit logs are off-loaded to a different system or media.
      Is it the case that auditd overflow action is not set correctly?
 SRG-OS-000342-GPOS-00133, SRG-OS-000479-GPOS-00224 AU-4(1)
xccdf_org.ssgproject.content_rule_auditd_write_logs medium Write Audit Logs to the Disk If write_logs isn't set to yes, the Audit logs will not be written to the disk. To configure Audit daemon to write Audit logs to the disk, set write_logs to yes in /etc/audit/auditd.conf. This is the default setting. 
To verify that Audit Daemon is configured to write logs to the disk, run the
following command:

$ sudo grep write_logs /etc/audit/auditd.conf

The output should return the following:

write_logs = yes

      Is it the case that write_logs isn't set to yes?
 SRG-OS-000480-GPOS-00227 CM-6
xccdf_org.ssgproject.content_rule_banner_etc_issue medium Modify the System Login Banner Display of a standardized and approved use notification before granting access to the operating system ensures privacy and security notification verbiage used is consistent with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance.

System use notifications are required only for access via login interfaces with human users and are not required when such human interfaces do not exist.		 To configure the system login banner edit /etc/issue. Replace the default text with a message compliant with the local site policy or a legal disclaimer. The DoD required text is either:

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.

OR:

I've read & consent to terms in IS user agreem't.		 
To check if the system login banner is compliant,
run the following command:


$ cat /etc/issue

      Is it the case that it does not display the required banner?
 SRG-OS-000023-GPOS-00006, SRG-OS-000228-GPOS-00088 AC-8(a), AC-8(c)
xccdf_org.ssgproject.content_rule_chronyd_client_only low Disable chrony daemon from acting as server In order to prevent unauthorized connection of devices, unauthorized transfer of information, or unauthorized tunneling (i.e., embedding of data types within data types), organizations must disable or restrict unused or unnecessary physical and logical ports/protocols on information systems. Operating systems are capable of providing a wide variety of functions and services. Some of the functions and services provided by default may not be necessary to support essential organizational operations. Additionally, it is sometimes convenient to provide multiple services from a single component (e.g., VPN and IPS); however, doing so increases risk over limiting the services provided by any one component. To support the requirements and principles of least functionality, the operating system must support the organizational requirements, providing only essential capabilities and limiting the use of ports, protocols, and/or services to only those required, authorized, and approved to conduct official business or to address authorized quality of life issues. The port option in /etc/chrony.conf can be set to 0 to make chrony daemon to never open any listening port for server operation and to operate strictly in a client-only mode. 
Verify Oracle Linux 9 disables the chrony daemon from acting as a server with the following command:

$ grep -w port /etc/chrony.conf


port 0

      Is it the case that the "port" option is not set to "0", is commented out, or is missing?
 SRG-OS-000096-GPOS-00050, SRG-OS-000095-GPOS-00049 AU-8(1), AU-12(1)
xccdf_org.ssgproject.content_rule_chronyd_no_chronyc_network low Disable network management of chrony daemon Minimizing the exposure of the server functionality of the chrony daemon diminishes the attack surface. The cmdport option in /etc/chrony.conf can be set to 0 to stop chrony daemon from listening on the UDP port 323 for management connections made by chronyc. 
Verify Oracle Linux 9 disables network management of the chrony daemon with the following command:

$ grep -w cmdport /etc/chrony.conf


cmdport 0

      Is it the case that the "cmdport" option is not set to "0", is commented out, or is missing?
 SRG-OS-000096-GPOS-00050, SRG-OS-000095-GPOS-00049 CM-7(1)
xccdf_org.ssgproject.content_rule_chronyd_or_ntpd_set_maxpoll medium Configure Time Service Maxpoll Interval Inaccurate time stamps make it more difficult to correlate events and can lead to an inaccurate analysis. Determining the correct time a particular event occurred on a system is critical when conducting forensic analysis and investigating system events. Sources outside the configured acceptable allowance (drift) may be inaccurate. Synchronizing internal information system clocks provides uniformity of time stamps for information systems with multiple system clocks and systems connected over a network. Organizations should consider endpoints that may not have regular access to the authoritative time server (e.g., mobile, teleworking, and tactical endpoints). The maxpoll should be configured to 16 in /etc/ntp.conf or /etc/chrony.conf (or /etc/chrony.d/) to continuously poll time servers. To configure maxpoll in /etc/ntp.conf or /etc/chrony.conf (or /etc/chrony.d/) add the following after each server, pool or peer entry: 
maxpoll 16
to server directives. If using chrony, any pool directives should be configured too.		 
Verify Oracle Linux 9 is securely comparing internal information system clocks at a regular interval with an NTP server with the following command:

$ sudo grep maxpoll /etc/ntp.conf /etc/chrony.conf /etc/chrony.d/


server [ntp.server.name] iburst maxpoll 16
.
      Is it the case that "maxpoll" has not been set to the value of "16", is commented out, or is missing?
 SRG-OS-000355-GPOS-00143, SRG-OS-000356-GPOS-00144, SRG-OS-000359-GPOS-00146 CM-6(a), AU-8(1)(b), AU-12(1)
xccdf_org.ssgproject.content_rule_chronyd_server_directive medium Ensure Chrony is only configured with the server directive Depending on the infrastructure being used the pool directive may not be supported. Using the server directive allows for better control of where the system gets time data from. Check that Chrony only has time sources configured with the server directive. 
Run the following command and verify that time sources are only configured with server directive:

# grep -E "^(server|pool)" /etc/chrony.conf

A line with the appropriate server should be returned, any line returned starting with pool is a finding.
      Is it the case that an authoritative remote time server is not configured or configured with pool directive?
 SRG-OS-000355-GPOS-00143, SRG-OS-000356-GPOS-00144, SRG-OS-000359-GPOS-00146
xccdf_org.ssgproject.content_rule_clean_components_post_updating low Ensure yum Removes Previous Package Versions Previous versions of software components that are not removed from the information system after updates have been installed may be exploited by some adversaries. yum should be configured to remove previous software components after new versions have been installed. To configure yum to remove the previous software components after updating, set the clean_requirements_on_remove to 1 in /etc/yum.conf. 
Verify Oracle Linux 9 removes all software components after updated versions have been installed.



$ grep clean_requirements_on_remove /etc/yum.conf


clean_requirements_on_remove=1

      Is it the case that '"clean_requirements_on_remove" is not set to "1"'?
 SRG-OS-000437-GPOS-00194 SI-2(6), CM-11(a), CM-11(b), CM-6(a)
xccdf_org.ssgproject.content_rule_configure_bind_crypto_policy high Configure BIND to use System Crypto Policy Overriding the system crypto policy makes the behavior of the BIND service violate expectations, and makes system configuration more fragmented. Crypto Policies provide a centralized control over crypto algorithms usage of many packages. BIND is supported by crypto policy, but the BIND configuration may be set up to ignore it. To check that Crypto Policies settings are configured correctly, ensure that the /etc/named.conf includes the appropriate configuration: In the options section of /etc/named.conf, make sure that the following line is not commented out or superseded by later includes: include "/etc/crypto-policies/back-ends/bind.config"; 
To verify that BIND uses the system crypto policy, check out that the BIND config file

/etc/named.conf
 contains the 
include "/etc/crypto-policies/back-ends/bind.config";

directive:

$ sudo grep 'include "/etc/crypto-policies/back-ends/bind.config";' /etc/named.conf

Verify that the directive is at the bottom of the 
options
 section of the config file.
      Is it the case that BIND is installed and the BIND config file doesn't contain the

include "/etc/crypto-policies/back-ends/bind.config";
 directive?
 SRG-OS-000423-GPOS-00187, SRG-OS-000426-GPOS-00190 SC-13, SC-12(2), SC-12(3)
xccdf_org.ssgproject.content_rule_configure_crypto_policy high Configure System Cryptography Policy Centralized cryptographic policies simplify applying secure ciphers across an operating system and the applications that run on that operating system. Use of weak or untested encryption algorithms undermines the purposes of utilizing encryption to protect data. To configure the system cryptography policy to use ciphers only from the FIPS policy, run the following command: 
$ sudo update-crypto-policies --set FIPS
The rule checks if settings for selected crypto policy are configured as expected. Configuration files in the /etc/crypto-policies/back-ends are either symlinks to correct files provided by Crypto-policies package or they are regular files in case crypto policy customizations are applied. Crypto policies may be customized by crypto policy modules, in which case it is delimited from the base policy using a colon.		 
To verify that cryptography policy has been configured correctly, run the
following command:

$ update-crypto-policies --show

The output should return 
FIPS
.
Run the command to check if the policy is correctly applied:

$ update-crypto-policies --is-applied

The output should be 
The configured policy is applied
.
Moreover, check if settings for selected crypto policy are as expected.
List all libraries for which it holds that their crypto policies do not have symbolic link in 
/etc/crypto-policies/back-ends
.

$ ls -l /etc/crypto-policies/back-ends/ | grep '^[^l]' | tail -n +2 | awk -F' ' '{print $NF}' | awk -F'.' '{print $1}' | sort

Subsequently, check if matching libraries have drop in files in the 
/etc/crypto-policies/local.d
 directory.

$ ls /etc/crypto-policies/local.d/ | awk -F'-' '{print $1}' | uniq | sort

Outputs of two previous commands should match.
      Is it the case that cryptographic policy is not configured or is configured incorrectly?
 SRG-OS-000396-GPOS-00176, SRG-OS-000393-GPOS-00173, SRG-OS-000394-GPOS-00174 AC-17(a), AC-17(2), CM-6(a), MA-4(6), SC-13, SC-12(2), SC-12(3)
xccdf_org.ssgproject.content_rule_configure_firewalld_ports medium Configure the Firewalld Ports In order to prevent unauthorized connection of devices, unauthorized transfer of information, or unauthorized tunneling (i.e., embedding of data types within data types), organizations must disable or restrict unused or unnecessary physical and logical ports/protocols on information systems.

Operating systems are capable of providing a wide variety of functions and services. Some of the functions and services provided by default may not be necessary to support essential organizational operations. Additionally, it is sometimes convenient to provide multiple services from a single component (e.g., VPN and IPS); however, doing so increases risk over limiting the services provided by one component.

To support the requirements and principles of least functionality, the operating system must support the organizational requirements, providing only essential capabilities and limiting the use of ports, protocols, and/or services to only those required, authorized, and approved to conduct official business.		 Configure the firewalld ports to allow approved services to have access to the system. To configure firewalld to open ports, run the following command: 
firewall-cmd --permanent --add-port=port_number/tcp
To configure firewalld to allow access for pre-defined services, run the following command: 
firewall-cmd --permanent --add-service=service_name
 
Inspect the list of enabled firewall ports and verify they are configured correctly by running
the following command:


$ sudo firewall-cmd --list-all


Ask the System Administrator for the site or program Ports, Protocols, and Services Management Component Local Service Assessment (PPSM CLSA). Verify the services allowed by the firewall match the PPSM CLSA.
      Is it the case that there are additional ports, protocols, or services that are not in the PPSM CLSA, or there are ports, protocols, or services that are prohibited by the PPSM Category Assurance List (CAL), or there are no firewall rules configured?
 SRG-OS-000096-GPOS-00050, SRG-OS-000297-GPOS-00115 AC-4, CM-7(b), CA-3(5), SC-7(21), CM-6(a)
xccdf_org.ssgproject.content_rule_configure_kerberos_crypto_policy high Configure Kerberos to use System Crypto Policy Overriding the system crypto policy makes the behavior of Kerberos violate expectations, and makes system configuration more fragmented. Crypto Policies provide a centralized control over crypto algorithms usage of many packages. Kerberos is supported by crypto policy, but it's configuration may be set up to ignore it. To check that Crypto Policies settings for Kerberos are configured correctly, examine that there is a symlink at /etc/krb5.conf.d/crypto-policies targeting /etc/cypto-policies/back-ends/krb5.config. If the symlink exists, Kerberos is configured to use the system-wide crypto policy settings. 
Check that the symlink exists and target the correct Kerberos crypto policy, with the following command:

file /etc/krb5.conf.d/crypto-policies

If command output shows the following line, Kerberos is configured to use the system-wide crypto policy.

/etc/krb5.conf.d/crypto-policies: symbolic link to /etc/crypto-policies/back-ends/krb5.config

      Is it the case that the symlink does not exist or points to a different target?
 SRG-OS-000120-GPOS-00061 SC-13, SC-12(2), SC-12(3)
xccdf_org.ssgproject.content_rule_configure_libreswan_crypto_policy high Configure Libreswan to use System Crypto Policy Overriding the system crypto policy makes the behavior of the Libreswan service violate expectations, and makes system configuration more fragmented. Crypto Policies provide a centralized control over crypto algorithms usage of many packages. Libreswan is supported by system crypto policy, but the Libreswan configuration may be set up to ignore it. To check that Crypto Policies settings are configured correctly, ensure that the /etc/ipsec.conf includes the appropriate configuration file. In /etc/ipsec.conf, make sure that the following line is not commented out or superseded by later includes: include /etc/crypto-policies/back-ends/libreswan.config 
Verify that the IPSec service uses the system crypto policy.

If the ipsec service is not installed is not applicable.

Check to see if the "IPsec" service is active with the following command:

$ systemctl status ipsec

ipsec.service - Internet Key Exchange (IKE) Protocol Daemon for IPsec
Loaded: loaded (/usr/lib/systemd/system/ipsec.service; disabled)
Active: inactive (dead)

If the "IPsec" service is active, check to see if it is using the system crypto policy with the following command:

$ sudo grep include /etc/ipsec.conf /etc/ipsec.d/*.conf

/etc/ipsec.conf:include /etc/crypto-policies/back-ends/libreswan.config
      Is it the case that the "IPsec" service is active and the ipsec configuration file does not contain does not contain include /etc/crypto-policies/back-ends/libreswan.config?
 SRG-OS-000033-GPOS-00014 CM-6(a), MA-4(6), SC-13, SC-12(2), SC-12(3)
xccdf_org.ssgproject.content_rule_configure_opensc_card_drivers medium Configure opensc Smart Card Drivers Smart card login provides two-factor authentication stronger than that provided by a username and password combination. Smart cards leverage PKI (public key infrastructure) in order to provide and verify credentials. Configuring the smart card driver in use by your organization helps to prevent users from using unauthorized smart cards. The OpenSC smart card tool can auto-detect smart card drivers; however, setting the smart card drivers in use by your organization helps to prevent users from using unauthorized smart cards. The default smart card driver for this profile is cac. To configure the OpenSC driver, edit the /etc/opensc.conf and add the following line into the file in the app default block, so it will look like: 
app default {
   ...
   card_drivers = cac;
}

Verify that Oracle Linux 9 loads the cac driver with the following command:


$ grep card_drivers /etc/opensc.conf



card_drivers = cac;

      Is it the case that "cac" is not listed as a card driver, or there is no line returned for "card_drivers"?
 SRG-OS-000104-GPOS-00051, SRG-OS-000106-GPOS-00053, SRG-OS-000107-GPOS-00054, SRG-OS-000109-GPOS-00056, SRG-OS-000108-GPOS-00055, SRG-OS-000108-GPOS-00057, SRG-OS-000108-GPOS-00058 IA-2(1), IA-2(2), IA-2(3), IA-2(4), IA-2(6), IA-2(7), IA-2(11), CM-6(a)
xccdf_org.ssgproject.content_rule_configure_usbguard_auditbackend low Log USBGuard daemon audit events using Linux Audit Using the Linux Audit logging allows for centralized trace of events. To configure USBGuard daemon to log via Linux Audit (as opposed directly to a file), AuditBackend option in /etc/usbguard/usbguard-daemon.conf needs to be set to LinuxAudit. 
To verify that Linux Audit logging is enabled for the USBGuard daemon,
run the following command:

$ sudo grep AuditBackend /etc/usbguard/usbguard-daemon.conf

The output should be

AuditBackend=LinuxAudit

      Is it the case that AuditBackend is not set to LinuxAudit?
 SRG-OS-000062-GPOS-00031, SRG-OS-000471-GPOS-00215, SRG-APP-000141-CTR-000315 AU-2, CM-8(3), IA-3
xccdf_org.ssgproject.content_rule_configured_firewalld_default_deny medium Firewalld Must Employ a Deny-all, Allow-by-exception Policy for Allowing Connections to Other Systems Failure to restrict network connectivity only to authorized systems permits inbound connections from malicious systems. It also permits outbound connections that may facilitate exfiltration of data. Oracle Linux 9 incorporates the "firewalld" daemon, which allows for many different configurations. One of these configurations is zones. Zones can be utilized to a deny-all, allow-by-exception approach. The default "drop" zone will drop all incoming network packets unless it is explicitly allowed by the configuration file or is related to an outgoing network connection. 
Verify "firewalld" is configured to employ a deny-all, allow-by-exception policy for allowing connections to other systems with the following commands:

$ sudo firewall-cmd --state

running

$ sudo firewall-cmd --get-active-zones

[custom]
interfaces: ens33

$ sudo firewall-cmd --info-zone=[custom] | grep target

target: DROP
      Is it the case that no zones are active on the interfaces or if the target is set to a different option other than "DROP"?
 SRG-OS-000297-GPOS-00115 AC-17 (1)
xccdf_org.ssgproject.content_rule_coredump_disable_backtraces medium Disable core dump backtraces A core dump includes a memory image taken at the time the operating system terminates an application. The memory image could contain sensitive data and is generally useful only for developers or system operators trying to debug problems. Enabling core dumps on production systems is not recommended, however there may be overriding operational requirements to enable advanced debugging. Permitting temporary enablement of core dumps during such situations should be reviewed through local needs and policy. The ProcessSizeMax option in [Coredump] section of /etc/systemd/coredump.conf or in a drop-in file under /etc/systemd/coredump.conf.d/ specifies the maximum size in bytes of a core which will be processed. Core dumps exceeding this size may be stored, but the backtrace will not be generated. 
Verify Oracle Linux 9 disables core dump backtraces by issuing the following command:


$ grep -i process /etc/systemd/coredump.conf /etc/systemd/coredump.conf.d/*.conf

ProcessSizeMax=0

      Is it the case that the "ProcessSizeMax" item is missing, 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?
 SRG-OS-000480-GPOS-00227 CM-6
xccdf_org.ssgproject.content_rule_coredump_disable_storage medium Disable storing core dump A core dump includes a memory image taken at the time the operating system terminates an application. The memory image could contain sensitive data and is generally useful only for developers or system operators trying to debug problems. Enabling core dumps on production systems is not recommended, however there may be overriding operational requirements to enable advanced debugging. Permitting temporary enablement of core dumps during such situations should be reviewed through local needs and policy. The Storage option in [Coredump] section of /etc/systemd/coredump.conf or a drop-in file in /etc/systemd/coredump.conf.d/*.conf can be set to none to disable storing core dumps permanently. 
Verify Oracle Linux 9 disables storing core dumps for all users by issuing the following command:

$ grep -i storage /etc/systemd/coredump.conf /etc/systemd/coredump.conf.d/*.conf

Storage=none
      Is it the case that Storage is not set to none or is commented out 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?
 SRG-OS-000480-GPOS-00227 CM-6
xccdf_org.ssgproject.content_rule_dconf_db_up_to_date high Make sure that the dconf databases are up-to-date with regards to respective keyfiles Unlike text-based keyfiles, the binary database is impossible to check by OVAL. Therefore, in order to evaluate dconf configuration, both have to be true at the same time - configuration files have to be compliant, and the database needs to be more recent than those keyfiles, which gives confidence that it reflects them. By default, DConf uses a binary database as a data backend. The system-level database is compiled from keyfiles in the /etc/dconf/db/ directory by the 
dconf update
command. More specifically, content present in the following directories: 
/etc/dconf/db/local.d
/etc/dconf/db/local.d
 
In order to be sure that the databases are up-to-date, run the

dconf update

command as the administrator.
      Is it the case that The system-wide dconf databases are up-to-date with regards to respective keyfiles?
 SRG-OS-000480-GPOS-00227
xccdf_org.ssgproject.content_rule_dconf_gnome_banner_enabled medium Enable GNOME3 Login Warning Banner Display of a standardized and approved use notification before granting access to the operating system ensures privacy and security notification verbiage used is consistent with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance.

For U.S. Government systems, system use notifications are required only for access via login interfaces with human users and are not required when such human interfaces do not exist.		 In the default graphical environment, displaying a login warning banner in the GNOME Display Manager's login screen can be enabled on the login screen by setting banner-message-enable to true.

To enable, add or edit banner-message-enable to /etc/dconf/db/local.d/00-security-settings. For example: 
[org/gnome/login-screen]
banner-message-enable=true
Once the setting has been added, add a lock to /etc/dconf/db/local.d/locks/00-security-settings-lock to prevent user modification. For example: 
/org/gnome/login-screen/banner-message-enable
After the settings have been set, run dconf update. The banner text must also be set.		 
To ensure a login warning banner is enabled, run the following:

$ grep banner-message-enable /etc/dconf/db/local.d/*

If properly configured, the output should be true.
To ensure a login warning banner is locked and cannot be changed by a user, run the following:

$ grep banner-message-enable /etc/dconf/db/local.d/locks/*

If properly configured, the output should be /org/gnome/login-screen/banner-message-enable.
      Is it the case that it is not?
 SRG-OS-000023-GPOS-00006, SRG-OS-000228-GPOS-00088 AC-8(a), AC-8(b), AC-8(c)
xccdf_org.ssgproject.content_rule_dconf_gnome_disable_automount_open medium Disable GNOME3 Automount Opening Automatically mounting file systems permits easy introduction of unknown devices, thereby facilitating malicious activity. Disabling automatic mounting in GNOME3 can prevent the introduction of malware via removable media. It will, however, also prevent desktop users from legitimate use of removable media. The system's default desktop environment, GNOME3, will mount devices and removable media (such as DVDs, CDs and USB flash drives) whenever they are inserted into the system. To disable automount-open within GNOME3, add or set automount-open to false in /etc/dconf/db/local.d/00-security-settings. For example: 
[org/gnome/desktop/media-handling]
automount-open=false
Once the settings have been added, add a lock to /etc/dconf/db/local.d/locks/00-security-settings-lock to prevent user modification. For example: 
/org/gnome/desktop/media-handling/automount-open
After the settings have been set, run dconf update.		 
These settings can be verified by running the following:

$ gsettings get org.gnome.desktop.media-handling automount-open

If properly configured, the output for automount-openshould be false.
To ensure that users cannot enable automount opening in GNOME3, run the following:

$ grep 'automount-open' /etc/dconf/db/local.d/locks/*

If properly configured, the output for automount-open should be /org/gnome/desktop/media-handling/automount-open
      Is it the case that GNOME automounting is not disabled?
 SRG-OS-000114-GPOS-00059, SRG-OS-000378-GPOS-00163, SRG-OS-000480-GPOS-00227 CM-7(a), CM-7(b), CM-6(a)
xccdf_org.ssgproject.content_rule_dconf_gnome_disable_autorun low Disable GNOME3 Automount running Automatically mounting file systems permits easy introduction of unknown devices, thereby facilitating malicious activity. Disabling automatic mount running in GNOME3 can prevent the introduction of malware via removable media. It will, however, also prevent desktop users from legitimate use of removable media. The system's default desktop environment, GNOME3, will mount devices and removable media (such as DVDs, CDs and USB flash drives) whenever they are inserted into the system. To disable autorun-never within GNOME3, add or set autorun-never to true in /etc/dconf/db/local.d/00-security-settings. For example: 
[org/gnome/desktop/media-handling]
autorun-never=true
Once the settings have been added, add a lock to /etc/dconf/db/local.d/locks/00-security-settings-lock to prevent user modification. For example: 
/org/gnome/desktop/media-handling/autorun-never
After the settings have been set, run dconf update.		 
These settings can be verified by running the following:

$ gsettings get org.gnome.desktop.media-handling autorun-never

If properly configured, the output for autorun-nevershould be true.
To ensure that users cannot enable autorun in GNOME3, run the following:

$ grep 'autorun-never' /etc/dconf/db/local.d/locks/*

If properly configured, the output for autorun-never should be /org/gnome/desktop/media-handling/autorun-never
      Is it the case that GNOME autorun is not disabled?
 SRG-OS-000114-GPOS-00059, SRG-OS-000378-GPOS-00163, SRG-OS-000480-GPOS-00227 CM-7(a), CM-7(b), CM-6(a)
xccdf_org.ssgproject.content_rule_dconf_gnome_disable_ctrlaltdel_reboot high Disable Ctrl-Alt-Del Reboot Key Sequence in GNOME3 A locally logged-in user who presses Ctrl-Alt-Del, when at the console, can reboot the system. If accidentally pressed, as could happen in the case of mixed OS environment, this can create the risk of short-term loss of availability of systems due to unintentional reboot. By default, GNOME will reboot the system if the Ctrl-Alt-Del key sequence is pressed.

To configure the system to ignore the Ctrl-Alt-Del key sequence from the Graphical User Interface (GUI) instead of rebooting the system, add or set logout to [''] in /etc/dconf/db/local.d/00-security-settings. For example: 
[org/gnome/settings-daemon/plugins/media-keys]
logout=['']
Once the settings have been added, add a lock to /etc/dconf/db/local.d/locks/00-security-settings-lock to prevent user modification. For example: 
/org/gnome/settings-daemon/plugins/media-keys/logout
After the settings have been set, run dconf update.		 
To ensure the system is configured to ignore the Ctrl-Alt-Del sequence,
run the following command:

$ gsettings get org.gnome.settings-daemon.plugins.media-keys logout


$ grep logout /etc/dconf/db/local.d/locks/*

If properly configured, the output should be
/org/gnome/settings-daemon/plugins/media-keys/logout
      Is it the case that GNOME3 is configured to reboot when Ctrl-Alt-Del is pressed?
 SRG-OS-000480-GPOS-00227 CM-6(a), AC-6(1), CM-7(b)
xccdf_org.ssgproject.content_rule_dconf_gnome_disable_restart_shutdown high Disable the GNOME3 Login Restart and Shutdown Buttons A user who is at the console can reboot the system at the login screen. If restart or shutdown buttons are pressed at the login screen, this can create the risk of short-term loss of availability of systems due to reboot. In the default graphical environment, users logging directly into the system are greeted with a login screen that allows any user, known or unknown, the ability the ability to shutdown or restart the system. This functionality should be disabled by setting disable-restart-buttons to true.

To disable, add or edit disable-restart-buttons to /etc/dconf/db/local.d/00-security-settings. For example: 
[org/gnome/login-screen]
disable-restart-buttons=true
Once the setting has been added, add a lock to /etc/dconf/db/local.d/locks/00-security-settings-lock to prevent user modification. For example: 
/org/gnome/login-screen/disable-restart-buttons
After the settings have been set, run dconf update.		 
To ensure disable and restart on the login screen are disabled, run the following command:

$ grep disable-restart-buttons /etc/dconf/db/local.d/*

The output should be true.
To ensure that users cannot enable disable and restart on the login screen, run the following:

$ grep disable-restart-buttons /etc/dconf/db/local.d/locks/*

If properly configured, the output should be /org/gnome/login-screen/disable-restart-buttons
      Is it the case that disable-restart-buttons has not been configured or is not disabled?
 SRG-OS-000480-GPOS-00227 CM-6(a), AC-6(1), CM-7(b)
xccdf_org.ssgproject.content_rule_dconf_gnome_disable_user_list medium Disable the GNOME3 Login User List Leaving the user list enabled is a security risk since it allows anyone with physical access to the system to quickly enumerate known user accounts without logging in. In the default graphical environment, users logging directly into the system are greeted with a login screen that displays all known users. This functionality should be disabled by setting disable-user-list to true.

To disable, add or edit disable-user-list to /etc/dconf/db/local.d/00-security-settings. For example: 
[org/gnome/login-screen]
disable-user-list=true
Once the setting has been added, add a lock to /etc/dconf/db/local.d/locks/00-security-settings-lock to prevent user modification. For example: 
/org/gnome/login-screen/disable-user-list
After the settings have been set, run dconf update.		 
To ensure the user list is disabled, run the following command:

$ grep disable-user-list /etc/dconf/db/local.d/*

The output should be true.
To ensure that users cannot enable displaying the user list, run the following:

$ grep disable-user-list /etc/dconf/db/local.d/locks/*

If properly configured, the output should be /org/gnome/login-screen/disable-user-list
      Is it the case that disable-user-list has not been configured or is not disabled?
 SRG-OS-000480-GPOS-00227 CM-6(a), AC-23
xccdf_org.ssgproject.content_rule_dconf_gnome_lock_screen_on_smartcard_removal medium Enable the GNOME3 Screen Locking On Smartcard Removal Locking the screen automatically when removing the smartcard can prevent undesired access to system. In the default graphical environment, screen locking on smartcard removal can be enabled by setting removal-action to 'lock-screen'.

To enable, add or edit removal-action to /etc/dconf/db/local.d/00-security-settings. For example: 
[org/gnome/settings-daemon/peripherals/smartcard]
removal-action='lock-screen'
Once the setting has been added, add a lock to /etc/dconf/db/local.d/locks/00-security-settings-lock to prevent user modification. For example: 
/org/gnome/settings-daemon/peripherals/smartcard/removal-action
After the settings have been set, run dconf update.		 
To ensure screen locking on smartcard removal is enabled, run the following command:

$ grep removal-action /etc/dconf/db/local.d/*

The output should be 'lock-screen'.
To ensure that users cannot disable screen locking on smartcard removal, run the following:

$ grep removal-action /etc/dconf/db/local.d/locks/*

If properly configured, the output should be /org/gnome/settings-daemon/peripherals/smartcard/removal-action
      Is it the case that removal-action has not been configured?
 SRG-OS-000028-GPOS-00009, SRG-OS-000030-GPOS-00011
xccdf_org.ssgproject.content_rule_dconf_gnome_login_banner_text medium Set the GNOME3 Login Warning Banner Text An appropriate warning message reinforces policy awareness during the logon process and facilitates possible legal action against attackers. In the default graphical environment, configuring the login warning banner text in the GNOME Display Manager's login screen can be configured on the login screen by setting banner-message-text to 'APPROVED_BANNER' where APPROVED_BANNER is the approved banner for your environment.

To enable, add or edit banner-message-text to /etc/dconf/db/local.d/00-security-settings. For example: 
[org/gnome/login-screen]
banner-message-text='APPROVED_BANNER'
Once the setting has been added, add a lock to /etc/dconf/db/local.d/locks/00-security-settings-lock to prevent user modification. For example: 
/org/gnome/login-screen/banner-message-text
After the settings have been set, run dconf update. When entering a warning banner that spans several lines, remember to begin and end the string with ' and use \n for new lines.		 
To ensure the login warning banner text is properly set, run the following:

$ grep banner-message-text /etc/dconf/db/local.d/*

If properly configured, the proper banner text will appear.
To ensure the login warning banner text is locked and cannot be changed by a user, run the following:

$ grep banner-message-text /etc/dconf/db/local.d/locks/*

If properly configured, the output should be /org/gnome/login-screen/banner-message-text.
      Is it the case that it does not?
 SRG-OS-000023-GPOS-00006, SRG-OS-000228-GPOS-00088 AC-8(a), AC-8(c)
xccdf_org.ssgproject.content_rule_dconf_gnome_screensaver_idle_delay medium Set GNOME3 Screensaver Inactivity Timeout A session time-out lock is a temporary action taken when a user stops work and moves away from the immediate physical vicinity of the information system but does not logout because of the temporary nature of the absence. Rather than relying on the user to manually lock their operating system session prior to vacating the vicinity, GNOME3 can be configured to identify when a user's session has idled and take action to initiate a session lock. The idle time-out value for inactivity in the GNOME3 desktop is configured via the idle-delay setting must be set under an appropriate configuration file(s) in the /etc/dconf/db/local.d directory and locked in /etc/dconf/db/local.d/locks directory to prevent user modification.

For example, to configure the system for a 15 minute delay, add the following to /etc/dconf/db/local.d/00-security-settings: 
[org/gnome/desktop/session]
idle-delay=uint32 900
 
To check the current idle time-out value, run the following command:

$ gsettings get org.gnome.desktop.session idle-delay

If properly configured, the output should be 'uint32 '.
To ensure that users cannot change the screensaver inactivity timeout setting, run the following:

$ grep idle-delay /etc/dconf/db/local.d/locks/*

If properly configured, the output should be /org/gnome/desktop/session/idle-delay
      Is it the case that idle-delay is set to 0 or a value greater than ?
 SRG-OS-000029-GPOS-00010, SRG-OS-000031-GPOS-00012 AC-11(a), CM-6(a)
xccdf_org.ssgproject.content_rule_dconf_gnome_screensaver_lock_delay medium Set GNOME3 Screensaver Lock Delay After Activation Period A session lock is a temporary action taken when a user stops work and moves away from the immediate physical vicinity of the information system but does not want to logout because of the temporary nature of the absence. To activate the locking delay of the screensaver in the GNOME3 desktop when the screensaver is activated, add or set lock-delay to uint32 5 in /etc/dconf/db/local.d/00-security-settings. For example: 
[org/gnome/desktop/screensaver]
lock-delay=uint32 5
After the settings have been set, run dconf update.		 
To check that the screen locks immediately when activated, run the following command:

$ gsettings get org.gnome.desktop.screensaver lock-delay

If properly configured, the output should be 'uint32 5'.
      Is it the case that the screensaver lock delay is missing, or is set to a value greater than 5?
 SRG-OS-000029-GPOS-00010, SRG-OS-000031-GPOS-00012 AC-11(a), CM-6(a)
xccdf_org.ssgproject.content_rule_dconf_gnome_screensaver_lock_enabled medium Enable GNOME3 Screensaver Lock After Idle Period A session lock is a temporary action taken when a user stops work and moves away from the immediate physical vicinity of the information system but does not want to logout because of the temporary nature of the absence. To activate locking of the screensaver in the GNOME3 desktop when it is activated, add or set lock-enabled to true in /etc/dconf/db/local.d/00-security-settings. For example: 
[org/gnome/desktop/screensaver]
lock-enabled=true
Once the settings have been added, add a lock to /etc/dconf/db/local.d/locks/00-security-settings-lock to prevent user modification. For example: 
/org/gnome/desktop/screensaver/lock-enabled
After the settings have been set, run dconf update.		 
To check the status of the idle screen lock activation, run the following command:


$ gsettings get org.gnome.desktop.screensaver lock-enabled

If properly configured, the output should be true.
To ensure that users cannot change how long until the screensaver locks, run the following:

$ grep lock-enabled /etc/dconf/db/local.d/locks/*

If properly configured, the output for lock-enabled should be /org/gnome/desktop/screensaver/lock-enabled
      Is it the case that screensaver locking is not enabled and/or has not been set or configured correctly?
 SRG-OS-000028-GPOS-00009, SRG-OS-000030-GPOS-00011 CM-6(a)
xccdf_org.ssgproject.content_rule_dconf_gnome_screensaver_mode_blank medium Implement Blank Screensaver Setting the screensaver mode to blank-only conceals the contents of the display from passersby. To set the screensaver mode in the GNOME3 desktop to a blank screen, add or set picture-uri to string '' in /etc/dconf/db/local.d/00-security-settings. For example: 
[org/gnome/desktop/screensaver]
picture-uri=string ''
Once the settings have been added, add a lock to /etc/dconf/db/local.d/locks/00-security-settings-lock to prevent user modification. For example: 
/org/gnome/desktop/screensaver/picture-uri
After the settings have been set, run dconf update.		 
To ensure the screensaver is configured to be blank, run the following command:

$ gsettings get org.gnome.desktop.screensaver picture-uri

If properly configured, the output should be ''.

To ensure that users cannot set the screensaver background, run the following:

$ grep picture-uri /etc/dconf/db/local.d/locks/*

If properly configured, the output should be /org/gnome/desktop/screensaver/picture-uri
      Is it the case that it is not set or configured properly?
 SRG-OS-000031-GPOS-00012 AC-11(1), CM-6(a), AC-11(1).1
xccdf_org.ssgproject.content_rule_dconf_gnome_screensaver_user_locks medium Ensure Users Cannot Change GNOME3 Screensaver Settings A session time-out lock is a temporary action taken when a user stops work and moves away from the immediate physical vicinity of the information system but does not logout because of the temporary nature of the absence. Rather than relying on the user to manually lock their operating system session prior to vacating the vicinity, GNOME desktops can be configured to identify when a user's session has idled and take action to initiate the session lock. As such, users should not be allowed to change session settings. If not already configured, ensure that users cannot change GNOME3 screensaver lock settings by adding /org/gnome/desktop/screensaver/lock-delay to /etc/dconf/db/local.d/locks/00-security-settings-lock to prevent user modification. For example: 
/org/gnome/desktop/screensaver/lock-delay
After the settings have been set, run dconf update.		 
To ensure that users cannot change session idle and lock settings, run the following:

$ grep 'lock-delay' /etc/dconf/db/local.d/locks/*

If properly configured, the output should return:
/org/gnome/desktop/screensaver/lock-delay
      Is it the case that GNOME3 session settings are not locked or configured properly?
 SRG-OS-000029-GPOS-00010, SRG-OS-000031-GPOS-00012 CM-6(a)
xccdf_org.ssgproject.content_rule_dconf_gnome_session_idle_user_locks medium Ensure Users Cannot Change GNOME3 Session Idle Settings A session time-out lock is a temporary action taken when a user stops work and moves away from the immediate physical vicinity of the information system but does not logout because of the temporary nature of the absence. Rather than relying on the user to manually lock their operating system session prior to vacating the vicinity, GNOME desktops can be configured to identify when a user's session has idled and take action to initiate the session lock. As such, users should not be allowed to change session settings. If not already configured, ensure that users cannot change GNOME3 session idle settings by adding /org/gnome/desktop/session/idle-delay to /etc/dconf/db/local.d/locks/00-security-settings-lock to prevent user modification. For example: 
/org/gnome/desktop/session/idle-delay
After the settings have been set, run dconf update.		 
To ensure that users cannot change session idle and lock settings, run the following:

$ grep 'idle-delay' /etc/dconf/db/local.d/locks/*

If properly configured, the output should return:
/org/gnome/desktop/session/idle-delay
      Is it the case that idle-delay is not locked?
 SRG-OS-000029-GPOS-00010, SRG-OS-000031-GPOS-00012 CM-6(a)
xccdf_org.ssgproject.content_rule_dir_group_ownership_library_dirs medium Verify that Shared Library Directories Have Root Group Ownership Files from shared library directories are loaded into the address space of processes (including privileged ones) or of the kernel itself at runtime. Proper ownership of library directories is necessary to protect the integrity of the system. System-wide shared library files, which are linked to executables during process load time or run time, are stored in the following directories by default: 
/lib
/lib64
/usr/lib
/usr/lib64
Kernel modules, which can be added to the kernel during runtime, are also stored in /lib/modules. All files in these directories should be group-owned by the root user. If the directories, is found to be owned by a user other than root correct its ownership with the following command: 
$ sudo chgrp root DIR
 
Verify the system-wide shared library directories are group-owned by "root" with the following command:

$ sudo find /lib /lib64 /usr/lib /usr/lib64 ! -group root -type d -exec stat -c "%n %G" '{}' \;

If any system-wide shared library directory is returned and is not group-owned by a required system account, this is a finding.
      Is it the case that any system-wide shared library directory is returned and is not group-owned by a required system account?
 SRG-OS-000259-GPOS-00100 CM-5(6), CM-5(6).1
xccdf_org.ssgproject.content_rule_dir_ownership_library_dirs medium Verify that Shared Library Directories Have Root Ownership Files from shared library directories are loaded into the address space of processes (including privileged ones) or of the kernel itself at runtime. Proper ownership of library directories is necessary to protect the integrity of the system. System-wide shared library files, which are linked to executables during process load time or run time, are stored in the following directories by default: 
/lib
/lib64
/usr/lib
/usr/lib64
Kernel modules, which can be added to the kernel during runtime, are also stored in /lib/modules. All files in these directories should be owned by the root user. If the directories, is found to be owned by a user other than root correct its ownership with the following command: 
$ sudo chown root DIR
 
Verify the system-wide shared library directories are owned by "root" with the following command:

$ sudo find /lib /lib64 /usr/lib /usr/lib64 ! -user root -type d -exec stat -c "%n %U" '{}' \;
      Is it the case that any system-wide shared library directory is not owned by root?
 SRG-OS-000259-GPOS-00100 CM-5(6), CM-5(6).1
xccdf_org.ssgproject.content_rule_dir_permissions_library_dirs medium Verify that Shared Library Directories Have Restrictive Permissions If the operating system were to allow any user to make changes to software libraries, then those changes might be implemented without undergoing the appropriate testing and approvals that are part of a robust change management process. This requirement applies to operating systems with software libraries that are accessible and configurable, as in the case of interpreted languages. Software libraries also include privileged programs which execute with escalated privileges. Only qualified and authorized individuals must be allowed to obtain access to information system components for purposes of initiating changes, including upgrades and modifications. System-wide shared library directories, which contain are linked to executables during process load time or run time, are stored in the following directories by default: 
/lib
/lib64
/usr/lib
/usr/lib64
Kernel modules, which can be added to the kernel during runtime, are stored in /lib/modules. All sub-directories in these directories should not be group-writable or world-writable. If any file in these directories is found to be group-writable or world-writable, correct its permission with the following command: 
$ sudo chmod go-w DIR
 
Shared libraries are stored in the following directories:

/lib
/lib64
/usr/lib
/usr/lib64


To find shared libraries that are group-writable or world-writable,
run the following command for each directory DIR which contains shared libraries:

$ sudo find -L DIR -perm /022 -type d

      Is it the case that any of these files are group-writable or world-writable?
 SRG-OS-000259-GPOS-00100 CM-5, CM-5(6), CM-5(6).1
xccdf_org.ssgproject.content_rule_dir_perms_world_writable_root_owned medium Ensure All World-Writable Directories Are Owned by root User Allowing a user account to own a world-writable directory is undesirable because it allows the owner of that directory to remove or replace any files that may be placed in the directory by other users. All directories in local partitions which are world-writable should be owned by root. If any world-writable directories are not owned by root, this should be investigated. Following this, the files should be deleted or assigned to root user. 
The following command will discover and print world-writable directories that
are not owned by root. Run it once for each local partition PART:

$ sudo find PART -xdev -type d -perm -0002 -uid +0 -print

      Is it the case that there are world-writable directories not owned by root?
 SRG-OS-000480-GPOS-00227, SRG-OS-000138-GPOS-00069
xccdf_org.ssgproject.content_rule_dir_perms_world_writable_sticky_bits medium Verify that All World-Writable Directories Have Sticky Bits Set Failing to set the sticky bit on public directories allows unauthorized users to delete files in the directory structure.

The only authorized public directories are those temporary directories supplied with the system, or those designed to be temporary file repositories. The setting is normally reserved for directories used by the system, by users for temporary file storage (such as /tmp), and for directories requiring global read/write access.		 When the so-called 'sticky bit' is set on a directory, only the owner of a given file may remove that file from the directory. Without the sticky bit, any user with write access to a directory may remove any file in the directory. Setting the sticky bit prevents users from removing each other's files. In cases where there is no reason for a directory to be world-writable, a better solution is to remove that permission rather than to set the sticky bit. However, if a directory is used by a particular application, consult that application's documentation instead of blindly changing modes.
To set the sticky bit on a world-writable directory DIR, run the following command: 
$ sudo chmod +t DIR
 
To find world-writable directories that lack the sticky bit, run the following command:

$ sudo find / -type d \( -perm -0002 -a ! -perm -1000 \) -print 2>/dev/null

fixtext: |-
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:

$ chmod a+t [World-Writable Directory]
srg_requirement:
A sticky bit must be set on all Oracle Linux 9 public directories to prevent unauthorized and unintended information transferred via shared system resources.
      Is it the case that any world-writable directories are missing the sticky bit?
 SRG-OS-000138-GPOS-00069 CM-6(a), AC-6(1)
xccdf_org.ssgproject.content_rule_directory_group_ownership_var_log_audit medium System Audit Directories Must Be Group Owned By Root Unauthorized disclosure of audit records can reveal system and configuration data to attackers, thus compromising its confidentiality. All audit directories must be group owned by root user. By default, the path for audit log is 
/var/log/audit/
. To properly set the group owner of /var/log/audit, run the command: 
$ sudo chgrp root /var/log/audit
If log_group in /etc/audit/auditd.conf is set to a group other than the root group account, change the group ownership of the audit directories to this specific group.		 
Determine the audit log group by running the following command:

$ sudo grep -P '^[ ]*log_group[ ]+=.*$' /etc/audit/auditd.conf

Then, check that all directories within the /var/log/audit directory are owned by the group specified as log_group or by root if the log_group is not specified.
Run the following command:

$ sudo find /var/log/audit -type d -printf "%p %g\n"

All listed directories must be owned by the log_group or by root if the log_group is not specified.
      Is it the case that there is a directory owned by different group?
 SRG-OS-000057-GPOS-00027, SRG-OS-000058-GPOS-00028, SRG-OS-000059-GPOS-00029, SRG-OS-000206-GPOS-00084 CM-6(a), AC-6(1), AU-9(4)
xccdf_org.ssgproject.content_rule_directory_ownership_var_log_audit medium System Audit Directories Must Be Owned By Root Unauthorized disclosure of audit records can reveal system and configuration data to attackers, thus compromising its confidentiality. All audit directories must be owned by root user. By default, the path for audit log is 
/var/log/audit/
. To properly set the owner of /var/log/audit, run the command: 
$ sudo chown root /var/log/audit 
Determine where the audit logs are stored with the following command:

$ sudo grep -iw log_file /etc/audit/auditd.conf

log_file = /var/log/audit/audit.log

Determine the owner of the audit log directory by using the output of the above command
(default: "/var/log/audit/"). Run the following command with the correct audit log directory
path:

$ sudo ls -ld /var/log/audit

drwx------ 2 root root 23 Jun 11 11:56 /var/log/audit

The audit log directory must be owned by "root"
      Is it the case that the directory is not owned by root?
 SRG-OS-000057-GPOS-00027, SRG-OS-000058-GPOS-00028, SRG-OS-000059-GPOS-00029, SRG-OS-000206-GPOS-00084 CM-6(a), AC-6(1), AU-9(4)
xccdf_org.ssgproject.content_rule_disable_ctrlaltdel_burstaction high Disable Ctrl-Alt-Del Burst Action A locally logged-in user who presses Ctrl-Alt-Del, when at the console, can reboot the system. If accidentally pressed, as could happen in the case of mixed OS environment, this can create the risk of short-term loss of availability of systems due to unintentional reboot. By default, SystemD will reboot the system if the Ctrl-Alt-Del key sequence is pressed Ctrl-Alt-Delete more than 7 times in 2 seconds.

To configure the system to ignore the CtrlAltDelBurstAction setting, add or modify the following to /etc/systemd/system.conf: 
CtrlAltDelBurstAction=none
 
To ensure the system is configured to ignore the Ctrl-Alt-Del setting,
enter the following command:

$ sudo grep -i ctrlaltdelburstaction /etc/systemd/system.conf

The output should return:

CtrlAltDelBurstAction=none

      Is it the case that the system is configured to reboot when Ctrl-Alt-Del is pressed more than 7 times in 2 seconds.?
 SRG-OS-000324-GPOS-00125, SRG-OS-000480-GPOS-00227 CM-6(a), AC-6(1), CM-6(a)
xccdf_org.ssgproject.content_rule_disable_ctrlaltdel_reboot high Disable Ctrl-Alt-Del Reboot Activation A locally logged-in user who presses Ctrl-Alt-Del, when at the console, can reboot the system. If accidentally pressed, as could happen in the case of mixed OS environment, this can create the risk of short-term loss of availability of systems due to unintentional reboot. By default, SystemD will reboot the system if the Ctrl-Alt-Del key sequence is pressed.

To configure the system to ignore the Ctrl-Alt-Del key sequence from the command line instead of rebooting the system, do either of the following: 
ln -sf /dev/null /etc/systemd/system/ctrl-alt-del.target
or 
systemctl mask ctrl-alt-del.target


Do not simply delete the /usr/lib/systemd/system/ctrl-alt-del.service file, as this file may be restored during future system updates.		 
To ensure the system is configured to mask the Ctrl-Alt-Del sequence, Check
that the ctrl-alt-del.target is masked and not active with the following
command:

sudo systemctl status ctrl-alt-del.target

The output should indicate that the target is masked and not active. It
might resemble following output:

ctrl-alt-del.target
Loaded: masked (/dev/null; bad)
Active: inactive (dead)

      Is it the case that the system is configured to reboot when Ctrl-Alt-Del is pressed?
 SRG-OS-000324-GPOS-00125, SRG-OS-000480-GPOS-00227 CM-6(a), AC-6(1)
xccdf_org.ssgproject.content_rule_disable_host_auth medium Disable Host-Based Authentication SSH trust relationships mean a compromise on one host can allow an attacker to move trivially to other hosts. SSH's cryptographic host-based authentication is more secure than .rhosts authentication. However, it is not recommended that hosts unilaterally trust one another, even within an organization.
The default SSH configuration disables host-based authentication. The appropriate configuration is used if no value is set for HostbasedAuthentication.
To explicitly disable host-based authentication, add or correct the following line in /etc/ssh/sshd_config.d/00-complianceascode-hardening.conf: 
HostbasedAuthentication no
 
To determine how the SSH daemon's HostbasedAuthentication option is set, run the following command:


$ sudo grep -i HostbasedAuthentication /etc/ssh/sshd_config.d/00-complianceascode-hardening.conf


$ sudo grep -i HostbasedAuthentication /etc/ssh/sshd_config.d/01-complianceascode-reinforce-os-defaults.conf


If a line indicating no is returned, then the required value is set.

      Is it the case that the required value is not set?
 SRG-OS-000480-GPOS-00229 AC-3, AC-17(a), CM-7(a), CM-7(b), CM-6(a)
xccdf_org.ssgproject.content_rule_disable_users_coredumps medium Disable Core Dumps for All Users A core dump includes a memory image taken at the time the operating system terminates an application. The memory image could contain sensitive data and is generally useful only for developers trying to debug problems. To disable core dumps for all users, add the following line to /etc/security/limits.conf, or to a file within the /etc/security/limits.d/ directory: 
*     hard   core    0
 
Verify that core dumps are disabled for all users, run the following command:

$ grep core /etc/security/limits.conf


*     hard   core    0

      Is it the case that the "core" item is missing, 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"?
 SRG-OS-000480-GPOS-00227 CM-6, SC-7(10)
xccdf_org.ssgproject.content_rule_disallow_bypass_password_sudo medium Disallow Configuration to Bypass Password Requirements for Privilege Escalation Without re-authentication, users may access resources or perform tasks for which they do not have authorization. When operating systems provide the capability to escalate a functional capability, it is critical the user re-authenticate. Verify the operating system is not configured to bypass password requirements for privilege escalation. Check the configuration of the "/etc/pam.d/sudo" file with the following command: 
$ sudo grep pam_succeed_if /etc/pam.d/sudo
If any occurrences of "pam_succeed_if" is returned from the command, this is a finding.		 
Verify the operating system is not configured to bypass password requirements for privilege
escalation. Check the configuration of the "/etc/pam.d/sudo" file with the following command:

$ sudo grep pam_succeed_if /etc/pam.d/sudo

      Is it the case that system is configured to bypass password requirements for privilege escalation?
 SRG-OS-000373-GPOS-00156, SRG-OS-000373-GPOS-00157, SRG-OS-000373-GPOS-00158 IA-11
xccdf_org.ssgproject.content_rule_enable_authselect medium Enable authselect Authselect is a successor to authconfig. It is a tool to select system authentication and identity sources from a list of supported profiles instead of letting the administrator manually build the PAM stack. That way, it avoids potential breakage of configuration, as it ships several tested profiles that are well tested and supported to solve different use-cases. Configure user authentication setup to use the authselect tool. If authselect profile is selected, the rule will enable the sssd profile. 
Verify that authselect is enabled by running

authselect current

If authselect is enabled on the system, the output should show the ID of the profile which is currently in use.
      Is it the case that authselect is not used to manage user authentication setup on the system?
 SRG-OS-000480-GPOS-00227 AC-3
xccdf_org.ssgproject.content_rule_enable_dracut_fips_module high Enable Dracut FIPS Module Use of weak or untested encryption algorithms undermines the purposes of utilizing encryption to protect data. The operating system must implement cryptographic modules adhering to the higher standards approved by the federal government since this provides assurance they have been tested and validated. To enable FIPS mode, run the following command: 
fips-mode-setup --enable
To enable FIPS, the system requires that the fips module is added in dracut configuration. Check if /etc/dracut.conf.d/40-fips.conf contain add_dracutmodules+=" fips "		 
To verify that the Dracut FIPS module is enabled, run the following command:
grep "add_dracutmodules" /etc/dracut.conf.d/40-fips.conf
The output should look like this:
add_dracutmodules+=" fips "
      Is it the case that the Dracut FIPS module is not enabled?
 SRG-OS-000478-GPOS-00223 SC-12(2), SC-12(3), IA-7, SC-13, CM-6(a), SC-12
xccdf_org.ssgproject.content_rule_enable_fips_mode high Enable FIPS Mode Use of weak or untested encryption algorithms undermines the purposes of utilizing encryption to protect data. The operating system must implement cryptographic modules adhering to the higher standards approved by the federal government since this provides assurance they have been tested and validated. To enable FIPS mode, run the following command: 
fips-mode-setup --enable

The fips-mode-setup command will configure the system in FIPS mode by automatically configuring the following:
  • Setting the kernel FIPS mode flag (/proc/sys/crypto/fips_enabled) to 1
  • Creating /etc/system-fips
  • Setting the system crypto policy in /etc/crypto-policies/config to FIPS
  • Loading the Dracut fips module
 
To verify that FIPS mode is enabled properly, run the following command:

cat /proc/sys/crypto/fips_enabled

The output be must:

1

      Is it the case that FIPS mode is not enabled?
 SRG-OS-000478-GPOS-00223, SRG-OS-000396-GPOS-00176 CM-3(6), SC-12(2), SC-12(3), IA-7, SC-13, CM-6(a), SC-12
xccdf_org.ssgproject.content_rule_encrypt_partitions high Encrypt Partitions The risk of a system's physical compromise, particularly mobile systems such as laptops, places its data at risk of compromise. Encrypting this data mitigates the risk of its loss if the system is lost. Oracle Linux 9 natively supports partition encryption through the Linux Unified Key Setup-on-disk-format (LUKS) technology. The easiest way to encrypt a partition is during installation time.

For manual installations, select the Encrypt checkbox during partition creation to encrypt the partition. When this option is selected the system will prompt for a passphrase to use in decrypting the partition. The passphrase will subsequently need to be entered manually every time the system boots.

For automated/unattended installations, it is possible to use Kickstart by adding the --encrypted and --passphrase= options to the definition of each partition to be encrypted. For example, the following line would encrypt the root partition: 
part / --fstype=ext4 --size=100 --onpart=hda1 --encrypted --passphrase=PASSPHRASE
Any PASSPHRASE is stored in the Kickstart in plaintext, and the Kickstart must then be protected accordingly. Omitting the --passphrase= option from the partition definition will cause the installer to pause and interactively ask for the passphrase during installation.

By default, the Anaconda installer uses aes-xts-plain64 cipher with a minimum 512 bit key size which should be compatible with FIPS enabled.

Detailed information on encrypting partitions using LUKS or LUKS ciphers can be found on the Oracle Linux 9 Documentation web site:
https://docs.oracle.com/en/operating-systems/oracle-linux/9/install/install-InstallingOracleLinuxManually.html#system-options .		 
Check the system partitions to determine if they are encrypted with the following command:

blkid




Output will be similar to:

/dev/sda1: UUID=" ab12c3de-4f56-789a-8f33-3850cc8ce3a2
" TYPE="crypto_LUKS"
/dev/sda2: UUID=" bc98d7ef-6g54-321h-1d24-9870de2ge1a2
" TYPE="crypto_LUKS"




The boot partition and pseudo-file systems, such as /proc, /sys, and tmpfs,
are not required to use disk encryption and are not a finding.
      Is it the case that partitions do not have a type of crypto_LUKS?
 SRG-OS-000405-GPOS-00184, SRG-OS-000185-GPOS-00079, SRG-OS-000404-GPOS-00183 CM-6(a), SC-28, SC-28(1), SC-13, AU-9(3)
xccdf_org.ssgproject.content_rule_ensure_epel_repos_disabled medium Ensure EPEL Repository is Disabled The EPEL repository is not officially supported by Red Hat and may contain packages that have not been vetted for security in an enterprise environment. Using unsupported repositories can introduce vulnerabilities, compatibility issues, or packages that do not meet DoD security requirements. Only packages from authorized repositories should be installed to maintain system integrity and security. The system must not have the EPEL (Extra Packages for Enterprise Linux) repository enabled. EPEL provides additional packages that are not part of the official RHEL distribution and may not meet enterprise security requirements. Check if any repository files in /etc/yum.repos.d/ contain enabled EPEL repositories by running: 
$ grep -r "^\[.*epel.*\]" /etc/yum.repos.d/
If EPEL repositories are found, ensure they are disabled by setting enabled=0 in the repository configuration file.		 
To verify that EPEL repository is not enabled, run the following commands:

$ grep -r "^\[.*epel.*\]" /etc/yum.repos.d/

For each EPEL repository found, check if it is enabled:

$ grep -A 5 "^\[.*epel.*\]" /etc/yum.repos.d/*.repo | grep "enabled"

The output should show enabled=0 for all EPEL repositories, or no EPEL repositories
should be present.
      Is it the case that EPEL repository is enabled?
 SRG-OS-000095-GPOS-00049
xccdf_org.ssgproject.content_rule_ensure_gpgcheck_globally_activated high Ensure gpgcheck Enabled In Main yum Configuration Changes to any software components can have significant effects on the overall security of the operating system. This requirement ensures the software has not been tampered with and that it has been provided by a trusted vendor.
Accordingly, patches, service packs, device drivers, or operating system components must be signed with a certificate recognized and approved by the organization.
Verifying the authenticity of the software prior to installation validates the integrity of the patch or upgrade received from a vendor. This ensures the software has not been tampered with and that it has been provided by a trusted vendor. Self-signed certificates are disallowed by this requirement. Certificates used to verify the software must be from an approved Certificate Authority (CA).		 The gpgcheck option controls whether RPM packages' signatures are always checked prior to installation. To configure yum to check package signatures before installing them, ensure the following line appears in /etc/yum.conf in the [main] section: 
gpgcheck=1
 
Verify that yum verifies the signature of packages from a repository prior to install with the following command:


$ grep gpgcheck /etc/yum.conf



gpgcheck=1


If "gpgcheck" is not set to "1", or if the option is missing or commented out, ask the System Administrator how the certificates for patches and other operating system components are verified.
      Is it the case that there is no process to validate certificates that is approved by the organization?
 SRG-OS-000366-GPOS-00153 CM-5(3), SI-7, SC-12, SC-12(3), CM-6(a), SA-12, SA-12(10), CM-11(a), CM-11(b)
xccdf_org.ssgproject.content_rule_ensure_gpgcheck_local_packages high Ensure gpgcheck Enabled for Local Packages Changes to any software components can have significant effects to the overall security of the operating system. This requirement ensures the software has not been tampered and has been provided by a trusted vendor.

Accordingly, patches, service packs, device drivers, or operating system components must be signed with a certificate recognized and approved by the organization.		 yum should be configured to verify the signature(s) of local packages prior to installation. To configure yum to verify signatures of local packages, set the localpkg_gpgcheck to 1 in /etc/yum.conf. 
Verify that yum verifies the signature of local packages prior to install with the following command:


$ grep localpkg_gpgcheck /etc/yum.conf



localpkg_gpgcheck=1


If "localpkg_gpgcheck" is not set to "1", or if the option is missing or commented out, ask the System Administrator how the certificates for patches and other operating system components are verified.
      Is it the case that there is no process to validate certificates for local packages that is approved by the organization?
 SRG-OS-000366-GPOS-00153 CM-11(a), CM-11(b), CM-6(a), CM-5(3), SA-12, SA-12(10)
xccdf_org.ssgproject.content_rule_ensure_gpgcheck_never_disabled high Ensure gpgcheck Enabled for All yum Package Repositories Verifying the authenticity of the software prior to installation validates the integrity of the patch or upgrade received from a vendor. This ensures the software has not been tampered with and that it has been provided by a trusted vendor. Self-signed certificates are disallowed by this requirement. Certificates used to verify the software must be from an approved Certificate Authority (CA)." To ensure signature checking is not disabled for any repos, remove any lines from files in /etc/yum.repos.d of the form: 
gpgcheck=0
 
To determine whether yum has been configured to disable
gpgcheck for any repos,  inspect all files in
/etc/yum.repos.d and ensure the following does not appear in any
sections:

gpgcheck=0

A value of 0 indicates that gpgcheck has been disabled for that repo.
      Is it the case that GPG checking is disabled?
 SRG-OS-000366-GPOS-00153 CM-5(3), SI-7, SC-12, SC-12(3), CM-6(a), SA-12, SA-12(10), CM-11(a), CM-11(b)
xccdf_org.ssgproject.content_rule_ensure_oracle_gpgkey_installed high Ensure Oracle Linux GPG Key Installed Changes to software components can have significant effects on the overall security of the operating system. This requirement ensures the software has not been tampered with and that it has been provided by a trusted vendor. The Oracle GPG key is necessary to cryptographically verify packages are from Oracle. To ensure the system can cryptographically verify base software packages come from Oracle (and to connect to the Unbreakable Linux Network to receive them), the Oracle GPG key must properly be installed. To install the Oracle GPG key, run: 
$ sudo uln_register
If the system is not connected to the Internet, then install the Oracle GPG key from trusted media such as the Oracle installation CD-ROM or DVD. Assuming the disc is mounted in /media/cdrom, use the following command as the root user to import it into the keyring: 
$ sudo rpm --import /media/cdrom/RPM-GPG-KEY-oracle
Alternatively, the key may be pre-loaded during the Oracle installation. In such cases, the key can be installed by running the following command: 
sudo rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-oracle
 
To ensure that the GPG key is installed, run:

$ rpm -q --queryformat "%{SUMMARY}\n" gpg-pubkey

The command should return the string below:

gpg(Oracle OSS group (Open Source Software group) <build@oss.oracle.com>

      Is it the case that the Oracle GPG Key is not installed?
 CM-5(3), SI-7, SC-12, SC-12(3), CM-6(a), CM-11(a), CM-11(b)
xccdf_org.ssgproject.content_rule_file_audit_tools_group_ownership medium Audit Tools Must Be Group-owned by Root Protecting audit information also includes identifying and protecting the tools used to view and manipulate log data. Therefore, protecting audit tools is necessary to prevent unauthorized operations on audit information. Oracle Linux 9 systems providing tools to interface with audit information will leverage user permissions and roles identifying the user accessing the tools, and the corresponding rights the user enjoys, to make access decisions regarding the access to audit tools. Audit tools include, but are not limited to, vendor-provided and open source audit tools needed to successfully view and manipulate audit information system activity and records. Audit tools include custom queries and report generators. Audit tools must have the correct group owner. 
Verify the audit tools are group-owned by "root" to prevent any unauthorized access, deletion, or modification.

Check the group-owner of each audit tool by running the following command:

$ sudo stat -c "%G %n" /sbin/auditctl /sbin/aureport /sbin/ausearch /sbin/autrace /sbin/auditd /sbin/rsyslogd /sbin/augenrules

root /sbin/auditctl
root /sbin/aureport
root /sbin/ausearch
root /sbin/autrace
root /sbin/auditd
root /sbin/rsyslogd
root /sbin/augenrules
      Is it the case that any audit tools are not group-owned by root?
 SRG-OS-000256-GPOS-00097, SRG-OS-000257-GPOS-00098, SRG-OS-000258-GPOS-00099 AU-9
xccdf_org.ssgproject.content_rule_file_audit_tools_ownership medium Audit Tools Must Be Owned by Root Protecting audit information also includes identifying and protecting the tools used to view and manipulate log data. Therefore, protecting audit tools is necessary to prevent unauthorized operations on audit information. Oracle Linux 9 systems providing tools to interface with audit information will leverage user permissions and roles identifying the user accessing the tools, and the corresponding rights the user enjoys, to make access decisions regarding the access to audit tools. Audit tools include, but are not limited to, vendor-provided and open source audit tools needed to successfully view and manipulate audit information system activity and records. Audit tools include custom queries and report generators. Audit tools must have the correct owner. 
Verify the audit tools are owned by "root" to prevent any unauthorized access, deletion, or modification.

Check the owner of each audit tool by running the following command:

$ sudo stat -c "%U %n" /sbin/auditctl /sbin/aureport /sbin/ausearch /sbin/autrace /sbin/auditd /sbin/rsyslogd /sbin/augenrules

root /sbin/auditctl
root /sbin/aureport
root /sbin/ausearch
root /sbin/autrace
root /sbin/auditd
root /sbin/rsyslogd
root /sbin/augenrules
      Is it the case that any audit tools are not owned by root?
 SRG-OS-000256-GPOS-00097, SRG-OS-000257-GPOS-00098, SRG-OS-000258-GPOS-00099 AU-9
xccdf_org.ssgproject.content_rule_file_audit_tools_permissions medium Audit Tools Must Have a Mode of 0755 or Less Permissive Protecting audit information also includes identifying and protecting the tools used to view and manipulate log data. Therefore, protecting audit tools is necessary to prevent unauthorized operations on audit information. Oracle Linux 9 systems providing tools to interface with audit information will leverage user permissions and roles identifying the user accessing the tools, and the corresponding rights the user enjoys, to make access decisions regarding the access to audit tools. Audit tools include, but are not limited to, vendor-provided and open source audit tools needed to successfully view and manipulate audit information system activity and records. Audit tools include custom queries and report generators. Audit tools must have a mode of 0755 or less permissive. 
Verify the audit tools are protected from unauthorized access, deletion, or modification by checking the permissive mode.

Check the octal permission of each audit tool by running the following command:

$ sudo stat -c "%U %n" /sbin/auditctl /sbin/aureport /sbin/ausearch /sbin/autrace /sbin/auditd /sbin/rsyslogd /sbin/augenrules
      Is it the case that any of these files have more permissive permissions than 0755?
 SRG-OS-000256-GPOS-00097, SRG-OS-000257-GPOS-00098, SRG-OS-000258-GPOS-00099 AU-9
xccdf_org.ssgproject.content_rule_file_groupowner_backup_etc_group medium Verify Group Who Owns Backup group File The /etc/group- file is a backup file of /etc/group, and as such, it contains information regarding groups that are configured on the system. Protection of this file is important for system security. To properly set the group owner of /etc/group-, run the command: 
$ sudo chgrp root /etc/group-
 
To check the group ownership of /etc/group-,
run the command:

$ ls -lL /etc/group-

If properly configured, the output should indicate the following group-owner:

  root
  
      Is it the case that /etc/group- does not have a group owner of
root
?
 SRG-OS-000480-GPOS-00227 AC-6 (1)
xccdf_org.ssgproject.content_rule_file_groupowner_backup_etc_gshadow medium Verify Group Who Owns Backup gshadow File The /etc/gshadow- file is a backup of /etc/gshadow, and as such, it contains group password hashes. Protection of this file is critical for system security. To properly set the group owner of /etc/gshadow-, run the command: 
$ sudo chgrp root /etc/gshadow-
 
To check the group ownership of /etc/gshadow-,
run the command:

$ ls -lL /etc/gshadow-

If properly configured, the output should indicate the following group-owner:

  root
  
      Is it the case that /etc/gshadow- does not have a group owner of
root
?
 SRG-OS-000480-GPOS-00227 AC-6 (1)
xccdf_org.ssgproject.content_rule_file_groupowner_backup_etc_passwd medium Verify Group Who Owns Backup passwd File The /etc/passwd- file is a backup file of /etc/passwd, and as such, it contains information about the users that are configured on the system. Protection of this file is critical for system security. To properly set the group owner of /etc/passwd-, run the command: 
$ sudo chgrp root /etc/passwd-
 
To check the group ownership of /etc/passwd-,
run the command:

$ ls -lL /etc/passwd-

If properly configured, the output should indicate the following group-owner:

  root
  
      Is it the case that /etc/passwd- does not have a group owner of
root
?
 SRG-OS-000480-GPOS-00227 AC-6 (1)
xccdf_org.ssgproject.content_rule_file_groupowner_backup_etc_shadow medium Verify User Who Owns Backup shadow File The /etc/shadow- file is a backup file of /etc/shadow, and as such, it contains the list of local system accounts and password hashes. Protection of this file is critical for system security. To properly set the group owner of /etc/shadow-, run the command: 
$ sudo chgrp root /etc/shadow-
 
To check the group ownership of /etc/shadow-,
run the command:

$ ls -lL /etc/shadow-

If properly configured, the output should indicate the following group-owner:

  root
  
      Is it the case that /etc/shadow- does not have a group owner of
root
?
 SRG-OS-000480-GPOS-00227
xccdf_org.ssgproject.content_rule_file_groupowner_cron_d medium Verify Group Who Owns cron.d Service configuration files enable or disable features of their respective services that if configured incorrectly can lead to insecure and vulnerable configurations. Therefore, service configuration files should be owned by the correct group to prevent unauthorized changes. To properly set the group owner of /etc/cron.d, run the command: 
$ sudo chgrp root /etc/cron.d
 
To check the group ownership of /etc/cron.d,
run the command:

$ ls -lL /etc/cron.d

If properly configured, the output should indicate the following group-owner:

  root
  
      Is it the case that /etc/cron.d does not have a group owner of
root
?
 SRG-OS-000480-GPOS-00227 CM-6(a), AC-6(1)
xccdf_org.ssgproject.content_rule_file_groupowner_cron_daily medium Verify Group Who Owns cron.daily Service configuration files enable or disable features of their respective services that if configured incorrectly can lead to insecure and vulnerable configurations. Therefore, service configuration files should be owned by the correct group to prevent unauthorized changes. To properly set the group owner of /etc/cron.daily, run the command: 
$ sudo chgrp root /etc/cron.daily
 
To check the group ownership of /etc/cron.daily,
run the command:

$ ls -lL /etc/cron.daily

If properly configured, the output should indicate the following group-owner:

  root
  
      Is it the case that /etc/cron.daily does not have a group owner of
root
?
 SRG-OS-000480-GPOS-00227 CM-6(a), AC-6(1)
xccdf_org.ssgproject.content_rule_file_groupowner_cron_deny medium Verify Group Who Owns cron.deny Service configuration files enable or disable features of their respective services that if configured incorrectly can lead to insecure and vulnerable configurations. Therefore, service configuration files should be owned by the correct group to prevent unauthorized changes. To properly set the group owner of /etc/cron.deny, run the command: 
$ sudo chgrp root /etc/cron.deny
 
To check the group ownership of /etc/cron.deny,
run the command:

$ ls -lL /etc/cron.deny

If properly configured, the output should indicate the following group-owner:

  root
  
      Is it the case that /etc/cron.deny does not have a group owner of
root
?
 SRG-OS-000480-GPOS-00227 CM-6 b
xccdf_org.ssgproject.content_rule_file_groupowner_cron_hourly medium Verify Group Who Owns cron.hourly Service configuration files enable or disable features of their respective services that if configured incorrectly can lead to insecure and vulnerable configurations. Therefore, service configuration files should be owned by the correct group to prevent unauthorized changes. To properly set the group owner of /etc/cron.hourly, run the command: 
$ sudo chgrp root /etc/cron.hourly
 
To check the group ownership of /etc/cron.hourly,
run the command:

$ ls -lL /etc/cron.hourly

If properly configured, the output should indicate the following group-owner:

  root
  
      Is it the case that /etc/cron.hourly does not have a group owner of
root
?
 SRG-OS-000480-GPOS-00227 CM-6(a), AC-6(1)
xccdf_org.ssgproject.content_rule_file_groupowner_cron_monthly medium Verify Group Who Owns cron.monthly Service configuration files enable or disable features of their respective services that if configured incorrectly can lead to insecure and vulnerable configurations. Therefore, service configuration files should be owned by the correct group to prevent unauthorized changes. To properly set the group owner of /etc/cron.monthly, run the command: 
$ sudo chgrp root /etc/cron.monthly
 
To check the group ownership of /etc/cron.monthly,
run the command:

$ ls -lL /etc/cron.monthly

If properly configured, the output should indicate the following group-owner:

  root
  
      Is it the case that /etc/cron.monthly does not have a group owner of
root
?
 SRG-OS-000480-GPOS-00227 CM-6(a), AC-6(1)
xccdf_org.ssgproject.content_rule_file_groupowner_cron_weekly medium Verify Group Who Owns cron.weekly Service configuration files enable or disable features of their respective services that if configured incorrectly can lead to insecure and vulnerable configurations. Therefore, service configuration files should be owned by the correct group to prevent unauthorized changes. To properly set the group owner of /etc/cron.weekly, run the command: 
$ sudo chgrp root /etc/cron.weekly
 
To check the group ownership of /etc/cron.weekly,
run the command:

$ ls -lL /etc/cron.weekly

If properly configured, the output should indicate the following group-owner:

  root
  
      Is it the case that /etc/cron.weekly does not have a group owner of
root
?
 SRG-OS-000480-GPOS-00227 CM-6(a), AC-6(1)
xccdf_org.ssgproject.content_rule_file_groupowner_crontab medium Verify Group Who Owns Crontab Service configuration files enable or disable features of their respective services that if configured incorrectly can lead to insecure and vulnerable configurations. Therefore, service configuration files should be owned by the correct group to prevent unauthorized changes. To properly set the group owner of /etc/crontab, run the command: 
$ sudo chgrp root /etc/crontab
 
To check the group ownership of /etc/crontab,
run the command:

$ ls -lL /etc/crontab

If properly configured, the output should indicate the following group-owner:

  root
  
      Is it the case that /etc/crontab does not have a group owner of
root
?
 SRG-OS-000480-GPOS-00227 CM-6(a), AC-6(1)
xccdf_org.ssgproject.content_rule_file_groupowner_etc_group medium Verify Group Who Owns group File The /etc/group file contains information regarding groups that are configured on the system. Protection of this file is important for system security. To properly set the group owner of /etc/group, run the command: 
$ sudo chgrp root /etc/group
 
To check the group ownership of /etc/group,
run the command:

$ ls -lL /etc/group

If properly configured, the output should indicate the following group-owner:

  root
  
      Is it the case that /etc/group does not have a group owner of
root
?
 SRG-OS-000480-GPOS-00227 CM-6(a), AC-6(1)
xccdf_org.ssgproject.content_rule_file_groupowner_etc_gshadow medium Verify Group Who Owns gshadow File The /etc/gshadow file contains group password hashes. Protection of this file is critical for system security. To properly set the group owner of /etc/gshadow, run the command: 
$ sudo chgrp root /etc/gshadow
 
To check the group ownership of /etc/gshadow,
run the command:

$ ls -lL /etc/gshadow

If properly configured, the output should indicate the following group-owner:

  root
  
      Is it the case that /etc/gshadow does not have a group owner of
root
?
 SRG-OS-000480-GPOS-00227 CM-6(a), AC-6(1)
xccdf_org.ssgproject.content_rule_file_groupowner_etc_passwd medium Verify Group Who Owns passwd File The /etc/passwd file contains information about the users that are configured on the system. Protection of this file is critical for system security. To properly set the group owner of /etc/passwd, run the command: 
$ sudo chgrp root /etc/passwd
 
To check the group ownership of /etc/passwd,
run the command:

$ ls -lL /etc/passwd

If properly configured, the output should indicate the following group-owner:

  root
  
      Is it the case that /etc/passwd does not have a group owner of
root
?
 SRG-OS-000480-GPOS-00227 CM-6(a), AC-6(1)
xccdf_org.ssgproject.content_rule_file_groupowner_etc_shadow medium Verify Group Who Owns shadow File The /etc/shadow file stores password hashes. Protection of this file is critical for system security. To properly set the group owner of /etc/shadow, run the command: 
$ sudo chgrp root /etc/shadow
 
To check the group ownership of /etc/shadow,
run the command:

$ ls -lL /etc/shadow

If properly configured, the output should indicate the following group-owner:

  root
  
      Is it the case that /etc/shadow does not have a group owner of
root
?
 SRG-OS-000480-GPOS-00227 CM-6(a), AC-6(1)
xccdf_org.ssgproject.content_rule_file_groupowner_grub2_cfg medium Verify /boot/grub2/grub.cfg Group Ownership The root group is a highly-privileged group. Furthermore, the group-owner of this file should not have any access privileges anyway. The file /boot/grub2/grub.cfg should be group-owned by the root group to prevent destruction or modification of the file. To properly set the group owner of /boot/grub2/grub.cfg, run the command: 
$ sudo chgrp root /boot/grub2/grub.cfg
 
To check the group ownership of /boot/grub2/grub.cfg,
run the command:

$ ls -lL /boot/grub2/grub.cfg

If properly configured, the output should indicate the following group-owner:

  root
  
      Is it the case that /boot/grub2/grub.cfg does not have a group owner of
root
?
 SRG-OS-000480-GPOS-00227 CM-6(a), AC-6(1)
xccdf_org.ssgproject.content_rule_file_groupowner_sshd_config medium Verify Group Who Owns SSH Server config file Service configuration files enable or disable features of their respective services that if configured incorrectly can lead to insecure and vulnerable configurations. Therefore, service configuration files should be owned by the correct group to prevent unauthorized changes. To properly set the group owner of /etc/ssh/sshd_config, run the command: 
$ sudo chgrp root /etc/ssh/sshd_config
 
To check the group ownership of /etc/ssh/sshd_config,
run the command:

$ ls -lL /etc/ssh/sshd_config

If properly configured, the output should indicate the following group-owner:

  root
  
      Is it the case that /etc/ssh/sshd_config does not have a group owner of
root
?
 SRG-OS-000480-GPOS-00227 AC-17(a), CM-6(a), AC-6(1)
xccdf_org.ssgproject.content_rule_file_groupowner_var_log medium Verify Group Who Owns /var/log Directory The /var/log directory contains files with logs of error messages in the system and should only be accessed by authorized personnel. To properly set the group owner of /var/log, run the command: 
$ sudo chgrp root /var/log
 
To check the group ownership of /var/log,
run the command:

$ ls -lL /var/log

If properly configured, the output should indicate the following group-owner:

  root
  
      Is it the case that /var/log does not have a group owner of
root
?
 SRG-OS-000206-GPOS-00084, SRG-APP-000118-CTR-000240
xccdf_org.ssgproject.content_rule_file_groupowner_var_log_messages medium Verify Group Who Owns /var/log/messages File The /var/log/messages file contains logs of error messages in the system and should only be accessed by authorized personnel. To properly set the group owner of /var/log/messages, run the command: 
$ sudo chgrp root /var/log/messages
 
To check the group ownership of /var/log/messages,
run the command:

$ ls -lL /var/log/messages

If properly configured, the output should indicate the following group-owner:

  root
  
      Is it the case that /var/log/messages does not have a group owner of
root
?
 SRG-OS-000206-GPOS-00084
xccdf_org.ssgproject.content_rule_file_groupownership_home_directories medium All Interactive User Home Directories Must Be Group-Owned By The Primary Group If the Group Identifier (GID) of a local interactive users home directory is not the same as the primary GID of the user, this would allow unauthorized access to the users files, and users that share the same group may not be able to access files that they legitimately should. Change the group owner of interactive users home directory to the group found in /etc/passwd. To change the group owner of interactive users home directory, use the following command: 
$ sudo chgrp USER_GROUP /home/USER
This rule ensures every home directory related to an interactive user is group-owned by an interactive user. It also ensures that interactive users are group-owners of one and only one home directory.		 
To verify the assigned home directory of all interactive users is group-
owned by that users primary GID, run the following command:

# ls -ld $(awk -F: '($3>=1000)&&($7 !~ /nologin/){print $6}' /etc/passwd)

      Is it the case that the group ownership is incorrect?
 SRG-OS-000480-GPOS-00227
xccdf_org.ssgproject.content_rule_file_groupownership_system_commands_dirs medium Verify that system commands files are group owned by root or a system account If the operating system allows any user to make changes to software libraries, then those changes might be implemented without undergoing the appropriate testing and approvals that are part of a robust change management process. This requirement applies to operating systems with software libraries that are accessible and configurable, as in the case of interpreted languages. Software libraries also include privileged programs which execute with escalated privileges. Only qualified and authorized individuals must be allowed to obtain access to information system components for purposes of initiating changes, including upgrades and modifications. System commands files are stored in the following directories by default: 
/bin
/sbin
/usr/bin
/usr/sbin
/usr/local/bin
/usr/local/sbin
All files in these directories should be owned by the root group, or a system account. If the directory, or any file in these directories, is found to be owned by a group other than root or a a system account correct its ownership with the following command: 
$ sudo chgrp root FILE
 
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 {} \;
      Is it the case that any system commands are returned and is not group-owned by a required system account?
 SRG-OS-000259-GPOS-00100 CM-5(6), CM-5(6).1
xccdf_org.ssgproject.content_rule_file_owner_backup_etc_group medium Verify User Who Owns Backup group File The /etc/group- file is a backup file of /etc/group, and as such, it contains information regarding groups that are configured on the system. Protection of this file is important for system security. To properly set the owner of /etc/group-, run the command: 
$ sudo chown root /etc/group- 
To check the ownership of /etc/group-,
run the command:

$ ls -lL /etc/group-

If properly configured, the output should indicate the following owner:
root
      Is it the case that /etc/group- does not have an owner of root?
 SRG-OS-000480-GPOS-00227 AC-6 (1)
xccdf_org.ssgproject.content_rule_file_owner_backup_etc_gshadow medium Verify User Who Owns Backup gshadow File The /etc/gshadow- file is a backup of /etc/gshadow, and as such, it contains group password hashes. Protection of this file is critical for system security. To properly set the owner of /etc/gshadow-, run the command: 
$ sudo chown root /etc/gshadow- 
To check the ownership of /etc/gshadow-,
run the command:

$ ls -lL /etc/gshadow-

If properly configured, the output should indicate the following owner:
root
      Is it the case that /etc/gshadow- does not have an owner of root?
 SRG-OS-000480-GPOS-00227 AC-6 (1)
xccdf_org.ssgproject.content_rule_file_owner_backup_etc_passwd medium Verify User Who Owns Backup passwd File The /etc/passwd- file is a backup file of /etc/passwd, and as such, it contains information about the users that are configured on the system. Protection of this file is critical for system security. To properly set the owner of /etc/passwd-, run the command: 
$ sudo chown root /etc/passwd- 
To check the ownership of /etc/passwd-,
run the command:

$ ls -lL /etc/passwd-

If properly configured, the output should indicate the following owner:
root
      Is it the case that /etc/passwd- does not have an owner of root?
 SRG-OS-000480-GPOS-00227 AC-6 (1)
xccdf_org.ssgproject.content_rule_file_owner_backup_etc_shadow medium Verify Group Who Owns Backup shadow File The /etc/shadow- file is a backup file of /etc/shadow, and as such, it contains the list of local system accounts and password hashes. Protection of this file is critical for system security. To properly set the owner of /etc/shadow-, run the command: 
$ sudo chown root /etc/shadow- 
To check the ownership of /etc/shadow-,
run the command:

$ ls -lL /etc/shadow-

If properly configured, the output should indicate the following owner:
root
      Is it the case that /etc/shadow- does not have an owner of root?
 SRG-OS-000480-GPOS-00227 AC-6 (1)
xccdf_org.ssgproject.content_rule_file_owner_cron_d medium Verify Owner on cron.d Service configuration files enable or disable features of their respective services that if configured incorrectly can lead to insecure and vulnerable configurations. Therefore, service configuration files should be owned by the correct user to prevent unauthorized changes. To properly set the owner of /etc/cron.d, run the command: 
$ sudo chown root /etc/cron.d 
To check the ownership of /etc/cron.d,
run the command:

$ ls -lL /etc/cron.d

If properly configured, the output should indicate the following owner:
root
      Is it the case that /etc/cron.d does not have an owner of root?
 SRG-OS-000480-GPOS-00227 CM-6(a), AC-6(1)
xccdf_org.ssgproject.content_rule_file_owner_cron_daily medium Verify Owner on cron.daily Service configuration files enable or disable features of their respective services that if configured incorrectly can lead to insecure and vulnerable configurations. Therefore, service configuration files should be owned by the correct user to prevent unauthorized changes. To properly set the owner of /etc/cron.daily, run the command: 
$ sudo chown root /etc/cron.daily 
To check the ownership of /etc/cron.daily,
run the command:

$ ls -lL /etc/cron.daily

If properly configured, the output should indicate the following owner:
root
      Is it the case that /etc/cron.daily does not have an owner of root?
 SRG-OS-000480-GPOS-00227 CM-6(a), AC-6(1)
xccdf_org.ssgproject.content_rule_file_owner_cron_deny medium Verify Owner on cron.deny Service configuration files enable or disable features of their respective services that if configured incorrectly can lead to insecure and vulnerable configurations. Therefore, service configuration files should be owned by the correct user to prevent unauthorized changes. To properly set the owner of /etc/cron.deny, run the command: 
$ sudo chown root /etc/cron.deny 
To check the ownership of /etc/cron.deny,
run the command:

$ ls -lL /etc/cron.deny

If properly configured, the output should indicate the following owner:
root
      Is it the case that /etc/cron.deny does not have an owner of root?
 SRG-OS-000480-GPOS-00227 CM-6 b
xccdf_org.ssgproject.content_rule_file_owner_cron_hourly medium Verify Owner on cron.hourly Service configuration files enable or disable features of their respective services that if configured incorrectly can lead to insecure and vulnerable configurations. Therefore, service configuration files should be owned by the correct user to prevent unauthorized changes. To properly set the owner of /etc/cron.hourly, run the command: 
$ sudo chown root /etc/cron.hourly 
To check the ownership of /etc/cron.hourly,
run the command:

$ ls -lL /etc/cron.hourly

If properly configured, the output should indicate the following owner:
root
      Is it the case that /etc/cron.hourly does not have an owner of root?
 SRG-OS-000480-GPOS-00227 CM-6(a), AC-6(1)
xccdf_org.ssgproject.content_rule_file_owner_cron_monthly medium Verify Owner on cron.monthly Service configuration files enable or disable features of their respective services that if configured incorrectly can lead to insecure and vulnerable configurations. Therefore, service configuration files should be owned by the correct user to prevent unauthorized changes. To properly set the owner of /etc/cron.monthly, run the command: 
$ sudo chown root /etc/cron.monthly 
To check the ownership of /etc/cron.monthly,
run the command:

$ ls -lL /etc/cron.monthly

If properly configured, the output should indicate the following owner:
root
      Is it the case that /etc/cron.monthly does not have an owner of root?
 SRG-OS-000480-GPOS-00227 CM-6(a), AC-6(1)
xccdf_org.ssgproject.content_rule_file_owner_cron_weekly medium Verify Owner on cron.weekly Service configuration files enable or disable features of their respective services that if configured incorrectly can lead to insecure and vulnerable configurations. Therefore, service configuration files should be owned by the correct user to prevent unauthorized changes. To properly set the owner of /etc/cron.weekly, run the command: 
$ sudo chown root /etc/cron.weekly 
To check the ownership of /etc/cron.weekly,
run the command:

$ ls -lL /etc/cron.weekly

If properly configured, the output should indicate the following owner:
root
      Is it the case that /etc/cron.weekly does not have an owner of root?
 SRG-OS-000480-GPOS-00227 CM-6(a), AC-6(1)
xccdf_org.ssgproject.content_rule_file_owner_crontab medium Verify Owner on crontab Service configuration files enable or disable features of their respective services that if configured incorrectly can lead to insecure and vulnerable configurations. Therefore, service configuration files should be owned by the correct user to prevent unauthorized changes. To properly set the owner of /etc/crontab, run the command: 
$ sudo chown root /etc/crontab 
To check the ownership of /etc/crontab,
run the command:

$ ls -lL /etc/crontab

If properly configured, the output should indicate the following owner:
root
      Is it the case that /etc/crontab does not have an owner of root?
 SRG-OS-000480-GPOS-00227 CM-6(a), AC-6(1)
xccdf_org.ssgproject.content_rule_file_owner_etc_group medium Verify User Who Owns group File The /etc/group file contains information regarding groups that are configured on the system. Protection of this file is important for system security. To properly set the owner of /etc/group, run the command: 
$ sudo chown root /etc/group 
To check the ownership of /etc/group,
run the command:

$ ls -lL /etc/group

If properly configured, the output should indicate the following owner:
root
      Is it the case that /etc/group does not have an owner of root?
 SRG-OS-000480-GPOS-00227 CM-6(a), AC-6(1)
xccdf_org.ssgproject.content_rule_file_owner_etc_gshadow medium Verify User Who Owns gshadow File The /etc/gshadow file contains group password hashes. Protection of this file is critical for system security. To properly set the owner of /etc/gshadow, run the command: 
$ sudo chown root /etc/gshadow 
To check the ownership of /etc/gshadow,
run the command:

$ ls -lL /etc/gshadow

If properly configured, the output should indicate the following owner:
root
      Is it the case that /etc/gshadow does not have an owner of root?
 SRG-OS-000480-GPOS-00227 CM-6(a), AC-6(1)
xccdf_org.ssgproject.content_rule_file_owner_etc_passwd medium Verify User Who Owns passwd File The /etc/passwd file contains information about the users that are configured on the system. Protection of this file is critical for system security. To properly set the owner of /etc/passwd, run the command: 
$ sudo chown root /etc/passwd 
To check the ownership of /etc/passwd,
run the command:

$ ls -lL /etc/passwd

If properly configured, the output should indicate the following owner:
root
      Is it the case that /etc/passwd does not have an owner of root?
 SRG-OS-000480-GPOS-00227 CM-6(a), AC-6(1)
xccdf_org.ssgproject.content_rule_file_owner_etc_shadow medium Verify User Who Owns shadow File The /etc/shadow file contains the list of local system accounts and stores password hashes. Protection of this file is critical for system security. Failure to give ownership of this file to root provides the designated owner with access to sensitive information which could weaken the system security posture. To properly set the owner of /etc/shadow, run the command: 
$ sudo chown root /etc/shadow 
To check the ownership of /etc/shadow,
run the command:

$ ls -lL /etc/shadow

If properly configured, the output should indicate the following owner:
root
      Is it the case that /etc/shadow does not have an owner of root?
 SRG-OS-000480-GPOS-00227 CM-6(a), AC-6(1)
xccdf_org.ssgproject.content_rule_file_owner_grub2_cfg medium Verify /boot/grub2/grub.cfg User Ownership Only root should be able to modify important boot parameters. The file /boot/grub2/grub.cfg should be owned by the root user to prevent destruction or modification of the file. To properly set the owner of /boot/grub2/grub.cfg, run the command: 
$ sudo chown root /boot/grub2/grub.cfg 
To check the ownership of /boot/grub2/grub.cfg,
run the command:

$ ls -lL /boot/grub2/grub.cfg

If properly configured, the output should indicate the following owner:
root
      Is it the case that /boot/grub2/grub.cfg does not have an owner of root?
 SRG-OS-000480-GPOS-00227 CM-6(a), AC-6(1)
xccdf_org.ssgproject.content_rule_file_owner_sshd_config medium Verify Owner on SSH Server config file Service configuration files enable or disable features of their respective services that if configured incorrectly can lead to insecure and vulnerable configurations. Therefore, service configuration files should be owned by the correct group to prevent unauthorized changes. To properly set the owner of /etc/ssh/sshd_config, run the command: 
$ sudo chown root /etc/ssh/sshd_config 
To check the ownership of /etc/ssh/sshd_config,
run the command:

$ ls -lL /etc/ssh/sshd_config

If properly configured, the output should indicate the following owner:
root
      Is it the case that /etc/ssh/sshd_config does not have an owner of root?
 SRG-OS-000480-GPOS-00227 AC-17(a), CM-6(a), AC-6(1)
xccdf_org.ssgproject.content_rule_file_owner_var_log medium Verify User Who Owns /var/log Directory The /var/log directory contains files with logs of error messages in the system and should only be accessed by authorized personnel. To properly set the owner of /var/log, run the command: 
$ sudo chown root /var/log 
To check the ownership of /var/log,
run the command:

$ ls -lL /var/log

If properly configured, the output should indicate the following owner:
root
      Is it the case that /var/log does not have an owner of root?
 SRG-OS-000206-GPOS-00084, SRG-APP-000118-CTR-000240
xccdf_org.ssgproject.content_rule_file_owner_var_log_messages medium Verify User Who Owns /var/log/messages File The /var/log/messages file contains logs of error messages in the system and should only be accessed by authorized personnel. To properly set the owner of /var/log/messages, run the command: 
$ sudo chown root /var/log/messages 
To check the ownership of /var/log/messages,
run the command:

$ ls -lL /var/log/messages

If properly configured, the output should indicate the following owner:
root
      Is it the case that /var/log/messages does not have an owner of root?
 SRG-OS-000206-GPOS-00084
xccdf_org.ssgproject.content_rule_file_ownership_binary_dirs medium Verify that System Executables Have Root Ownership System binaries are executed by privileged users as well as system services, and restrictive permissions are necessary to ensure that their execution of these programs cannot be co-opted. System executables are stored in the following directories by default: 
/bin
/sbin
/usr/bin
/usr/libexec
/usr/local/bin
/usr/local/sbin
/usr/sbin
All files in these directories should be owned by the root user. If any file FILE in these directories is found to be owned by a user other than root, correct its ownership with the following command: 
$ sudo chown root FILE
 
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/libexec /usr/local/bin /usr/local/sbin ! -user root -exec ls -l {} \;
      Is it the case that any system commands are found to not be owned by root?
 SRG-OS-000259-GPOS-00100 CM-5(6), CM-5(6).1, CM-6(a), AC-6(1)
xccdf_org.ssgproject.content_rule_file_ownership_library_dirs medium Verify that Shared Library Files Have Root Ownership Files from shared library directories are loaded into the address space of processes (including privileged ones) or of the kernel itself at runtime. Proper ownership is necessary to protect the integrity of the system. System-wide shared library files, which are linked to executables during process load time or run time, are stored in the following directories by default: 
/lib
/lib64
/usr/lib
/usr/lib64
Kernel modules, which can be added to the kernel during runtime, are also stored in /lib/modules. All files in these directories should be owned by the root user. If the directory, or any file in these directories, is found to be owned by a user other than root correct its ownership with the following command: 
$ sudo chown root FILE
 
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 {} \;
      Is it the case that any system wide shared library file is not owned by root?
 SRG-OS-000259-GPOS-00100 CM-5(6), CM-5(6).1, CM-6(a), AC-6(1)
xccdf_org.ssgproject.content_rule_file_permission_user_init_files medium Ensure All User Initialization Files Have Mode 0740 Or Less Permissive Local initialization files are used to configure the user's shell environment upon logon. Malicious modification of these files could compromise accounts upon logon. Set the mode of the user initialization files to 0740 with the following command: 
$ sudo chmod 0740 /home/USER/.INIT_FILE
 
To verify that all user initialization files have a mode of 0740 or
less permissive, run the following command:

$ sudo find /home -type f -name '\.*' \( -perm -0002 -o -perm -0020 \)

There should be no output.
      Is it the case that they are not 0740 or more permissive?
 SRG-OS-000480-GPOS-00227
xccdf_org.ssgproject.content_rule_file_permissions_backup_etc_group medium Verify Permissions on Backup group File The /etc/group- file is a backup file of /etc/group, and as such, it contains information regarding groups that are configured on the system. Protection of this file is important for system security. To properly set the permissions of /etc/group-, run the command: 
$ sudo chmod 0644 /etc/group-
 
To check the permissions of /etc/group-,
run the command:

$ ls -l /etc/group-

If properly configured, the output should indicate the following permissions:
-rw-r--r--
      Is it the case that /etc/group- does not have unix mode -rw-r--r--?
 SRG-OS-000480-GPOS-00227 AC-6 (1)
xccdf_org.ssgproject.content_rule_file_permissions_backup_etc_gshadow medium Verify Permissions on Backup gshadow File The /etc/gshadow- file is a backup of /etc/gshadow, and as such, it contains group password hashes. Protection of this file is critical for system security. To properly set the permissions of /etc/gshadow-, run the command: 
$ sudo chmod 0000 /etc/gshadow-
 
To check the permissions of /etc/gshadow-,
run the command:

$ ls -l /etc/gshadow-

If properly configured, the output should indicate the following permissions:
----------
      Is it the case that /etc/gshadow- does not have unix mode ----------?
 SRG-OS-000480-GPOS-00227 AC-6 (1)
xccdf_org.ssgproject.content_rule_file_permissions_backup_etc_passwd medium Verify Permissions on Backup passwd File The /etc/passwd- file is a backup file of /etc/passwd, and as such, it contains information about the users that are configured on the system. Protection of this file is critical for system security. To properly set the permissions of /etc/passwd-, run the command: 
$ sudo chmod 0644 /etc/passwd-
 
To check the permissions of /etc/passwd-,
run the command:

$ ls -l /etc/passwd-

If properly configured, the output should indicate the following permissions:
-rw-r--r--
      Is it the case that /etc/passwd- does not have unix mode -rw-r--r--?
 SRG-OS-000480-GPOS-00227 AC-6 (1)
xccdf_org.ssgproject.content_rule_file_permissions_backup_etc_shadow medium Verify Permissions on Backup shadow File The /etc/shadow- file is a backup file of /etc/shadow, and as such, it contains the list of local system accounts and password hashes. Protection of this file is critical for system security. To properly set the permissions of /etc/shadow-, run the command: 
$ sudo chmod 0000 /etc/shadow-
 
To check the permissions of /etc/shadow-,
run the command:

$ ls -l /etc/shadow-

If properly configured, the output should indicate the following permissions:
----------
      Is it the case that /etc/shadow- does not have unix mode ----------?
 SRG-OS-000480-GPOS-00227 AC-6 (1)
xccdf_org.ssgproject.content_rule_file_permissions_binary_dirs medium Verify that System Executables Have Restrictive Permissions System binaries are executed by privileged users, as well as system services, and restrictive permissions are necessary to ensure execution of these programs cannot be co-opted. System executables are stored in the following directories by default: 
/bin
/sbin
/usr/bin
/usr/libexec
/usr/local/bin
/usr/local/sbin
/usr/sbin
All files in these directories should not be group-writable or world-writable. If any file FILE in these directories is found to be group-writable or world-writable, correct its permission with the following command: 
$ sudo chmod go-w FILE
 
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/libexec /usr/local/bin /usr/local/sbin -perm /022 -exec ls -l {} \;
      Is it the case that any system commands are found to be group-writable or world-writable?
 SRG-OS-000259-GPOS-00100 CM-5(6), CM-5(6).1, CM-6(a), AC-6(1)
xccdf_org.ssgproject.content_rule_file_permissions_cron_d medium Verify Permissions on cron.d Service configuration files enable or disable features of their respective services that if configured incorrectly can lead to insecure and vulnerable configurations. Therefore, service configuration files should have the correct access rights to prevent unauthorized changes. To properly set the permissions of /etc/cron.d, run the command: 
$ sudo chmod 0700 /etc/cron.d
 
To check the permissions of /etc/cron.d,
run the command:

$ ls -l /etc/cron.d

If properly configured, the output should indicate the following permissions:
-rwx------
      Is it the case that /etc/cron.d does not have unix mode -rwx------?
 SRG-OS-000480-GPOS-00227 CM-6(a), AC-6(1)
xccdf_org.ssgproject.content_rule_file_permissions_cron_daily medium Verify Permissions on cron.daily Service configuration files enable or disable features of their respective services that if configured incorrectly can lead to insecure and vulnerable configurations. Therefore, service configuration files should have the correct access rights to prevent unauthorized changes. To properly set the permissions of /etc/cron.daily, run the command: 
$ sudo chmod 0700 /etc/cron.daily
 
To check the permissions of /etc/cron.daily,
run the command:

$ ls -l /etc/cron.daily

If properly configured, the output should indicate the following permissions:
-rwx------
      Is it the case that /etc/cron.daily does not have unix mode -rwx------?
 SRG-OS-000480-GPOS-00227 CM-6(a), AC-6(1)
xccdf_org.ssgproject.content_rule_file_permissions_cron_hourly medium Verify Permissions on cron.hourly Service configuration files enable or disable features of their respective services that if configured incorrectly can lead to insecure and vulnerable configurations. Therefore, service configuration files should have the correct access rights to prevent unauthorized changes. To properly set the permissions of /etc/cron.hourly, run the command: 
$ sudo chmod 0700 /etc/cron.hourly
 
To check the permissions of /etc/cron.hourly,
run the command:

$ ls -l /etc/cron.hourly

If properly configured, the output should indicate the following permissions:
-rwx------
      Is it the case that /etc/cron.hourly does not have unix mode -rwx------?
 SRG-OS-000480-GPOS-00227 CM-6(a), AC-6(1)
xccdf_org.ssgproject.content_rule_file_permissions_cron_monthly medium Verify Permissions on cron.monthly Service configuration files enable or disable features of their respective services that if configured incorrectly can lead to insecure and vulnerable configurations. Therefore, service configuration files should have the correct access rights to prevent unauthorized changes. To properly set the permissions of /etc/cron.monthly, run the command: 
$ sudo chmod 0700 /etc/cron.monthly
 
To check the permissions of /etc/cron.monthly,
run the command:

$ ls -l /etc/cron.monthly

If properly configured, the output should indicate the following permissions:
-rwx------
      Is it the case that /etc/cron.monthly does not have unix mode -rwx------?
 SRG-OS-000480-GPOS-00227 CM-6(a), AC-6(1)
xccdf_org.ssgproject.content_rule_file_permissions_cron_weekly medium Verify Permissions on cron.weekly Service configuration files enable or disable features of their respective services that if configured incorrectly can lead to insecure and vulnerable configurations. Therefore, service configuration files should have the correct access rights to prevent unauthorized changes. To properly set the permissions of /etc/cron.weekly, run the command: 
$ sudo chmod 0700 /etc/cron.weekly
 
To check the permissions of /etc/cron.weekly,
run the command:

$ ls -l /etc/cron.weekly

If properly configured, the output should indicate the following permissions:
-rwx------
      Is it the case that /etc/cron.weekly does not have unix mode -rwx------?
 SRG-OS-000480-GPOS-00227 CM-6(a), AC-6(1)
xccdf_org.ssgproject.content_rule_file_permissions_crontab medium Verify Permissions on crontab Service configuration files enable or disable features of their respective services that if configured incorrectly can lead to insecure and vulnerable configurations. Therefore, service configuration files should have the correct access rights to prevent unauthorized changes. To properly set the permissions of /etc/crontab, run the command: 
$ sudo chmod 0600 /etc/crontab
 
To check the permissions of /etc/crontab,
run the command:

$ ls -l /etc/crontab

If properly configured, the output should indicate the following permissions:
-rw-------
      Is it the case that /etc/crontab does not have unix mode -rw-------?
 SRG-OS-000480-GPOS-00227 CM-6(a), AC-6(1)
xccdf_org.ssgproject.content_rule_file_permissions_etc_audit_auditd medium Verify Permissions on /etc/audit/auditd.conf Without the capability to restrict the roles and individuals that can select which events are audited, unauthorized personnel may be able to prevent the auditing of critical events. Misconfigured audits may degrade the system's performance by overwhelming the audit log. Misconfigured audits may also make it more difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. To properly set the permissions of /etc/audit/auditd.conf, run the command: 
$ sudo chmod 0640 /etc/audit/auditd.conf
 
To check the permissions of /etc/audit/auditd.conf,
run the command:

$ ls -l /etc/audit/auditd.conf

If properly configured, the output should indicate the following permissions:
-rw-r-----
      Is it the case that /etc/audit/auditd.conf does not have unix mode -rw-r-----?
 SRG-OS-000063-GPOS-00032 AU-12(b)
xccdf_org.ssgproject.content_rule_file_permissions_etc_audit_rulesd medium Verify Permissions on /etc/audit/rules.d/*.rules Without the capability to restrict the roles and individuals that can select which events are audited, unauthorized personnel may be able to prevent the auditing of critical events. Misconfigured audits may degrade the system's performance by overwhelming the audit log. Misconfigured audits may also make it more difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. To properly set the permissions of /etc/audit/rules.d/*.rules, run the command: 
$ sudo chmod 0600 /etc/audit/rules.d/*.rules
 
To check the permissions of /etc/audit/rules.d/*.rules,
run the command:

$ ls -l /etc/audit/rules.d/*.rules

If properly configured, the output should indicate the following permissions:
-rw-------
      Is it the case that /etc/audit/rules.d/*.rules does not have unix mode -rw-------?
 SRG-OS-000063-GPOS-00032 AU-12(b)
xccdf_org.ssgproject.content_rule_file_permissions_etc_group medium Verify Permissions on group File The /etc/group file contains information regarding groups that are configured on the system. Protection of this file is important for system security. To properly set the permissions of /etc/group, run the command: 
$ sudo chmod 0644 /etc/group
 
To check the permissions of /etc/group,
run the command:

$ ls -l /etc/group

If properly configured, the output should indicate the following permissions:
-rw-r--r--
      Is it the case that /etc/group does not have unix mode -rw-r--r--?
 SRG-OS-000480-GPOS-00227 CM-6(a), AC-6(1)
xccdf_org.ssgproject.content_rule_file_permissions_etc_gshadow medium Verify Permissions on gshadow File The /etc/gshadow file contains group password hashes. Protection of this file is critical for system security. To properly set the permissions of /etc/gshadow, run the command: 
$ sudo chmod 0000 /etc/gshadow
 
To check the permissions of /etc/gshadow,
run the command:

$ ls -l /etc/gshadow

If properly configured, the output should indicate the following permissions:
----------
      Is it the case that /etc/gshadow does not have unix mode ----------?
 SRG-OS-000480-GPOS-00227 CM-6(a), AC-6(1)
xccdf_org.ssgproject.content_rule_file_permissions_etc_passwd medium Verify Permissions on passwd File If the /etc/passwd file is writable by a group-owner or the world the risk of its compromise is increased. The file contains the list of accounts on the system and associated information, and protection of this file is critical for system security. To properly set the permissions of /etc/passwd, run the command: 
$ sudo chmod 0644 /etc/passwd
 
To check the permissions of /etc/passwd,
run the command:

$ ls -l /etc/passwd

If properly configured, the output should indicate the following permissions:
-rw-r--r--
      Is it the case that /etc/passwd does not have unix mode -rw-r--r--?
 SRG-OS-000480-GPOS-00227 CM-6(a), AC-6(1)
xccdf_org.ssgproject.content_rule_file_permissions_etc_shadow medium Verify Permissions on shadow File The /etc/shadow file contains the list of local system accounts and stores password hashes. Protection of this file is critical for system security. Failure to give ownership of this file to root provides the designated owner with access to sensitive information which could weaken the system security posture. To properly set the permissions of /etc/shadow, run the command: 
$ sudo chmod 0000 /etc/shadow
 
To check the permissions of /etc/shadow,
run the command:

$ ls -l /etc/shadow

If properly configured, the output should indicate the following permissions:
----------
      Is it the case that /etc/shadow does not have unix mode ----------?
 SRG-OS-000480-GPOS-00227 CM-6(a), AC-6(1)
xccdf_org.ssgproject.content_rule_file_permissions_home_directories medium All Interactive User Home Directories Must Have mode 0750 Or Less Permissive Excessive permissions on local interactive user home directories may allow unauthorized access to user files by other users. Change the mode of interactive users home directories to 0750. To change the mode of interactive users home directory, use the following command: 
$ sudo chmod 0750 /home/USER
 
To verify the assigned home directory of all interactive user home directories
have a mode of 
0750
 or less permissive, run the following command:

$ sudo ls -l /home

Inspect the output for any directories with incorrect permissions.
      Is it the case that they are more permissive?
 SRG-OS-000480-GPOS-00227
xccdf_org.ssgproject.content_rule_file_permissions_library_dirs medium Verify that Shared Library Files Have Restrictive Permissions Files from shared library directories are loaded into the address space of processes (including privileged ones) or of the kernel itself at runtime. Restrictive permissions are necessary to protect the integrity of the system. System-wide shared library files, which are linked to executables during process load time or run time, are stored in the following directories by default: 
/lib
/lib64
/usr/lib
/usr/lib64
Kernel modules, which can be added to the kernel during runtime, are stored in /lib/modules. All files in these directories should not be group-writable or world-writable. If any file in these directories is found to be group-writable or world-writable, correct its permission with the following command: 
$ sudo chmod go-w FILE
 
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 {} \;
      Is it the case that any system-wide shared library file is found to be group-writable or world-writable?
 SRG-OS-000259-GPOS-00100 CM-6(a), CM-5(6), CM-5(6).1, AC-6(1)
xccdf_org.ssgproject.content_rule_file_permissions_sshd_config medium Verify Permissions on SSH Server config file Service configuration files enable or disable features of their respective services that if configured incorrectly can lead to insecure and vulnerable configurations. Therefore, service configuration files should be owned by the correct group to prevent unauthorized changes. To properly set the permissions of /etc/ssh/sshd_config, run the command: 
$ sudo chmod 0600 /etc/ssh/sshd_config
 
To check the permissions of /etc/ssh/sshd_config,
run the command:

$ ls -l /etc/ssh/sshd_config

If properly configured, the output should indicate the following permissions:
-rw-------
      Is it the case that /etc/ssh/sshd_config does not have unix mode -rw-------?
 SRG-OS-000480-GPOS-00227 AC-17(a), CM-6(a), AC-6(1)
xccdf_org.ssgproject.content_rule_file_permissions_sshd_private_key medium Verify Permissions on SSH Server Private *_key Key Files If an unauthorized user obtains the private SSH host key file, the host could be impersonated. SSH server private keys - files that match the /etc/ssh/*_key glob, have to have restricted permissions. If those files are owned by the root user and the root group, they have to have the 0640 permission or stricter. If they are owned by the root user, but by a dedicated group ssh_keys, they can have the 0640 permission or stricter. 
To check the permissions of /etc/ssh/*_key,
run the command:

$ ls -l /etc/ssh/*_key

If properly configured, the output should indicate the following permissions:
-rw-r-----
      Is it the case that /etc/ssh/*_key does not have unix mode -rw-r-----?
 SRG-OS-000480-GPOS-00227 AC-17(a), CM-6(a), AC-6(1)
xccdf_org.ssgproject.content_rule_file_permissions_sshd_pub_key medium Verify Permissions on SSH Server Public *.pub Key Files If a public host key file is modified by an unauthorized user, the SSH service may be compromised. To properly set the permissions of /etc/ssh/*.pub, run the command: 
$ sudo chmod 0644 /etc/ssh/*.pub
 
To check the permissions of /etc/ssh/*.pub,
run the command:

$ ls -l /etc/ssh/*.pub

If properly configured, the output should indicate the following permissions:
-rw-r--r--
      Is it the case that /etc/ssh/*.pub does not have unix mode -rw-r--r--?
 SRG-OS-000480-GPOS-00227 AC-17(a), CM-6(a), AC-6(1)
xccdf_org.ssgproject.content_rule_file_permissions_ungroupowned medium Ensure All Files Are Owned by a Group Unowned files do not directly imply a security problem, but they are generally a sign that something is amiss. They may be caused by an intruder, by incorrect software installation or draft software removal, or by failure to remove all files belonging to a deleted account, or other similar cases. The files should be repaired so they will not cause problems when accounts are created in the future, and the cause should be discovered and addressed. If any file is not group-owned by a valid defined group, the cause of the lack of group-ownership must be investigated. Following this, those files should be deleted or assigned to an appropriate group. The groups need to be defined in /etc/group or in /usr/lib/group if nss-altfiles are configured to be used in /etc/nsswitch.conf. Locate the mount points related to local devices by the following command: 
$ findmnt -n -l -k -it $(awk '/nodev/ { print $2 }' /proc/filesystems | paste -sd,)
For all mount points listed by the previous command, it is necessary to search for files which do not belong to a valid group using the following command: 
$ sudo find MOUNTPOINT -xdev -nogroup 2>/dev/null
 
The following command will locate the mount points related to local devices:

$ findmnt -n -l -k -it $(awk '/nodev/ { print $2 }' /proc/filesystems | paste -sd,)


The following command will show files which do not belong to a valid group:

$ sudo find MOUNTPOINT -xdev -nogroup 2>/dev/null


Replace MOUNTPOINT by the mount points listed by the fist command.

No files without a valid group should be located.
      Is it the case that there is output?
 SRG-OS-000480-GPOS-00227 CM-6(a), AC-6(1)
xccdf_org.ssgproject.content_rule_file_permissions_var_log medium Verify Permissions on /var/log Directory The /var/log directory contains files with logs of error messages in the system and should only be accessed by authorized personnel. To properly set the permissions of /var/log, run the command: 
$ sudo chmod 0755 /var/log
 
To check the permissions of /var/log,
run the command:

$ ls -l /var/log

If properly configured, the output should indicate the following permissions:
drwxr-xr-x
      Is it the case that /var/log does not have unix mode drwxr-xr-x?
 SRG-OS-000206-GPOS-00084, SRG-APP-000118-CTR-000240
xccdf_org.ssgproject.content_rule_file_permissions_var_log_audit medium System Audit Logs Must Have Mode 0640 or Less Permissive If users can write to audit logs, audit trails can be modified or destroyed. Determine where the audit logs are stored with the following command: 
$ sudo grep -iw log_file /etc/audit/auditd.conf
log_file = /var/log/audit/audit.log
Configure the audit log to be protected from unauthorized read access by setting the correct permissive mode with the following command: 
$ sudo chmod 0600 audit_log_file
By default, audit_log_file is "/var/log/audit/audit.log".		 
Run the following command to check the mode of the system audit logs:

$ sudo grep -iw log_file /etc/audit/auditd.conf


log_file=/var/log/audit/audit.log


$ sudo stat -c "%n %a" /var/log/audit/*


$ sudo ls -l /var/log/audit

Audit logs must be mode 0640 or less permissive.
      Is it the case that any permissions are more permissive?
 SRG-OS-000057-GPOS-00027, SRG-OS-000058-GPOS-00028, SRG-OS-000059-GPOS-00029, SRG-OS-000206-GPOS-00084, SRG-APP-000118-CTR-000240 CM-6(a), AC-6(1), AU-9(4)
xccdf_org.ssgproject.content_rule_file_permissions_var_log_messages medium Verify Permissions on /var/log/messages File The /var/log/messages file contains logs of error messages in the system and should only be accessed by authorized personnel. To properly set the permissions of /var/log/messages, run the command: 
$ sudo chmod 0640 /var/log/messages
 
To check the permissions of /var/log/messages,
run the command:

$ ls -l /var/log/messages

If properly configured, the output should indicate the following permissions:
-rw-r-----
      Is it the case that /var/log/messages does not have unix mode -rw-r-----?
 SRG-OS-000206-GPOS-00084
xccdf_org.ssgproject.content_rule_file_sshd_50_redhat_exists medium The File /etc/ssh/sshd_config.d/50-redhat.conf Must Exist The file must exist to configure SSH correctly. The /etc/ssh/sshd_config.d/50-redhat.conf file must exist as it contains important settings to secure SSH. 
None
      Is it the case that None?
 SRG-OS-000250-GPOS-00093 AC-17 (2)
xccdf_org.ssgproject.content_rule_fips_crypto_policy_symlinks medium System Wide Crypto Policy Files Must Point to FIPS Policy Centralized cryptographic policies simplify applying secure ciphers across an operating system and the applications that run on that operating system. Use of weak or untested encryption algorithms undermines the purposes of using encryption to protect data. All files in /etc/crypto-policies/back-ends/ except for nss.config should be symlinks pointing to /usr/share/crypto-policies/FIPS/ 
$ stat -c%N /etc/crypto-policies/back-ends/*
'/etc/crypto-policies/back-ends/bind.config' -> '/usr/share/crypto-policies/FIPS/bind.txt'
'/etc/crypto-policies/back-ends/gnutls.config' -> '/usr/share/crypto-policies/FIPS/gnutls.txt'
'/etc/crypto-policies/back-ends/java.config' -> '/usr/share/crypto-policies/FIPS/java.txt'
'/etc/crypto-policies/back-ends/javasystem.config' -> '/usr/share/crypto-policies/FIPS/javasystem.txt'
'/etc/crypto-policies/back-ends/krb5.config' -> '/usr/share/crypto-policies/FIPS/krb5.txt'
'/etc/crypto-policies/back-ends/libreswan.config' -> '/usr/share/crypto-policies/FIPS/libreswan.txt'
'/etc/crypto-policies/back-ends/libssh.config' -> '/usr/share/crypto-policies/FIPS/libssh.txt'
'/etc/crypto-policies/back-ends/nss.config'
'/etc/crypto-policies/back-ends/openssh.config' -> '/usr/share/crypto-policies/FIPS/openssh.txt'
'/etc/crypto-policies/back-ends/opensshserver.config' -> '/usr/share/crypto-policies/FIPS/opensshserver.txt'
'/etc/crypto-policies/back-ends/opensslcnf.config' -> '/usr/share/crypto-policies/FIPS/opensslcnf.txt'
'/etc/crypto-policies/back-ends/openssl.config' -> '/usr/share/crypto-policies/FIPS/openssl.txt'
'/etc/crypto-policies/back-ends/openssl_fips.config' -> '/usr/share/crypto-policies/FIPS/openssl_fips.txt'

Validate all files are symlinks to pointing to /usr/share/crypto-policies/FIPS/ except for
nss.config:

$ stat -c%N /etc/crypto-policies/back-ends/*
'/etc/crypto-policies/back-ends/bind.config' -> '/usr/share/crypto-policies/FIPS/bind.txt'
'/etc/crypto-policies/back-ends/gnutls.config' -> '/usr/share/crypto-policies/FIPS/gnutls.txt'
'/etc/crypto-policies/back-ends/java.config' -> '/usr/share/crypto-policies/FIPS/java.txt'
'/etc/crypto-policies/back-ends/javasystem.config' -> '/usr/share/crypto-policies/FIPS/javasystem.txt'
'/etc/crypto-policies/back-ends/krb5.config' -> '/usr/share/crypto-policies/FIPS/krb5.txt'
'/etc/crypto-policies/back-ends/libreswan.config' -> '/usr/share/crypto-policies/FIPS/libreswan.txt'
'/etc/crypto-policies/back-ends/libssh.config' -> '/usr/share/crypto-policies/FIPS/libssh.txt'
'/etc/crypto-policies/back-ends/nss.config'
'/etc/crypto-policies/back-ends/openssh.config' -> '/usr/share/crypto-policies/FIPS/openssh.txt'
'/etc/crypto-policies/back-ends/opensshserver.config' -> '/usr/share/crypto-policies/FIPS/opensshserver.txt'
'/etc/crypto-policies/back-ends/opensslcnf.config' -> '/usr/share/crypto-policies/FIPS/opensslcnf.txt'
'/etc/crypto-policies/back-ends/openssl.config' -> '/usr/share/crypto-policies/FIPS/openssl.txt'
'/etc/crypto-policies/back-ends/openssl_fips.config' -> '/usr/share/crypto-policies/FIPS/openssl_fips.txt'


      Is it the case that Any file shows a different output?
 SRG-OS-000396-GPOS-00176, SRG-OS-000393-GPOS-00173, SRG-OS-000394-GPOS-00174 SC-13, MA-4(6)
xccdf_org.ssgproject.content_rule_firewalld-backend medium Configure Firewalld to Use the Nftables Backend Nftables is modern kernel module for controlling network connections coming into a system. Utilizing the limit statement in "nftables" can help to mitigate DoS attacks. Firewalld can be configured with many backends, such as nftables. 
Verify "nftables" is configured to allow rate limits on any connection to the system with the following command:

Verify "firewalld" has "nftables" set as the default backend:

$ sudo grep -i firewallbackend /etc/firewalld/firewalld.conf

# FirewallBackend
FirewallBackend=nftables
      Is it the case that the "nftables" is not set as the "firewallbackend"?
 SRG-OS-000420-GPOS-00186 SC-5
xccdf_org.ssgproject.content_rule_gid_passwd_group_same low All GIDs referenced in /etc/passwd must be defined in /etc/group If a user is assigned the Group Identifier (GID) of a group not existing on the system, and a group with the Group Identifier (GID) is subsequently created, the user may have unintended rights to any files associated with the group. Add a group to the system for each GID referenced without a corresponding group. 
To ensure all GIDs referenced in /etc/passwd are defined in /etc/group,
run the following command:

$ sudo pwck -qr

There should be no output.
      Is it the case that GIDs referenced in /etc/passwd are returned as not defined in /etc/group?
 SRG-OS-000104-GPOS-00051 IA-2, CM-6(a)
xccdf_org.ssgproject.content_rule_gnome_gdm_disable_automatic_login high Disable GDM Automatic Login Failure to restrict system access to authenticated users negatively impacts operating system security. The GNOME Display Manager (GDM) can allow users to automatically login without user interaction or credentials. User should always be required to authenticate themselves to the system that they are authorized to use. To disable user ability to automatically login to the system, set the AutomaticLoginEnable to false in the [daemon] section in /etc/gdm/custom.conf. For example: 
[daemon]
AutomaticLoginEnable=false
 
To verify that automatic logins are disabled, run the following command:

$ grep -Pzoi "^\[daemon]\\nautomaticlogin.*" /etc/gdm/custom.conf

The output should show the following:

[daemon]
AutomaticLoginEnable=false

      Is it the case that GDM allows users to automatically login?
 SRG-OS-000480-GPOS-00229 CM-6(a), AC-6(1), CM-7(b)
xccdf_org.ssgproject.content_rule_group_unique_id medium Ensure All Groups on the System Have Unique Group ID To assure accountability and prevent unauthenticated access, groups must be identified uniquely to prevent potential misuse and compromise of the system. Change the group name or delete groups, so each has a unique id. 
Run the following command to check for duplicate group names:
Check that the operating system contains no duplicate Group ID (GID) for interactive users by running the following command:

    cut -d : -f 3 /etc/group | uniq -d


If output is produced, this is a finding.
Configure the operating system to contain no duplicate GIDs.
Edit the file "/etc/group" and provide each group that has a duplicate GID with a unique GID.
      Is it the case that the system has duplicate group ids?
 SRG-OS-000104-GPOS-00051
xccdf_org.ssgproject.content_rule_grub2_admin_username high Set the Boot Loader Admin Username to a Non-Default Value Having a non-default grub superuser username makes password-guessing attacks less effective. The grub2 boot loader should have a superuser account and password protection enabled to protect boot-time settings.

To maximize the protection, select a password-protected superuser account with unique name, and modify the /etc/grub.d/01_users configuration file to reflect the account name change.

Do not to use common administrator account names like root, admin, or administrator for the grub2 superuser account.

Change the superuser to a different username (The default is 'root'). 
$ sed -i 's/\(set superusers=\).*/\1"<unique user ID>"/g' /etc/grub.d/01_users
The line mentioned above must be followed by the line 
export superusers
so that the superusers is honored.

Once the superuser account has been added, update the grub.cfg file by running: 
grubby --update-kernel=ALL
 
To verify the boot loader superuser account has been set, run the following
command:

sudo grep -A1 "superusers" /boot/grub2/grub.cfg

The output should show the following:

set superusers="superusers-account"
export superusers

where superusers-account is the actual account name different from common names like root,
admin, or administrator and different from any other existing user name.
      Is it the case that superuser account is not set or is set to root, admin, administrator or any other existing user name?
 SRG-OS-000080-GPOS-00048 CM-6(a)
xccdf_org.ssgproject.content_rule_grub2_audit_argument low Enable Auditing for Processes Which Start Prior to the Audit Daemon Each process on the system carries an "auditable" flag which indicates whether its activities can be audited. Although auditd takes care of enabling this for all processes which launch after it does, adding the kernel argument ensures it is set for every process during boot. To ensure all processes can be audited, even those which start prior to the audit daemon, add the argument audit=1 to the default GRUB 2 command line for the Linux operating system. To ensure that audit=1 is added as a kernel command line argument to newly installed kernels, add audit=1 to the default Grub2 command line for Linux operating systems. Modify the line within /etc/default/grub as shown below: 
GRUB_CMDLINE_LINUX="... audit=1 ..."
Run the following command to update command line for already installed kernels:
# grubby --update-kernel=ALL --args="audit=1"
 
Inspect the form of default GRUB 2 command line for the Linux operating system
in /etc/default/grub. If it includes audit=1,
then the parameter will be configured for newly installed kernels.
First check if the GRUB recovery is enabled:

$ sudo grep 'GRUB_DISABLE_RECOVERY' /etc/default/grub

If this option is set to true, then check that a line is output by the following command:

$ sudo grep 'GRUB_CMDLINE_LINUX_DEFAULT.*audit=1.*' /etc/default/grub

If the recovery is disabled, check the line with

$ sudo grep 'GRUB_CMDLINE_LINUX.*audit=1.*' /etc/default/grub
.Moreover, command line parameters for currently installed kernels should be checked as well.
Run the following command:

$ sudo grubby --info=ALL | grep args | grep -v 'audit=1'

The command should not return any output.
      Is it the case that auditing is not enabled at boot time?
 SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215, SRG-OS-000473-GPOS-00218, SRG-OS-000254-GPOS-00095 AC-17(1), AU-14(1), AU-10, CM-6(a), IR-5(1)
xccdf_org.ssgproject.content_rule_grub2_audit_backlog_limit_argument low Extend Audit Backlog Limit for the Audit Daemon audit_backlog_limit sets the queue length for audit events awaiting transfer to the audit daemon. Until the audit daemon is up and running, all log messages are stored in this queue. If the queue is overrun during boot process, the action defined by audit failure flag is taken. To improve the kernel capacity to queue all log events, even those which occurred prior to the audit daemon, add the argument audit_backlog_limit=8192 to the default GRUB 2 command line for the Linux operating system. To ensure that audit_backlog_limit=8192 is added as a kernel command line argument to newly installed kernels, add audit_backlog_limit=8192 to the default Grub2 command line for Linux operating systems. Modify the line within /etc/default/grub as shown below: 
GRUB_CMDLINE_LINUX="... audit_backlog_limit=8192 ..."
Run the following command to update command line for already installed kernels:
# grubby --update-kernel=ALL --args="audit_backlog_limit=8192"
 
Inspect the form of default GRUB 2 command line for the Linux operating system
in /etc/default/grub. If it includes audit_backlog_limit=8192,
then the parameter will be configured for newly installed kernels.
First check if the GRUB recovery is enabled:

$ sudo grep 'GRUB_DISABLE_RECOVERY' /etc/default/grub

If this option is set to true, then check that a line is output by the following command:

$ sudo grep 'GRUB_CMDLINE_LINUX_DEFAULT.*audit_backlog_limit=8192.*' /etc/default/grub

If the recovery is disabled, check the line with

$ sudo grep 'GRUB_CMDLINE_LINUX.*audit_backlog_limit=8192.*' /etc/default/grub
.Moreover, command line parameters for currently installed kernels should be checked as well.
Run the following command:

$ sudo grubby --info=ALL | grep args | grep -v 'audit_backlog_limit=8192'

The command should not return any output.
      Is it the case that audit backlog limit is not configured?
 SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000254-GPOS-00095, SRG-OS-000341-GPOS-00132, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215 CM-6(a)
xccdf_org.ssgproject.content_rule_grub2_disable_interactive_boot medium Verify that Interactive Boot is Disabled Using interactive or recovery boot, the console user could disable auditing, firewalls, or other services, weakening system security. Oracle Linux 9 systems support an "interactive boot" option that can be used to prevent services from being started. On a Oracle Linux 9 system, interactive boot can be enabled by providing a 1, yes, true, or on value to the systemd.confirm_spawn kernel argument in /etc/default/grub. Remove any instance of 
systemd.confirm_spawn=(1|yes|true|on)
from the kernel arguments in that file to disable interactive boot. Recovery booting must also be disabled. Confirm that GRUB_DISABLE_RECOVERY=true is set in /etc/default/grub. It is also required to change the runtime configuration, run: 
/sbin/grubby --update-kernel=ALL --remove-args="systemd.confirm_spawn"
grub2-mkconfig -o /boot/grub2/grub.cfg
 
Inspect /etc/default/grub for any instances of
systemd.confirm_spawn=(1|yes|true|on) in the kernel boot arguments.
Presence of a systemd.confirm_spawn=(1|yes|true|on) indicates
that interactive boot is enabled at boot time and verify that
GRUB_DISABLE_RECOVERY=true to disable recovery boot.
      Is it the case that Interactive boot is enabled at boot time?
 SRG-OS-000480-GPOS-00227 SC-2(1), CM-6(a)
xccdf_org.ssgproject.content_rule_grub2_page_poison_argument medium Enable page allocator poisoning Poisoning writes an arbitrary value to freed pages, so any modification or reference to that page after being freed or before being initialized will be detected and prevented. This prevents many types of use-after-free vulnerabilities at little performance cost. Also prevents leak of data and detection of corrupted memory. To enable poisoning of free pages, add the argument page_poison=1 to the default GRUB 2 command line for the Linux operating system. To ensure that page_poison=1 is added as a kernel command line argument to newly installed kernels, add page_poison=1 to the default Grub2 command line for Linux operating systems. Modify the line within /etc/default/grub as shown below: 
GRUB_CMDLINE_LINUX="... page_poison=1 ..."
Run the following command to update command line for already installed kernels:
# grubby --update-kernel=ALL --args="page_poison=1"
 
Inspect the form of default GRUB 2 command line for the Linux operating system
in /etc/default/grub. If it includes page_poison=1,
then the parameter will be configured for newly installed kernels.
First check if the GRUB recovery is enabled:

$ sudo grep 'GRUB_DISABLE_RECOVERY' /etc/default/grub

If this option is set to true, then check that a line is output by the following command:

$ sudo grep 'GRUB_CMDLINE_LINUX_DEFAULT.*page_poison=1.*' /etc/default/grub

If the recovery is disabled, check the line with

$ sudo grep 'GRUB_CMDLINE_LINUX.*page_poison=1.*' /etc/default/grub
.Moreover, command line parameters for currently installed kernels should be checked as well.
Run the following command:

$ sudo grubby --info=ALL | grep args | grep -v 'page_poison=1'

The command should not return any output.
      Is it the case that page allocator poisoning is not enabled?
 SRG-OS-000480-GPOS-00227, SRG-OS-000134-GPOS-00068 CM-6(a)
xccdf_org.ssgproject.content_rule_grub2_password high Set Boot Loader Password in grub2 Password protection on the boot loader configuration ensures users with physical access cannot trivially alter important bootloader settings. These include which kernel to use, and whether to enter single-user mode. The grub2 boot loader should have a superuser account and password protection enabled to protect boot-time settings.

Since plaintext passwords are a security risk, generate a hash for the password by running the following command: 
# grub2-setpassword
When prompted, enter the password that was selected. 

First, check whether the password is defined in either /boot/grub2/user.cfg or
/boot/grub2/grub.cfg.
Run the following commands:

$ sudo grep '^[\s]*GRUB2_PASSWORD=grub\.pbkdf2\.sha512.*$' /boot/grub2/user.cfg
$ sudo grep '^[\s]*password_pbkdf2[\s]+.*[\s]+grub\.pbkdf2\.sha512.*$' /boot/grub2/grub.cfg



Second, check that a superuser is defined in /boot/grub2/grub.cfg.

$ sudo grep '^[\s]*set[\s]+superusers=("?)[a-zA-Z_]+\1$'  /boot/grub2/grub.cfg

      Is it the case that it does not produce any output?
 SRG-OS-000080-GPOS-00048 CM-6(a)
xccdf_org.ssgproject.content_rule_grub2_pti_argument low Enable Kernel Page-Table Isolation (KPTI) Kernel page-table isolation is a kernel feature that mitigates the Meltdown security vulnerability and hardens the kernel against attempts to bypass kernel address space layout randomization (KASLR). To enable Kernel page-table isolation, add the argument pti=on to the default GRUB 2 command line for the Linux operating system. To ensure that pti=on is added as a kernel command line argument to newly installed kernels, add pti=on to the default Grub2 command line for Linux operating systems. Modify the line within /etc/default/grub as shown below: 
GRUB_CMDLINE_LINUX="... pti=on ..."
Run the following command to update command line for already installed kernels:
# grubby --update-kernel=ALL --args="pti=on"
 
Inspect the form of default GRUB 2 command line for the Linux operating system
in /etc/default/grub. If it includes pti=on,
then the parameter will be configured for newly installed kernels.
First check if the GRUB recovery is enabled:

$ sudo grep 'GRUB_DISABLE_RECOVERY' /etc/default/grub

If this option is set to true, then check that a line is output by the following command:

$ sudo grep 'GRUB_CMDLINE_LINUX_DEFAULT.*pti=on.*' /etc/default/grub

If the recovery is disabled, check the line with

$ sudo grep 'GRUB_CMDLINE_LINUX.*pti=on.*' /etc/default/grub
.Moreover, command line parameters for currently installed kernels should be checked as well.
Run the following command:

$ sudo grubby --info=ALL | grep args | grep -v 'pti=on'

The command should not return any output.
      Is it the case that Kernel page-table isolation is not enabled?
 SRG-OS-000433-GPOS-00193, SRG-OS-000095-GPOS-00049 SI-16
xccdf_org.ssgproject.content_rule_grub2_slub_debug_argument medium Enable SLUB/SLAB allocator poisoning Poisoning writes an arbitrary value to freed objects, so any modification or reference to that object after being freed or before being initialized will be detected and prevented. This prevents many types of use-after-free vulnerabilities at little performance cost. Also prevents leak of data and detection of corrupted memory. To enable poisoning of SLUB/SLAB objects, add the argument slub_debug=None to the default GRUB 2 command line for the Linux operating system. To ensure that slub_debug=None is added as a kernel command line argument to newly installed kernels, add slub_debug=None to the default Grub2 command line for Linux operating systems. Modify the line within /etc/default/grub as shown below: 
GRUB_CMDLINE_LINUX="... slub_debug=None ..."
Run the following command to update command line for already installed kernels:
# grubby --update-kernel=ALL --args="slub_debug=None"
 
Inspect the form of default GRUB 2 command line for the Linux operating system
in /etc/default/grub. If it includes slub_debug=None,
then the parameter will be configured for newly installed kernels.
First check if the GRUB recovery is enabled:

$ sudo grep 'GRUB_DISABLE_RECOVERY' /etc/default/grub

If this option is set to true, then check that a line is output by the following command:

$ sudo grep 'GRUB_CMDLINE_LINUX_DEFAULT.*slub_debug=None.*' /etc/default/grub

If the recovery is disabled, check the line with

$ sudo grep 'GRUB_CMDLINE_LINUX.*slub_debug=None.*' /etc/default/grub
.Moreover, command line parameters for currently installed kernels should be checked as well.
Run the following command:

$ sudo grubby --info=ALL | grep args | grep -v 'slub_debug=None'

The command should not return any output.
      Is it the case that SLUB/SLAB poisoning is not enabled?
 SRG-OS-000433-GPOS-00192, SRG-OS-000134-GPOS-00068 CM-6(a)
xccdf_org.ssgproject.content_rule_grub2_vsyscall_argument medium Disable vsyscalls Virtual Syscalls provide an opportunity of attack for a user who has control of the return instruction pointer. To disable use of virtual syscalls, add the argument vsyscall=none to the default GRUB 2 command line for the Linux operating system. To ensure that vsyscall=none is added as a kernel command line argument to newly installed kernels, add vsyscall=none to the default Grub2 command line for Linux operating systems. Modify the line within /etc/default/grub as shown below: 
GRUB_CMDLINE_LINUX="... vsyscall=none ..."
Run the following command to update command line for already installed kernels:
# grubby --update-kernel=ALL --args="vsyscall=none"
 
Inspect the form of default GRUB 2 command line for the Linux operating system
in /etc/default/grub. If it includes vsyscall=none,
then the parameter will be configured for newly installed kernels.
First check if the GRUB recovery is enabled:

$ sudo grep 'GRUB_DISABLE_RECOVERY' /etc/default/grub

If this option is set to true, then check that a line is output by the following command:

$ sudo grep 'GRUB_CMDLINE_LINUX_DEFAULT.*vsyscall=none.*' /etc/default/grub

If the recovery is disabled, check the line with

$ sudo grep 'GRUB_CMDLINE_LINUX.*vsyscall=none.*' /etc/default/grub
.Moreover, command line parameters for currently installed kernels should be checked as well.
Run the following command:

$ sudo grubby --info=ALL | grep args | grep -v 'vsyscall=none'

The command should not return any output.
      Is it the case that vsyscalls are enabled?
 SRG-OS-000480-GPOS-00227, SRG-OS-000134-GPOS-00068 CM-7(a)
xccdf_org.ssgproject.content_rule_harden_sshd_ciphers_openssh_conf_crypto_policy high Configure SSH Client to Use FIPS 140 Validated Ciphers: openssh.config Overriding the system crypto policy makes the behavior of the OpenSSH client violate expectations, and makes system configuration more fragmented. By specifying a cipher list with the order of ciphers being in a “strongest to weakest” orientation, the system will automatically attempt to use the strongest cipher for securing SSH connections. Crypto Policies provide a centralized control over crypto algorithms usage of many packages. OpenSSH is supported by system crypto policy, but the OpenSSH configuration may be set up incorrectly. To check that Crypto Policies settings for ciphers are configured correctly, ensure that /etc/crypto-policies/back-ends/openssh.config contains the following line and is not commented out: 
Ciphers aes256-gcm@openssh.com,aes256-ctr,aes128-gcm@openssh.com,aes128-ctr
 
To verify if the OpenSSH client uses defined Cipher suite in the Crypto Policy, run:

$ grep -i ciphers /etc/crypto-policies/back-ends/openssh.config

and verify that the line matches:

Ciphers aes256-gcm@openssh.com,aes256-ctr,aes128-gcm@openssh.com,aes128-ctr

      Is it the case that Crypto Policy for OpenSSH client is not configured correctly?
 SRG-OS-000033-GPOS-00014, SRG-OS-000125-GPOS-00065, SRG-OS-000250-GPOS-00093, SRG-OS-000393-GPOS-00173, SRG-OS-000394-GPOS-00174, SRG-OS-000423-GPOS-00187 AC-17(2)
xccdf_org.ssgproject.content_rule_harden_sshd_ciphers_opensshserver_conf_crypto_policy medium Configure SSH Server to Use FIPS 140-2 Validated Ciphers: opensshserver.config Overriding the system crypto policy makes the behavior of the OpenSSH server violate expectations, and makes system configuration more fragmented. By specifying a cipher list with the order of ciphers being in a “strongest to weakest” orientation, the system will automatically attempt to use the strongest cipher for securing SSH connections. Crypto Policies provide a centralized control over crypto algorithms usage of many packages. OpenSSH is supported by system crypto policy, but the OpenSSH configuration may be set up incorrectly. To check that Crypto Policies settings for ciphers are configured correctly, ensure that /etc/crypto-policies/back-ends/opensshserver.config contains the following text and is not commented out: 
-oCiphers=aes256-gcm@openssh.com,aes256-ctr,aes128-gcm@openssh.com,aes128-ctr
 
To verify if the OpenSSH server uses defined ciphers in the Crypto Policy, run:

$ grep -Po '(-oCiphers=\S+)' /etc/crypto-policies/back-ends/opensshserver.config

and verify that the line matches:

-oCiphers=aes256-gcm@openssh.com,aes256-ctr,aes128-gcm@openssh.com,aes128-ctr

      Is it the case that Crypto Policy for OpenSSH Server is not configured correctly?
 SRG-OS-000125-GPOS-00065, SRG-OS-000250-GPOS-00093 AC-17(2)
xccdf_org.ssgproject.content_rule_harden_sshd_macs_openssh_conf_crypto_policy medium Configure SSH Client to Use FIPS 140-2 Validated MACs: openssh.config Overriding the system crypto policy makes the behavior of the OpenSSH client violate expectations, and makes system configuration more fragmented. Crypto Policies provide a centralized control over crypto algorithms usage of many packages. OpenSSH is supported by system crypto policy, but the OpenSSH configuration may be set up incorrectly. To check that Crypto Policies settings are configured correctly, ensure that /etc/crypto-policies/back-ends/openssh.config contains the following line and is not commented out: MACs hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha2-256,hmac-sha2-512 
To verify if the OpenSSH client uses defined MACs in the Crypto Policy, run:

$ grep -i macs /etc/crypto-policies/back-ends/openssh.config

and verify that the line matches:

MACs hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha2-256,hmac-sha2-512

      Is it the case that Crypto Policy for OpenSSH client is not configured correctly?
 SRG-OS-000125-GPOS-00065, SRG-OS-000250-GPOS-00093 AC-17(2)
xccdf_org.ssgproject.content_rule_harden_sshd_macs_opensshserver_conf_crypto_policy medium Configure SSH Server to Use FIPS 140-2 Validated MACs: opensshserver.config Overriding the system crypto policy makes the behavior of the OpenSSH server violate expectations, and makes system configuration more fragmented. Crypto Policies provide a centralized control over crypto algorithms usage of many packages. OpenSSH is supported by system crypto policy, but the OpenSSH configuration may be set up incorrectly. To check that Crypto Policies settings are configured correctly, ensure that /etc/crypto-policies/back-ends/opensshserver.config contains the following text and is not commented out: -oMACS=hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha2-256,hmac-sha2-512 
To verify if the OpenSSH server uses defined MACs in the Crypto Policy, run:

$ grep -Po '(-oMACs=\S+)' /etc/crypto-policies/back-ends/opensshserver.config

and verify that the line matches:

-oMACS=hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha2-256,hmac-sha2-512

      Is it the case that Crypto Policy for OpenSSH Server is not configured correctly?
 SRG-OS-000125-GPOS-00065, SRG-OS-000250-GPOS-00093 AC-17(2)
xccdf_org.ssgproject.content_rule_install_smartcard_packages medium Install Smart Card Packages For Multifactor Authentication Using an authentication device, such as a CAC or token that is separate from the information system, ensures that even if the information system is compromised, that compromise will not affect credentials stored on the authentication device.

Multifactor solutions that require devices separate from information systems gaining access include, for example, hardware tokens providing time-based or challenge-response authenticators and smart cards or similar secure authentication devices issued by an organization or identity provider.		 Configure the operating system to implement multifactor authentication by installing the required package with the following command: The openssl-pkcs11 package can be installed with the following command: 
$ sudo yum install openssl-pkcs11
 
Check that Oracle Linux 9 has the packages for smart card support installed.

Run the following command to determine if the openssl-pkcs11 package is installed:

$ rpm -q openssl-pkcs11

      Is it the case that smartcard software is not installed?
 SRG-OS-000105-GPOS-00052, SRG-OS-000375-GPOS-00160, SRG-OS-000375-GPOS-00161, SRG-OS-000377-GPOS-00162 CM-6(a)
xccdf_org.ssgproject.content_rule_installed_OS_is_vendor_supported high The Installed Operating System Is Vendor Supported An operating system is considered "supported" if the vendor continues to provide security patches for the product. With an unsupported release, it will not be possible to resolve any security issue discovered in the system software. The installed operating system must be maintained by a vendor. Oracle Linux is supported by Oracle Corporation. As the Oracle Linux vendor, Oracle Corporation is responsible for providing security patches. 
To verify that the installed operating system is supported, run
the following command:


$ grep -i "oracle" /etc/oracle-release



Oracle Linux 9

      Is it the case that the installed operating system is not supported?
 SRG-OS-000480-GPOS-00227 CM-6(a), MA-6, SA-13(a)
xccdf_org.ssgproject.content_rule_kernel_module_atm_disabled medium Disable ATM Support Disabling ATM protects the system against exploitation of any flaws in its implementation. The Asynchronous Transfer Mode (ATM) is a protocol operating on network, data link, and physical layers, based on virtual circuits and virtual paths. To configure the system to prevent the atm kernel module from being loaded, add the following line to the file /etc/modprobe.d/atm.conf: 
install atm /bin/false
This entry will cause a non-zero return value during a atm module installation and additionally convey the meaning of the entry to the user in form of an error message. If you would like to omit a non-zero return value and an error message, you may want to add a different line instead (both /bin/true and /bin/false are allowed by OVAL and will be accepted by the scan): 
install atm /bin/true
To configure the system to prevent the atm from being used, add the following line to file /etc/modprobe.d/atm.conf: 
blacklist atm
 
If the system is configured to prevent the loading of the atm kernel module,
it will contain lines inside any file in /etc/modprobe.d or the deprecated /etc/modprobe.conf.
These lines instruct the module loading system to run another program (such as /bin/false) upon a module install event.

These lines can also instruct the module loading system to ignore the atm kernel module via blacklist keyword.

Run the following command to search for such lines in all files in /etc/modprobe.d and the deprecated /etc/modprobe.conf:

$ grep -r atm /etc/modprobe.conf /etc/modprobe.d

      Is it the case that no line is returned?
 SRG-OS-000095-GPOS-00049, SRG-OS-000480-GPOS-00227 AC-18
xccdf_org.ssgproject.content_rule_kernel_module_bluetooth_disabled medium Disable Bluetooth Kernel Module If Bluetooth functionality must be disabled, preventing the kernel from loading the kernel module provides an additional safeguard against its activation. The kernel's module loading system can be configured to prevent loading of the Bluetooth module. Add the following to the appropriate /etc/modprobe.d configuration file to prevent the loading of the Bluetooth module: 
install bluetooth /bin/true
 
If the system is configured to prevent the loading of the bluetooth kernel module,
it will contain lines inside any file in /etc/modprobe.d or the deprecated /etc/modprobe.conf.
These lines instruct the module loading system to run another program (such as /bin/false) upon a module install event.

These lines can also instruct the module loading system to ignore the bluetooth kernel module via blacklist keyword.

Run the following command to search for such lines in all files in /etc/modprobe.d and the deprecated /etc/modprobe.conf:

$ grep -r bluetooth /etc/modprobe.conf /etc/modprobe.d

      Is it the case that no line is returned?
 SRG-OS-000095-GPOS-00049, SRG-OS-000300-GPOS-00118 AC-18(a), AC-18(3), CM-7(a), CM-7(b), CM-6(a), MP-7
xccdf_org.ssgproject.content_rule_kernel_module_can_disabled medium Disable CAN Support Disabling CAN protects the system against exploitation of any flaws in its implementation. The Controller Area Network (CAN) is a serial communications protocol which was initially developed for automotive and is now also used in marine, industrial, and medical applications. To configure the system to prevent the can kernel module from being loaded, add the following line to the file /etc/modprobe.d/can.conf: 
install can /bin/false
This entry will cause a non-zero return value during a can module installation and additionally convey the meaning of the entry to the user in form of an error message. If you would like to omit a non-zero return value and an error message, you may want to add a different line instead (both /bin/true and /bin/false are allowed by OVAL and will be accepted by the scan): 
install can /bin/true
To configure the system to prevent the can from being used, add the following line to file /etc/modprobe.d/can.conf: 
blacklist can
 
If the system is configured to prevent the loading of the can kernel module,
it will contain lines inside any file in /etc/modprobe.d or the deprecated /etc/modprobe.conf.
These lines instruct the module loading system to run another program (such as /bin/false) upon a module install event.

These lines can also instruct the module loading system to ignore the can kernel module via blacklist keyword.

Run the following command to search for such lines in all files in /etc/modprobe.d and the deprecated /etc/modprobe.conf:

$ grep -r can /etc/modprobe.conf /etc/modprobe.d

      Is it the case that no line is returned?
 SRG-OS-000095-GPOS-00049, SRG-OS-000480-GPOS-00227 AC-18
xccdf_org.ssgproject.content_rule_kernel_module_cramfs_disabled low Disable Mounting of cramfs Removing support for unneeded filesystem types reduces the local attack surface of the server. To configure the system to prevent the cramfs kernel module from being loaded, add the following line to the file /etc/modprobe.d/cramfs.conf: 
install cramfs /bin/false
This entry will cause a non-zero return value during a cramfs module installation and additionally convey the meaning of the entry to the user in form of an error message. If you would like to omit a non-zero return value and an error message, you may want to add a different line instead (both /bin/true and /bin/false are allowed by OVAL and will be accepted by the scan): 
install cramfs /bin/true
To configure the system to prevent the cramfs from being used, add the following line to file /etc/modprobe.d/cramfs.conf: 
blacklist cramfs
This effectively prevents usage of this uncommon filesystem. The cramfs filesystem type is a compressed read-only Linux filesystem embedded in small footprint systems. A cramfs image can be used without having to first decompress the image.		 
If the system is configured to prevent the loading of the cramfs kernel module,
it will contain lines inside any file in /etc/modprobe.d or the deprecated /etc/modprobe.conf.
These lines instruct the module loading system to run another program (such as /bin/false) upon a module install event.

These lines can also instruct the module loading system to ignore the cramfs kernel module via blacklist keyword.

Run the following command to search for such lines in all files in /etc/modprobe.d and the deprecated /etc/modprobe.conf:

$ grep -r cramfs /etc/modprobe.conf /etc/modprobe.d

      Is it the case that no line is returned?
 SRG-OS-000095-GPOS-00049 CM-7(a), CM-7(b), CM-6(a)
xccdf_org.ssgproject.content_rule_kernel_module_firewire-core_disabled low Disable IEEE 1394 (FireWire) Support Disabling FireWire protects the system against exploitation of any flaws in its implementation. The IEEE 1394 (FireWire) is a serial bus standard for high-speed real-time communication. To configure the system to prevent the firewire-core kernel module from being loaded, add the following line to the file /etc/modprobe.d/firewire-core.conf: 
install firewire-core /bin/false
This entry will cause a non-zero return value during a firewire-core module installation and additionally convey the meaning of the entry to the user in form of an error message. If you would like to omit a non-zero return value and an error message, you may want to add a different line instead (both /bin/true and /bin/false are allowed by OVAL and will be accepted by the scan): 
install firewire-core /bin/true
To configure the system to prevent the firewire-core from being used, add the following line to file /etc/modprobe.d/firewire-core.conf: 
blacklist firewire-core
 
If the system is configured to prevent the loading of the firewire-core kernel module,
it will contain lines inside any file in /etc/modprobe.d or the deprecated /etc/modprobe.conf.
These lines instruct the module loading system to run another program (such as /bin/false) upon a module install event.

These lines can also instruct the module loading system to ignore the firewire-core kernel module via blacklist keyword.

Run the following command to search for such lines in all files in /etc/modprobe.d and the deprecated /etc/modprobe.conf:

$ grep -r firewire-core /etc/modprobe.conf /etc/modprobe.d

      Is it the case that no line is returned?
 SRG-OS-000095-GPOS-00049 AC-18
xccdf_org.ssgproject.content_rule_kernel_module_sctp_disabled medium Disable SCTP Support Disabling SCTP protects the system against exploitation of any flaws in its implementation. The Stream Control Transmission Protocol (SCTP) is a transport layer protocol, designed to support the idea of message-oriented communication, with several streams of messages within one connection. To configure the system to prevent the sctp kernel module from being loaded, add the following line to the file /etc/modprobe.d/sctp.conf: 
install sctp /bin/false
This entry will cause a non-zero return value during a sctp module installation and additionally convey the meaning of the entry to the user in form of an error message. If you would like to omit a non-zero return value and an error message, you may want to add a different line instead (both /bin/true and /bin/false are allowed by OVAL and will be accepted by the scan): 
install sctp /bin/true
To configure the system to prevent the sctp from being used, add the following line to file /etc/modprobe.d/sctp.conf: 
blacklist sctp
 
If the system is configured to prevent the loading of the sctp kernel module,
it will contain lines inside any file in /etc/modprobe.d or the deprecated /etc/modprobe.conf.
These lines instruct the module loading system to run another program (such as /bin/false) upon a module install event.

These lines can also instruct the module loading system to ignore the sctp kernel module via blacklist keyword.

Run the following command to search for such lines in all files in /etc/modprobe.d and the deprecated /etc/modprobe.conf:

$ grep -r sctp /etc/modprobe.conf /etc/modprobe.d

      Is it the case that no line is returned?
 SRG-OS-000095-GPOS-00049, SRG-OS-000480-GPOS-00227 CM-7(a), CM-7(b), CM-6(a)
xccdf_org.ssgproject.content_rule_kernel_module_tipc_disabled low Disable TIPC Support Disabling TIPC protects the system against exploitation of any flaws in its implementation. The Transparent Inter-Process Communication (TIPC) protocol is designed to provide communications between nodes in a cluster. To configure the system to prevent the tipc kernel module from being loaded, add the following line to the file /etc/modprobe.d/tipc.conf: 
install tipc /bin/false
This entry will cause a non-zero return value during a tipc module installation and additionally convey the meaning of the entry to the user in form of an error message. If you would like to omit a non-zero return value and an error message, you may want to add a different line instead (both /bin/true and /bin/false are allowed by OVAL and will be accepted by the scan): 
install tipc /bin/true
To configure the system to prevent the tipc from being used, add the following line to file /etc/modprobe.d/tipc.conf: 
blacklist tipc
 
If the system is configured to prevent the loading of the tipc kernel module,
it will contain lines inside any file in /etc/modprobe.d or the deprecated /etc/modprobe.conf.
These lines instruct the module loading system to run another program (such as /bin/false) upon a module install event.

These lines can also instruct the module loading system to ignore the tipc kernel module via blacklist keyword.

Run the following command to search for such lines in all files in /etc/modprobe.d and the deprecated /etc/modprobe.conf:

$ grep -r tipc /etc/modprobe.conf /etc/modprobe.d

      Is it the case that no line is returned?
 SRG-OS-000095-GPOS-00049 CM-7(a), CM-7(b), CM-6(a)
xccdf_org.ssgproject.content_rule_kernel_module_usb-storage_disabled medium Disable Modprobe Loading of USB Storage Driver USB storage devices such as thumb drives can be used to introduce malicious software. To prevent USB storage devices from being used, configure the kernel module loading system to prevent automatic loading of the USB storage driver. To configure the system to prevent the usb-storage kernel module from being loaded, add the following line to the file /etc/modprobe.d/usb-storage.conf: 
install usb-storage /bin/false
This entry will cause a non-zero return value during a usb-storage module installation and additionally convey the meaning of the entry to the user in form of an error message. If you would like to omit a non-zero return value and an error message, you may want to add a different line instead (both /bin/true and /bin/false are allowed by OVAL and will be accepted by the scan): 
install usb-storage /bin/true
To configure the system to prevent the usb-storage from being used, add the following line to file /etc/modprobe.d/usb-storage.conf: 
blacklist usb-storage
This will prevent the modprobe program from loading the usb-storage module, but will not prevent an administrator (or another program) from using the insmod program to load the module manually.		 
If the system is configured to prevent the loading of the usb-storage kernel module,
it will contain lines inside any file in /etc/modprobe.d or the deprecated /etc/modprobe.conf.
These lines instruct the module loading system to run another program (such as /bin/false) upon a module install event.

These lines can also instruct the module loading system to ignore the usb-storage kernel module via blacklist keyword.

Run the following command to search for such lines in all files in /etc/modprobe.d and the deprecated /etc/modprobe.conf:

$ grep -r usb-storage /etc/modprobe.conf /etc/modprobe.d

      Is it the case that no line is returned?
 SRG-OS-000114-GPOS-00059, SRG-OS-000378-GPOS-00163, SRG-OS-000480-GPOS-00227, SRG-APP-000141-CTR-000315 CM-7(a), CM-7(b), CM-6(a), MP-7
xccdf_org.ssgproject.content_rule_libreswan_approved_tunnels medium Verify Any Configured IPSec Tunnel Connections IP tunneling mechanisms can be used to bypass network filtering. Libreswan provides an implementation of IPsec and IKE, which permits the creation of secure tunnels over untrusted networks. As such, IPsec can be used to circumvent certain network requirements such as filtering. Verify that if any IPsec connection (conn) configured in /etc/ipsec.conf and /etc/ipsec.d exists is an approved organizational connection. 
Verify that Oracle Linux 9 does not have unauthorized IP tunnels configured.


# yum list installed libreswan
libreswan.x86-64 3.20-5.el7_4


If "libreswan" is installed, check to see if the "IPsec" service is active with the following command:

# systemctl status ipsec
ipsec.service - Internet Key Exchange (IKE) Protocol Daemon for IPsec
Loaded: loaded (/usr/lib/systemd/system/ipsec.service; disabled)
Active: inactive (dead)


If the "IPsec" service is active, check for configured IPsec connections (conn), perform the following:

grep -rni conn /etc/ipsec.conf /etc/ipsec.d/

Verify any returned results for organizational approval.
      Is it the case that the IPSec tunnels are not approved?
 SRG-OS-000480-GPOS-00227 AC-17(a), MA-4(6), CM-6(a), AC-4, SC-8
xccdf_org.ssgproject.content_rule_mount_option_boot_efi_nosuid medium Add nosuid Option to /boot/efi The presence of SUID and SGID executables should be tightly controlled. Users should not be able to execute SUID or SGID binaries from boot partitions. The nosuid mount option can be used to prevent execution of setuid programs in /boot/efi. The SUID and SGID permissions should not be required on the boot partition. Add the nosuid option to the fourth column of /etc/fstab for the line which controls mounting of /boot/efi. 
Verify the nosuid option is configured for the /boot/efi mount point,
    run the following command:
    
$ sudo mount | grep '\s/boot/efi\s'

    
. . . /boot/efi . . . nosuid . . .


      Is it the case that the "/boot/efi" file system does not have the "nosuid" option set?
 SRG-OS-000480-GPOS-00227 CM-6(b), CM-6.1(iv)
xccdf_org.ssgproject.content_rule_mount_option_boot_nodev medium Add nodev Option to /boot The only legitimate location for device files is the /dev directory located on the root partition. The only exception to this is chroot jails. The nodev mount option can be used to prevent device files from being created in /boot. Legitimate character and block devices should exist only in the /dev directory on the root partition or within chroot jails built for system services. Add the nodev option to the fourth column of /etc/fstab for the line which controls mounting of /boot. 
Verify the nodev option is configured for the /boot mount point,
    run the following command:
    
$ sudo mount | grep '\s/boot\s'

    
. . . /boot . . . nodev . . .


      Is it the case that the "/boot" file system does not have the "nodev" option set?
 SRG-OS-000368-GPOS-00154 CM-7(a), CM-7(b), CM-6(a), AC-6, AC-6(1), MP-7
xccdf_org.ssgproject.content_rule_mount_option_boot_nosuid medium Add nosuid Option to /boot The presence of SUID and SGID executables should be tightly controlled. Users should not be able to execute SUID or SGID binaries from boot partitions. The nosuid mount option can be used to prevent execution of setuid programs in /boot. The SUID and SGID permissions should not be required on the boot partition. Add the nosuid option to the fourth column of /etc/fstab for the line which controls mounting of /boot. 
Verify the nosuid option is configured for the /boot mount point,
    run the following command:
    
$ sudo mount | grep '\s/boot\s'

    
. . . /boot . . . nosuid . . .


      Is it the case that the "/boot" file system does not have the "nosuid" option set?
 SRG-OS-000368-GPOS-00154, SRG-OS-000480-GPOS-00227 CM-7(a), CM-7(b), CM-6(a), AC-6, AC-6(1), MP-7
xccdf_org.ssgproject.content_rule_mount_option_dev_shm_nodev medium Add nodev Option to /dev/shm The only legitimate location for device files is the /dev directory located on the root partition. The only exception to this is chroot jails. The nodev mount option can be used to prevent creation of device files in /dev/shm. Legitimate character and block devices should not exist within temporary directories like /dev/shm. Add the nodev option to the fourth column of /etc/fstab for the line which controls mounting of /dev/shm. 
Verify the nodev option is configured for the /dev/shm mount point,
    run the following command:
    
$ sudo mount | grep '\s/dev/shm\s'

    
. . . /dev/shm . . . nodev . . .


      Is it the case that the "/dev/shm" file system does not have the "nodev" option set?
 SRG-OS-000368-GPOS-00154 CM-7(a), CM-7(b), CM-6(a), AC-6, AC-6(1), MP-7
xccdf_org.ssgproject.content_rule_mount_option_dev_shm_noexec medium Add noexec Option to /dev/shm Allowing users to execute binaries from world-writable directories such as /dev/shm can expose the system to potential compromise. The noexec mount option can be used to prevent binaries from being executed out of /dev/shm. It can be dangerous to allow the execution of binaries from world-writable temporary storage directories such as /dev/shm. Add the noexec option to the fourth column of /etc/fstab for the line which controls mounting of /dev/shm. 
Verify the noexec option is configured for the /dev/shm mount point,
    run the following command:
    
$ sudo mount | grep '\s/dev/shm\s'

    
. . . /dev/shm . . . noexec . . .


      Is it the case that the "/dev/shm" file system does not have the "noexec" option set?
 SRG-OS-000368-GPOS-00154 CM-7(a), CM-7(b), CM-6(a), AC-6, AC-6(1), MP-7
xccdf_org.ssgproject.content_rule_mount_option_dev_shm_nosuid medium Add nosuid Option to /dev/shm The presence of SUID and SGID executables should be tightly controlled. Users should not be able to execute SUID or SGID binaries from temporary storage partitions. The nosuid mount option can be used to prevent execution of setuid programs in /dev/shm. The SUID and SGID permissions should not be required in these world-writable directories. Add the nosuid option to the fourth column of /etc/fstab for the line which controls mounting of /dev/shm. 
Verify the nosuid option is configured for the /dev/shm mount point,
    run the following command:
    
$ sudo mount | grep '\s/dev/shm\s'

    
. . . /dev/shm . . . nosuid . . .


      Is it the case that the "/dev/shm" file system does not have the "nosuid" option set?
 SRG-OS-000368-GPOS-00154 CM-7(a), CM-7(b), CM-6(a), AC-6, AC-6(1), MP-7
xccdf_org.ssgproject.content_rule_mount_option_home_nodev unknown Add nodev Option to /home The only legitimate location for device files is the /dev directory located on the root partition. The only exception to this is chroot jails. The nodev mount option can be used to prevent device files from being created in /home. Legitimate character and block devices should exist only in the /dev directory on the root partition or within chroot jails built for system services. Add the nodev option to the fourth column of /etc/fstab for the line which controls mounting of /home. 
Verify the nodev option is configured for the /home mount point,
    run the following command:
    
$ sudo mount | grep '\s/home\s'

    
. . . /home . . . nodev . . .


      Is it the case that the "/home" file system does not have the "nodev" option set?
 SRG-OS-000368-GPOS-00154
xccdf_org.ssgproject.content_rule_mount_option_home_noexec medium Add noexec Option to /home The /home directory contains data of individual users. Binaries in this directory should not be considered as trusted and users should not be able to execute them. The noexec mount option can be used to prevent binaries from being executed out of /home. Add the noexec option to the fourth column of /etc/fstab for the line which controls mounting of /home. 
Verify the noexec option is configured for the /home mount point,
    run the following command:
    
$ sudo mount | grep '\s/home\s'

    
. . . /home . . . noexec . . .


      Is it the case that the "/home" file system does not have the "noexec" option set?
 SRG-OS-000480-GPOS-00227 CM-6(b)
xccdf_org.ssgproject.content_rule_mount_option_home_nosuid medium Add nosuid Option to /home The presence of SUID and SGID executables should be tightly controlled. Users should not be able to execute SUID or SGID binaries from user home directory partitions. The nosuid mount option can be used to prevent execution of setuid programs in /home. The SUID and SGID permissions should not be required in these user data directories. Add the nosuid option to the fourth column of /etc/fstab for the line which controls mounting of /home. 
Verify the nosuid option is configured for the /home mount point,
    run the following command:
    
$ sudo mount | grep '\s/home\s'

    
. . . /home . . . nosuid . . .


      Is it the case that the "/home" file system does not have the "nosuid" option set?
 SRG-OS-000368-GPOS-00154, SRG-OS-000480-GPOS-00227 CM-7(a), CM-7(b), CM-6(a), AC-6, AC-6(1), MP-7
xccdf_org.ssgproject.content_rule_mount_option_krb_sec_remote_filesystems medium Mount Remote Filesystems with Kerberos Security When an NFS server is configured to use AUTH_SYS a selected userid and groupid are used to handle requests from the remote user. The userid and groupid could mistakenly or maliciously be set incorrectly. The AUTH_GSS method of authentication uses certificates on the server and client systems to more securely authenticate the remote mount request. Add the sec=krb5:krb5i:krb5p option to the fourth column of /etc/fstab for the line which controls mounting of any NFS mounts. 
To verify the sec option is configured for all NFS mounts, run the following command:

$ mount | grep "sec="

All NFS mounts should show the sec=krb5:krb5i:krb5p setting in parentheses.
This is not applicable if NFS is not implemented.
      Is it the case that the setting is not configured, has the 'sys' option added, or does not have all Kerberos options added?
 SRG-OS-000480-GPOS-00227 CM-7(a), CM-7(b), CM-6(a), IA-2, IA-2(8), IA-2(9), AC-17(a)
xccdf_org.ssgproject.content_rule_mount_option_nodev_nonroot_local_partitions medium Add nodev Option to Non-Root Local Partitions The nodev mount option prevents files from being interpreted as character or block devices. The only legitimate location for device files is the /dev directory located on the root partition. The only exception to this is chroot jails, for which it is not advised to set nodev on these filesystems. The nodev mount option prevents files from being interpreted as character or block devices. Legitimate character and block devices should exist only in the /dev directory on the root partition or within chroot jails built for system services. Add the nodev option to the fourth column of /etc/fstab for the line which controls mounting of any non-root local partitions. 
To verify the nodev option is configured for non-root local partitions, run the following command:

$ sudo mount | grep '^/dev\S* on /\S' | grep --invert-match 'nodev'

The output shows local non-root partitions mounted without the nodev option, and there should be no output at all.

      Is it the case that some mounts appear among output lines?
 SRG-OS-000368-GPOS-00154, SRG-OS-000480-GPOS-00227 CM-7(a), CM-7(b), CM-6(a), AC-6, AC-6(1), MP-7
xccdf_org.ssgproject.content_rule_mount_option_nodev_remote_filesystems medium Mount Remote Filesystems with nodev Legitimate device files should only exist in the /dev directory. NFS mounts should not present device files to users. Add the nodev option to the fourth column of /etc/fstab for the line which controls mounting of any NFS mounts. 
To verify the nodev option is configured for all NFS mounts, run
the following command:

$ mount | grep nfs

All NFS mounts should show the nodev setting in parentheses. This
is not applicable if NFS is not implemented.
      Is it the case that the setting does not show?
 SRG-OS-000480-GPOS-00227 CM-6(a), MP-2
xccdf_org.ssgproject.content_rule_mount_option_nodev_removable_partitions medium Add nodev Option to Removable Media Partitions The only legitimate location for device files is the /dev directory located on the root partition. An exception to this is chroot jails, and it is not advised to set nodev on partitions which contain their root filesystems. The nodev mount option prevents files from being interpreted as character or block devices. Legitimate character and block devices should exist only in the /dev directory on the root partition or within chroot jails built for system services. Add the nodev option to the fourth column of /etc/fstab for the line which controls mounting of any removable media partitions. 
Verify file systems that are 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
      Is it the case that a file system found in "/etc/fstab" refers to removable media and it does not have the "nodev" option set?
 SRG-OS-000480-GPOS-00227 CM-7(a), CM-7(b), CM-6(a), AC-6, AC-6(1), MP-7
xccdf_org.ssgproject.content_rule_mount_option_noexec_remote_filesystems medium Mount Remote Filesystems with noexec The noexec mount option causes the system not to execute binary files. This option must be used for mounting any file system not containing approved binary files as they may be incompatible. Executing files from untrusted file systems increases the opportunity for unprivileged users to attain unauthorized administrative access. Add the noexec option to the fourth column of /etc/fstab for the line which controls mounting of any NFS mounts. 
To verify the noexec option is configured for all NFS mounts, run the following command:

$ mount | grep nfs

All NFS mounts should show the noexec setting in parentheses.  This is not applicable if NFS is
not implemented.
      Is it the case that the setting does not show?
 SRG-OS-000480-GPOS-00227 AC-6, AC-6(8), AC-6(10), CM-6(a)
xccdf_org.ssgproject.content_rule_mount_option_noexec_removable_partitions medium Add noexec Option to Removable Media Partitions Allowing users to execute binaries from removable media such as USB keys exposes the system to potential compromise. The noexec mount option prevents the direct execution of binaries on the mounted filesystem. Preventing the direct execution of binaries from removable media (such as a USB key) provides a defense against malicious software that may be present on such untrusted media. Add the noexec option to the fourth column of /etc/fstab for the line which controls mounting of any removable media partitions. 
To verify that binaries cannot be directly executed from removable media, run the following command:

$ grep -v noexec /etc/fstab

The resulting output will show partitions which do not have the noexec flag. Verify all partitions
in the output are not removable media.
      Is it the case that removable media partitions are present?
 SRG-OS-000480-GPOS-00227 CM-7(a), CM-7(b), CM-6(a), AC-6, AC-6(1), MP-7
xccdf_org.ssgproject.content_rule_mount_option_nosuid_remote_filesystems medium Mount Remote Filesystems with nosuid NFS mounts should not present suid binaries to users. Only vendor-supplied suid executables should be installed to their default location on the local filesystem. Add the nosuid option to the fourth column of /etc/fstab for the line which controls mounting of any NFS mounts. 
To verify the nosuid option is configured for all NFS mounts, run
the following command:

$ mount | grep nfs

All NFS mounts should show the nosuid setting in parentheses. This
is not applicable if NFS is not implemented.
      Is it the case that the setting does not show?
 SRG-OS-000480-GPOS-00227 AC-6, AC-6(1), CM6(a)
xccdf_org.ssgproject.content_rule_mount_option_nosuid_removable_partitions medium Add nosuid Option to Removable Media Partitions The presence of SUID and SGID executables should be tightly controlled. Allowing users to introduce SUID or SGID binaries from partitions mounted off of removable media would allow them to introduce their own highly-privileged programs. The nosuid mount option prevents set-user-identifier (SUID) and set-group-identifier (SGID) permissions from taking effect. These permissions allow users to execute binaries with the same permissions as the owner and group of the file respectively. Users should not be allowed to introduce SUID and SGID files into the system via partitions mounted from removable media. Add the nosuid option to the fourth column of /etc/fstab for the line which controls mounting of any removable media partitions. 
Verify file systems that are 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
      Is it the case that file system found in "/etc/fstab" refers to removable media and it does not have the "nosuid" option set?
 SRG-OS-000480-GPOS-00227 CM-7(a), CM-7(b), CM-6(a), AC-6, AC-6(1), MP-7
xccdf_org.ssgproject.content_rule_mount_option_tmp_nodev medium Add nodev Option to /tmp The only legitimate location for device files is the /dev directory located on the root partition. The only exception to this is chroot jails. The nodev mount option can be used to prevent device files from being created in /tmp. Legitimate character and block devices should not exist within temporary directories like /tmp. Add the nodev option to the fourth column of /etc/fstab for the line which controls mounting of /tmp. 
Verify the nodev option is configured for the /tmp mount point,
    run the following command:
    
$ sudo mount | grep '\s/tmp\s'

    
. . . /tmp . . . nodev . . .


      Is it the case that the "/tmp" file system does not have the "nodev" option set?
 SRG-OS-000368-GPOS-00154 CM-7(a), CM-7(b), CM-6(a), AC-6, AC-6(1), MP-7
xccdf_org.ssgproject.content_rule_mount_option_tmp_noexec medium Add noexec Option to /tmp Allowing users to execute binaries from world-writable directories such as /tmp should never be necessary in normal operation and can expose the system to potential compromise. The noexec mount option can be used to prevent binaries from being executed out of /tmp. Add the noexec option to the fourth column of /etc/fstab for the line which controls mounting of /tmp. 
Verify the noexec option is configured for the /tmp mount point,
    run the following command:
    
$ sudo mount | grep '\s/tmp\s'

    
. . . /tmp . . . noexec . . .


      Is it the case that the "/tmp" file system does not have the "noexec" option set?
 SRG-OS-000368-GPOS-00154 CM-7(a), CM-7(b), CM-6(a), AC-6, AC-6(1), MP-7
xccdf_org.ssgproject.content_rule_mount_option_tmp_nosuid medium Add nosuid Option to /tmp The presence of SUID and SGID executables should be tightly controlled. Users should not be able to execute SUID or SGID binaries from temporary storage partitions. The nosuid mount option can be used to prevent execution of setuid programs in /tmp. The SUID and SGID permissions should not be required in these world-writable directories. Add the nosuid option to the fourth column of /etc/fstab for the line which controls mounting of /tmp. 
Verify the nosuid option is configured for the /tmp mount point,
    run the following command:
    
$ sudo mount | grep '\s/tmp\s'

    
. . . /tmp . . . nosuid . . .


      Is it the case that the "/tmp" file system does not have the "nosuid" option set?
 SRG-OS-000368-GPOS-00154 CM-7(a), CM-7(b), CM-6(a), AC-6, AC-6(1), MP-7
xccdf_org.ssgproject.content_rule_mount_option_var_log_audit_nodev medium Add nodev Option to /var/log/audit The only legitimate location for device files is the /dev directory located on the root partition. The only exception to this is chroot jails. The nodev mount option can be used to prevent device files from being created in /var/log/audit. Legitimate character and block devices should exist only in the /dev directory on the root partition or within chroot jails built for system services. Add the nodev option to the fourth column of /etc/fstab for the line which controls mounting of /var/log/audit. 
Verify the nodev option is configured for the /var/log/audit mount point,
    run the following command:
    
$ sudo mount | grep '\s/var/log/audit\s'

    
. . . /var/log/audit . . . nodev . . .


      Is it the case that the "/var/log/audit" file system does not have the "nodev" option set?
 SRG-OS-000368-GPOS-00154 CM-7(a), CM-7(b), CM-6(a), AC-6, AC-6(1), MP-7
xccdf_org.ssgproject.content_rule_mount_option_var_log_audit_noexec medium Add noexec Option to /var/log/audit Allowing users to execute binaries from directories containing audit log files such as /var/log/audit should never be necessary in normal operation and can expose the system to potential compromise. The noexec mount option can be used to prevent binaries from being executed out of /var/log/audit. Add the noexec option to the fourth column of /etc/fstab for the line which controls mounting of /var/log/audit. 
Verify the noexec option is configured for the /var/log/audit mount point,
    run the following command:
    
$ sudo mount | grep '\s/var/log/audit\s'

    
. . . /var/log/audit . . . noexec . . .


      Is it the case that the "/var/log/audit" file system does not have the "noexec" option set?
 SRG-OS-000368-GPOS-00154 CM-7(a), CM-7(b), CM-6(a), AC-6, AC-6(1), MP-7
xccdf_org.ssgproject.content_rule_mount_option_var_log_audit_nosuid medium Add nosuid Option to /var/log/audit The presence of SUID and SGID executables should be tightly controlled. Users should not be able to execute SUID or SGID binaries from partitions designated for audit log files. The nosuid mount option can be used to prevent execution of setuid programs in /var/log/audit. The SUID and SGID permissions should not be required in directories containing audit log files. Add the nosuid option to the fourth column of /etc/fstab for the line which controls mounting of /var/log/audit. 
Verify the nosuid option is configured for the /var/log/audit mount point,
    run the following command:
    
$ sudo mount | grep '\s/var/log/audit\s'

    
. . . /var/log/audit . . . nosuid . . .


      Is it the case that the "/var/log/audit" file system does not have the "nosuid" option set?
 SRG-OS-000368-GPOS-00154 CM-7(a), CM-7(b), CM-6(a), AC-6, AC-6(1), MP-7
xccdf_org.ssgproject.content_rule_mount_option_var_log_nodev medium Add nodev Option to /var/log The only legitimate location for device files is the /dev directory located on the root partition. The only exception to this is chroot jails. The nodev mount option can be used to prevent device files from being created in /var/log. Legitimate character and block devices should exist only in the /dev directory on the root partition or within chroot jails built for system services. Add the nodev option to the fourth column of /etc/fstab for the line which controls mounting of /var/log. 
Verify the nodev option is configured for the /var/log mount point,
    run the following command:
    
$ sudo mount | grep '\s/var/log\s'

    
. . . /var/log . . . nodev . . .


      Is it the case that the "/var/log" file system does not have the "nodev" option set?
 SRG-OS-000368-GPOS-00154 CM-7(a), CM-7(b), CM-6(a), AC-6, AC-6(1), MP-7
xccdf_org.ssgproject.content_rule_mount_option_var_log_noexec medium Add noexec Option to /var/log Allowing users to execute binaries from directories containing log files such as /var/log should never be necessary in normal operation and can expose the system to potential compromise. The noexec mount option can be used to prevent binaries from being executed out of /var/log. Add the noexec option to the fourth column of /etc/fstab for the line which controls mounting of /var/log. 
Verify the noexec option is configured for the /var/log mount point,
    run the following command:
    
$ sudo mount | grep '\s/var/log\s'

    
. . . /var/log . . . noexec . . .


      Is it the case that the "/var/log" file system does not have the "noexec" option set?
 SRG-OS-000368-GPOS-00154 CM-7(a), CM-7(b), CM-6(a), AC-6, AC-6(1), MP-7
xccdf_org.ssgproject.content_rule_mount_option_var_log_nosuid medium Add nosuid Option to /var/log The presence of SUID and SGID executables should be tightly controlled. Users should not be able to execute SUID or SGID binaries from partitions designated for log files. The nosuid mount option can be used to prevent execution of setuid programs in /var/log. The SUID and SGID permissions should not be required in directories containing log files. Add the nosuid option to the fourth column of /etc/fstab for the line which controls mounting of /var/log. 
Verify the nosuid option is configured for the /var/log mount point,
    run the following command:
    
$ sudo mount | grep '\s/var/log\s'

    
. . . /var/log . . . nosuid . . .


      Is it the case that the "/var/log" file system does not have the "nosuid" option set?
 SRG-OS-000368-GPOS-00154 CM-7(a), CM-7(b), CM-6(a), AC-6, AC-6(1), MP-7
xccdf_org.ssgproject.content_rule_mount_option_var_nodev medium Add nodev Option to /var The only legitimate location for device files is the /dev directory located on the root partition. The only exception to this is chroot jails. The nodev mount option can be used to prevent device files from being created in /var. Legitimate character and block devices should exist only in the /dev directory on the root partition or within chroot jails built for system services. Add the nodev option to the fourth column of /etc/fstab for the line which controls mounting of /var. 
Verify the nodev option is configured for the /var mount point,
    run the following command:
    
$ sudo mount | grep '\s/var\s'

    
. . . /var . . . nodev . . .


      Is it the case that the "/var" file system does not have the "nodev" option set?
 SRG-OS-000368-GPOS-00154 CM-7(a), CM-7(b), CM-6(a), AC-6, AC-6(1), MP-7
xccdf_org.ssgproject.content_rule_mount_option_var_tmp_nodev medium Add nodev Option to /var/tmp The only legitimate location for device files is the /dev directory located on the root partition. The only exception to this is chroot jails. The nodev mount option can be used to prevent device files from being created in /var/tmp. Legitimate character and block devices should not exist within temporary directories like /var/tmp. Add the nodev option to the fourth column of /etc/fstab for the line which controls mounting of /var/tmp. 
Verify the nodev option is configured for the /var/tmp mount point,
    run the following command:
    
$ sudo mount | grep '\s/var/tmp\s'

    
. . . /var/tmp . . . nodev . . .


      Is it the case that the "/var/tmp" file system does not have the "nodev" option set?
 SRG-OS-000368-GPOS-00154
xccdf_org.ssgproject.content_rule_mount_option_var_tmp_noexec medium Add noexec Option to /var/tmp Allowing users to execute binaries from world-writable directories such as /var/tmp should never be necessary in normal operation and can expose the system to potential compromise. The noexec mount option can be used to prevent binaries from being executed out of /var/tmp. Add the noexec option to the fourth column of /etc/fstab for the line which controls mounting of /var/tmp. 
Verify the noexec option is configured for the /var/tmp mount point,
    run the following command:
    
$ sudo mount | grep '\s/var/tmp\s'

    
. . . /var/tmp . . . noexec . . .


      Is it the case that the "/var/tmp" file system does not have the "noexec" option set?
 SRG-OS-000368-GPOS-00154
xccdf_org.ssgproject.content_rule_mount_option_var_tmp_nosuid medium Add nosuid Option to /var/tmp The presence of SUID and SGID executables should be tightly controlled. Users should not be able to execute SUID or SGID binaries from temporary storage partitions. The nosuid mount option can be used to prevent execution of setuid programs in /var/tmp. The SUID and SGID permissions should not be required in these world-writable directories. Add the nosuid option to the fourth column of /etc/fstab for the line which controls mounting of /var/tmp. 
Verify the nosuid option is configured for the /var/tmp mount point,
    run the following command:
    
$ sudo mount | grep '\s/var/tmp\s'

    
. . . /var/tmp . . . nosuid . . .


      Is it the case that the "/var/tmp" file system does not have the "nosuid" option set?
 SRG-OS-000368-GPOS-00154
xccdf_org.ssgproject.content_rule_network_configure_name_resolution medium Configure Multiple DNS Servers in /etc/resolv.conf To provide availability for name resolution services, multiple redundant name servers are mandated. A failure in name resolution could lead to the failure of security functions requiring name resolution, which may include time synchronization, centralized authentication, and remote system logging. 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 the DNS entry is found on the host's line of the "/etc/nsswitch.conf" file, then verify the following:
Multiple Domain Name System (DNS) Servers should be configured in /etc/resolv.conf. This provides redundant name resolution services in the event that a domain server crashes. To configure the system to contain as least 2 DNS servers, add a corresponding nameserver ip_address entry in /etc/resolv.conf for each DNS server where ip_address is the IP address of a valid DNS server. For example: 
search example.com
nameserver 192.168.0.1
nameserver 192.168.0.2
 
Verify that DNS servers have been configured properly, perform the following:

$ sudo grep nameserver /etc/resolv.conf

      Is it the case that less than two lines are returned that are not commented out?
 SRG-OS-000480-GPOS-00227 SC-20(a), CM-6(a)
xccdf_org.ssgproject.content_rule_network_sniffer_disabled medium Ensure System is Not Acting as a Network Sniffer Network interfaces in promiscuous mode allow for the capture of all network traffic visible to the system. If unauthorized individuals can access these applications, it may allow them to collect information such as logon IDs, passwords, and key exchanges between systems.

If the system is being used to perform a network troubleshooting function, the use of these tools must be documented with the Information Systems Security Manager (ISSM) and restricted to only authorized personnel.		 The system should not be acting as a network sniffer, which can capture all traffic on the network to which it is connected. Run the following to determine if any interface is running in promiscuous mode: 
$ ip link | grep PROMISC
Promiscuous mode of an interface can be disabled with the following command: 
$ sudo ip link set dev device_name multicast off promisc off
 
Verify that Promiscuous mode of an interface is disabled, run the following command:

$ ip link | grep PROMISC

      Is it the case that any network device is in promiscuous mode?
 SRG-OS-000480-GPOS-00227 CM-7(a), CM-7(b), CM-6(a), CM-7(2), MA-3
xccdf_org.ssgproject.content_rule_networkmanager_dns_mode medium NetworkManager DNS Mode Must Be Must Configured To ensure that DNS resolver settings are respected, a DNS mode in NetworkManager must be configured. The DNS processing mode in NetworkManager describes how DNS is processed on the system. Depending the mode some changes the system's DNS may not be respected. 
Verify that Oracle Linux 9 has a DNS mode configured in Network Manager.

$ NetworkManager --print-config
[main]
dns=
      Is it the case that the dns key under main does not exist or is not set to "none" or "default"?
 SRG-OS-000480-GPOS-00227 CM-6(b)
xccdf_org.ssgproject.content_rule_no_empty_passwords high Prevent Login to Accounts With Empty Password If an account has an empty password, anyone could log in and run commands with the privileges of that account. Accounts with empty passwords should never be used in operational environments. If an account is configured for password authentication but does not have an assigned password, it may be possible to log into the account without authentication. Remove any instances of the nullok in /etc/pam.d/system-auth and /etc/pam.d/password-auth to prevent logins with empty passwords. 
To verify that null passwords cannot be used, run the following command:


$ grep nullok /etc/pam.d/system-auth /etc/pam.d/password-auth


If this produces any output, it may be possible to log into accounts
with empty passwords. Remove any instances of the nullok option to
prevent logins with empty passwords.
      Is it the case that NULL passwords can be used?
 SRG-OS-000480-GPOS-00227 IA-5(1)(a), IA-5(c), CM-6(a)
xccdf_org.ssgproject.content_rule_no_empty_passwords_etc_shadow high Ensure There Are No Accounts With Blank or Null Passwords If an account has an empty password, anyone could log in and run commands with the privileges of that account. Accounts with empty passwords should never be used in operational environments. Check the "/etc/shadow" file for blank passwords with the following command: 
$ sudo awk -F: '!$2 {print $1}' /etc/shadow
If the command returns any results, this is a finding. Configure all accounts on the system to have a password or lock the account with the following commands: Perform a password reset: 
$ sudo passwd [username]
Lock an account: 
$ sudo passwd -l [username]
 
To verify that null passwords cannot be used, run the following command:

$ sudo awk -F: '!$2 {print $1}' /etc/shadow

If this produces any output, it may be possible to log into accounts
with empty passwords.
      Is it the case that Blank or NULL passwords can be used?
 SRG-OS-000480-GPOS-00227 CM-6(b), CM-6.1(iv)
xccdf_org.ssgproject.content_rule_no_files_unowned_by_user medium Ensure All Files Are Owned by a User Unowned files do not directly imply a security problem, but they are generally a sign that something is amiss. They may be caused by an intruder, by incorrect software installation or draft software removal, or by failure to remove all files belonging to a deleted account, or other similar cases. The files should be repaired so they will not cause problems when accounts are created in the future, and the cause should be discovered and addressed. If any files are not owned by a user, then the cause of their lack of ownership should be investigated. Following this, the files should be deleted or assigned to an appropriate user. Locate the mount points related to local devices by the following command: 
$ findmnt -n -l -k -it $(awk '/nodev/ { print $2 }' /proc/filesystems | paste -sd,)
For all mount points listed by the previous command, it is necessary to search for files which do not belong to a valid user using the following command: 
$ sudo find MOUNTPOINT -xdev -nouser 2>/dev/null
 
The following command will locate the mount points related to local devices:

$ findmnt -n -l -k -it $(awk '/nodev/ { print $2 }' /proc/filesystems | paste -sd,)


The following command will show files which do not belong to a valid user:

$ sudo find MOUNTPOINT -xdev -nouser 2>/dev/null


Replace MOUNTPOINT by the mount points listed by the fist command.

No files without a valid user should be located.
      Is it the case that files exist that are not owned by a valid user?
 SRG-OS-000480-GPOS-00227 CM-6(a), AC-6(1)
xccdf_org.ssgproject.content_rule_no_host_based_files high Remove Host-Based Authentication Files The shosts.equiv files are used to configure host-based authentication for the system via SSH. Host-based authentication is not sufficient for preventing unauthorized access to the system, as it does not require interactive identification and authentication of a connection request, or for the use of two-factor authentication. The shosts.equiv file lists remote hosts and users that are trusted by the local system. To remove these files, run the following command to delete them from any location: 
$ sudo rm /[path]/[to]/[file]/shosts.equiv
 
Verify that there are no shosts.equiv files on the system, run the following command:

$ find / -name shosts.equiv

      Is it the case that shosts.equiv files exist?
 SRG-OS-000480-GPOS-00227
xccdf_org.ssgproject.content_rule_no_shelllogin_for_systemaccounts medium Ensure that System Accounts Do Not Run a Shell Upon Login Ensuring shells are not given to system accounts upon login makes it more difficult for attackers to make use of system accounts. Some accounts are not associated with a human user of the system, and exist to perform some administrative functions. Should an attacker be able to log into these accounts, they should not be granted access to a shell.

The login shell for each local account is stored in the last field of each line in /etc/passwd. System accounts are those user accounts with a user ID less than 1000. The user ID is stored in the third field. If any system account other than root has a login shell, disable it with the command: 
$ sudo usermod -s /sbin/nologin account
 
To obtain a listing of all users, their UIDs, and their shells, run the command:

$ awk -F: '{print $1 ":" $3 ":" $7}' /etc/passwd

Identify the system accounts from this listing. These will primarily be the accounts with UID
numbers less than 1000, other than root.
      Is it the case that any system account other than root has a login shell?
 SRG-OS-000480-GPOS-00227 AC-6, CM-6(a), CM-6(b), CM-6.1(iv)
xccdf_org.ssgproject.content_rule_no_user_host_based_files high Remove User Host-Based Authentication Files The .shosts files are used to configure host-based authentication for individual users or the system via SSH. Host-based authentication is not sufficient for preventing unauthorized access to the system, as it does not require interactive identification and authentication of a connection request, or for the use of two-factor authentication. The ~/.shosts (in each user's home directory) files list remote hosts and users that are trusted by the local system. To remove these files, run the following command to delete them from any location: 
$ sudo find / -name '.shosts' -type f -delete
 
To verify that there are no .shosts files
on the system, run the following command:

$ sudo find / -name '.shosts'

      Is it the case that .shosts files exist?
 SRG-OS-000480-GPOS-00227
xccdf_org.ssgproject.content_rule_only_allow_dod_certs medium Only Allow DoD PKI-established CAs Untrusted Certificate Authorities (CA) can issue certificates, but they may be issued by organizations or individuals that seek to compromise DoD systems or by organizations with insufficient security controls. If the CA used for verifying the certificate is not a DoD-approved CA, trust of this CA has not been established. The DoD will only accept PKI-certificates obtained from a DoD-approved internal or external certificate authority. Reliance on CAs for the establishment of secure sessions includes, for example, the use of SSL/TLS certificates. The operating system must only allow the use of DoD PKI-established certificate authorities for verification of the establishment of protected sessions. 
None
      Is it the case that None?
 SRG-OS-000403-GPOS-00182
xccdf_org.ssgproject.content_rule_package_aide_installed medium Install AIDE The AIDE package must be installed if it is to be available for integrity checking. The aide package can be installed with the following command: 
$ sudo yum install aide
 
Run the following command to determine if the aide package is installed: 
$ rpm -q aide

      Is it the case that the package is not installed?
 SRG-OS-000445-GPOS-00199 CM-6(a)
xccdf_org.ssgproject.content_rule_package_audispd-plugins_installed medium Install audispd-plugins Package audispd-plugins provides plugins for the real-time interface to the audit subsystem, audispd. These plugins can do things like relay events to remote machines or analyze events for suspicious behavior. The audispd-plugins package can be installed with the following command: 
$ sudo yum install audispd-plugins
 
Run the following command to determine if the audispd-plugins package is installed: 
$ rpm -q audispd-plugins

      Is it the case that the package is not installed?
 SRG-OS-000342-GPOS-00133
xccdf_org.ssgproject.content_rule_package_audit_installed medium Ensure the audit Subsystem is Installed The auditd service is an access monitoring and accounting daemon, watching system calls to audit any access, in comparison with potential local access control policy such as SELinux policy. The audit package should be installed. 
Run the following command to determine if the audit package is installed: 
$ rpm -q audit

      Is it the case that the audit package is not installed?
 SRG-OS-000062-GPOS-00031, SRG-OS-000037-GPOS-00015, SRG-OS-000038-GPOS-00016, SRG-OS-000039-GPOS-00017, SRG-OS-000040-GPOS-00018, SRG-OS-000041-GPOS-00019, SRG-OS-000042-GPOS-00021, SRG-OS-000051-GPOS-00024, SRG-OS-000054-GPOS-00025, SRG-OS-000122-GPOS-00063, SRG-OS-000254-GPOS-00095, SRG-OS-000255-GPOS-00096, SRG-OS-000337-GPOS-00129, SRG-OS-000348-GPOS-00136, SRG-OS-000349-GPOS-00137, SRG-OS-000350-GPOS-00138, SRG-OS-000351-GPOS-00139, SRG-OS-000352-GPOS-00140, SRG-OS-000353-GPOS-00141, SRG-OS-000354-GPOS-00142, SRG-OS-000358-GPOS-00145, SRG-OS-000365-GPOS-00152, SRG-OS-000392-GPOS-00172, SRG-OS-000475-GPOS-00220 AC-7(a), AU-7(1), AU-7(2), AU-14, AU-12(2), AU-2(a), CM-6(a)
xccdf_org.ssgproject.content_rule_package_chrony_installed medium The Chrony package is installed Time synchronization is important to support time sensitive security mechanisms like Kerberos and also ensures log files have consistent time records across the enterprise, which aids in forensic investigations. System time should be synchronized between all systems in an environment. This is typically done by establishing an authoritative time server or set of servers and having all systems synchronize their clocks to them. The chrony package can be installed with the following command: 
$ sudo yum install chrony
 
Run the following command to determine if the chrony package is installed: 
$ rpm -q chrony

      Is it the case that the package is not installed?
 SRG-OS-000355-GPOS-00143
xccdf_org.ssgproject.content_rule_package_crypto-policies_installed medium Install crypto-policies package Centralized cryptographic policies simplify applying secure ciphers across an operating system and the applications that run on that operating system. Use of weak or untested encryption algorithms undermines the purposes of utilizing encryption to protect data. The crypto-policies package can be installed with the following command: 
$ sudo yum install crypto-policies
 
Run the following command to determine if the crypto-policies package is installed: 
$ rpm -q crypto-policies

      Is it the case that the package is not installed?
 SRG-OS-000396-GPOS-00176, SRG-OS-000393-GPOS-00173, SRG-OS-000394-GPOS-00174
xccdf_org.ssgproject.content_rule_package_fapolicyd_installed medium Install fapolicyd Package fapolicyd (File Access Policy Daemon) implements application whitelisting to decide file access rights. The fapolicyd package can be installed with the following command: 
$ sudo yum install fapolicyd
 
Run the following command to determine if the fapolicyd package is installed: 
$ rpm -q fapolicyd

      Is it the case that the fapolicyd package is not installed?
 SRG-OS-000370-GPOS-00155, SRG-OS-000368-GPOS-00154, SRG-OS-000480-GPOS-00230 CM-6(a), SI-4(22)
xccdf_org.ssgproject.content_rule_package_firewalld_installed medium Install firewalld Package "Firewalld" provides an easy and effective way to block/limit remote access to the system via ports, services, and protocols. Remote access services, such as those providing remote access to network devices and information systems, which lack automated control capabilities, increase risk and make remote user access management difficult at best. Remote access is access to nonpublic information systems by an authorized user (or an information system) communicating through an external, non-organization-controlled network. Remote access methods include, for example, dial-up, broadband, and wireless. Oracle Linux 9 functionality (e.g., SSH) must be capable of taking enforcement action if the audit reveals unauthorized activity. Automated control of remote access sessions allows organizations to ensure ongoing compliance with remote access policies by enforcing connection rules of remote access applications on a variety of information system components (e.g., servers, workstations, notebook computers, smartphones, and tablets)." The firewalld package can be installed with the following command: 
$ sudo yum install firewalld
 
Run the following command to determine if the firewalld package is installed: 
$ rpm -q firewalld

      Is it the case that the package is not installed?
 SRG-OS-000096-GPOS-00050, SRG-OS-000297-GPOS-00115, SRG-OS-000298-GPOS-00116, SRG-OS-000480-GPOS-00227, SRG-OS-000480-GPOS-00232 CM-6(a)
xccdf_org.ssgproject.content_rule_package_gnutls-utils_installed medium Ensure gnutls-utils is installed GnuTLS is a secure communications library implementing the SSL, TLS and DTLS protocols and technologies around them. It provides a simple C language application programming interface (API) to access the secure communications protocols as well as APIs to parse and write X.509, PKCS #12, OpenPGP and other required structures. This package contains command line TLS client and server and certificate manipulation tools. The gnutls-utils package can be installed with the following command: 
$ sudo yum install gnutls-utils
 
Run the following command to determine if the gnutls-utils package is installed: 
$ rpm -q gnutls-utils

      Is it the case that the package is not installed?
 SRG-OS-000480-GPOS-00227
xccdf_org.ssgproject.content_rule_package_gssproxy_removed medium Uninstall gssproxy Package gssproxy is a proxy for GSS API credential handling. Kerberos relies on some key derivation functions that may not be compatible with some site policies such as FIPS 140. The gssproxy package can be removed with the following command: 
$ sudo yum erase gssproxy
 
Run the following command to determine if the gssproxy package is installed:

$ rpm -q gssproxy

      Is it the case that the package is installed?
 SRG-OS-000095-GPOS-00049, SRG-OS-000480-GPOS-00227
xccdf_org.ssgproject.content_rule_package_iprutils_removed medium Uninstall iprutils Package iprutils provides a suite of utlilities to manage and configure SCSI devices supported by the ipr SCSI storage device driver. The iprutils package can be removed with the following command: 
$ sudo yum erase iprutils
 
Run the following command to determine if the iprutils package is installed:

$ rpm -q iprutils

      Is it the case that the package is installed?
 SRG-OS-000095-GPOS-00049, SRG-OS-000480-GPOS-00227
xccdf_org.ssgproject.content_rule_package_libreswan_installed medium Install libreswan Package Providing the ability for remote users or systems to initiate a secure VPN connection protects information when it is transmitted over a wide area network. The libreswan package provides an implementation of IPsec and IKE, which permits the creation of secure tunnels over untrusted networks. The libreswan package can be installed with the following command: 
$ sudo yum install libreswan
 
Run the following command to determine if the libreswan package is installed: 
$ rpm -q libreswan

      Is it the case that the package is not installed?
 SRG-OS-000480-GPOS-00227, SRG-OS-000120-GPOS-00061 CM-6(a)
xccdf_org.ssgproject.content_rule_package_nfs-utils_removed low Uninstall nfs-utils Package nfs-utils provides a daemon for the kernel NFS server and related tools. This package also contains the showmount program. showmount queries the mount daemon on a remote host for information about the Network File System (NFS) server on the remote host. For example, showmount can display the clients which are mounted on that host. The nfs-utils package can be removed with the following command: 
$ sudo yum erase nfs-utils
 
Run the following command to determine if the nfs-utils package is installed:

$ rpm -q nfs-utils

      Is it the case that the package is installed?
 SRG-OS-000095-GPOS-00049
xccdf_org.ssgproject.content_rule_package_nss-tools_installed medium Ensure nss-tools is installed Network Security Services (NSS) is a set of libraries designed to support cross-platform development of security-enabled client and server applications. Install the nss-tools package to install command-line tools to manipulate the NSS certificate and key database. The nss-tools package can be installed with the following command: 
$ sudo yum install nss-tools
 
Run the following command to determine if the nss-tools package is installed: 
$ rpm -q nss-tools

      Is it the case that the package is not installed?
 SRG-OS-000480-GPOS-00227
xccdf_org.ssgproject.content_rule_package_opensc_installed medium Install the opensc Package For Multifactor Authentication Using an authentication device, such as a CAC or token that is separate from the information system, ensures that even if the information system is compromised, that compromise will not affect credentials stored on the authentication device.

Multifactor solutions that require devices separate from information systems gaining access include, for example, hardware tokens providing time-based or challenge-response authenticators and smart cards or similar secure authentication devices issued by an organization or identity provider.		 The opensc package can be installed with the following command: 
$ sudo yum install opensc
 
Run the following command to determine if the opensc package is installed: 
$ rpm -q opensc

      Is it the case that the package is not installed?
 SRG-OS-000375-GPOS-00160, SRG-OS-000376-GPOS-00161 CM-6(a)
xccdf_org.ssgproject.content_rule_package_openssh-clients_installed medium Install OpenSSH client software This package includes utilities to make encrypted connections and transfer files securely to SSH servers. The openssh-clients package can be installed with the following command: 
$ sudo yum install openssh-clients
 
Run the following command to determine if the openssh-clients package is installed: 
$ rpm -q openssh-clients

      Is it the case that the package is not installed?
 SRG-OS-000480-GPOS-00227
xccdf_org.ssgproject.content_rule_package_openssh-server_installed medium Install the OpenSSH Server Package Without protection of the transmitted information, confidentiality, and integrity may be compromised because unprotected communications can be intercepted and either read or altered. The openssh-server package should be installed. The openssh-server package can be installed with the following command: 
$ sudo yum install openssh-server
 
Run the following command to determine if the openssh-server package is installed: 
$ rpm -q openssh-server

      Is it the case that the package is not installed?
 SRG-OS-000423-GPOS-00187, SRG-OS-000424-GPOS-00188, SRG-OS-000425-GPOS-00189, SRG-OS-000426-GPOS-00190 CM-6(a)
xccdf_org.ssgproject.content_rule_package_pcsc-lite_installed medium Install the pcsc-lite package The pcsc-lite package must be installed if it is to be available for multifactor authentication using smartcards. The pcsc-lite package can be installed with the following command: 
$ sudo yum install pcsc-lite
 
Run the following command to determine if the pcsc-lite package is installed: 
$ rpm -q pcsc-lite

      Is it the case that the package is not installed?
 SRG-OS-000375-GPOS-00160 CM-6(a)
xccdf_org.ssgproject.content_rule_package_policycoreutils-python-utils_installed medium Install policycoreutils-python-utils package This package is required to operate and manage an SELinux environment and its policies. It provides utilities such as semanage, audit2allow, audit2why, chcat and sandbox. The policycoreutils-python-utils package can be installed with the following command: 
$ sudo yum install policycoreutils-python-utils
 
Run the following command to determine if the policycoreutils-python-utils package is installed: 
$ rpm -q policycoreutils-python-utils

      Is it the case that the package is not installed?
 SRG-OS-000480-GPOS-00227
xccdf_org.ssgproject.content_rule_package_policycoreutils_installed low Install policycoreutils Package Security-enhanced Linux is a feature of the Linux kernel and a number of utilities with enhanced security functionality designed to add mandatory access controls to Linux. The Security-enhanced Linux kernel contains new architectural components originally developed to improve security of the Flask operating system. These architectural components provide general support for the enforcement of many kinds of mandatory access control policies, including those based on the concepts of Type Enforcement, Role-based Access Control, and Multi-level Security. policycoreutils contains the policy core utilities that are required for basic operation of an SELinux-enabled system. These utilities include load_policy to load SELinux policies, setfiles to label filesystems, newrole to switch roles, and so on. The policycoreutils package can be installed with the following command: 
$ sudo yum install policycoreutils
 
Run the following command to determine if the policycoreutils package is installed: 
$ rpm -q policycoreutils

      Is it the case that the policycoreutils package is not installed?
 SRG-OS-000480-GPOS-00227, SRG-OS-000134-GPOS-00068
xccdf_org.ssgproject.content_rule_package_quagga_removed low Uninstall quagga Package Routing software is typically used on routers to exchange network topology information with other routers. If routing software is used when not required, system network information may be unnecessarily transmitted across the network.
If there is no need to make the router software available, removing it provides a safeguard against its activation.		 The quagga package can be removed with the following command: 
 $ sudo yum erase quagga
 
Run the following command to determine if the quagga package is installed:

$ rpm -q quagga

      Is it the case that the package is installed?
 SRG-OS-000480-GPOS-00227 CM-7(a), CM-7(b), CM-6(a)
xccdf_org.ssgproject.content_rule_package_rng-tools_installed low Install rng-tools Package rng-tools provides hardware random number generator tools, such as those used in the formation of x509/PKI certificates. The rng-tools package can be installed with the following command: 
$ sudo yum install rng-tools
 
Run the following command to determine if the rng-tools package is installed: 
$ rpm -q rng-tools

      Is it the case that the package is not installed?
 SRG-OS-000480-GPOS-00227
xccdf_org.ssgproject.content_rule_package_rsyslog-gnutls_installed medium Ensure rsyslog-gnutls is installed The rsyslog-gnutls package provides Transport Layer Security (TLS) support for the rsyslog daemon, which enables secure remote logging. TLS protocol support for rsyslog is installed. The rsyslog-gnutls package can be installed with the following command: 
$ sudo yum install rsyslog-gnutls
 
Run the following command to determine if the rsyslog-gnutls package is installed:

$ rpm -q rsyslog-gnutls

      Is it the case that the package is installed?
 SRG-OS-000480-GPOS-00227, SRG-OS-000120-GPOS-00061
xccdf_org.ssgproject.content_rule_package_rsyslog_installed medium Ensure rsyslog is Installed The rsyslog package provides the rsyslog daemon, which provides system logging services. Rsyslog is installed by default. The rsyslog package can be installed with the following command: 
 $ sudo yum install rsyslog
 
Run the following command to determine if the rsyslog package is installed: 
$ rpm -q rsyslog

      Is it the case that the package is not installed?
 SRG-OS-000479-GPOS-00224, SRG-OS-000051-GPOS-00024, SRG-OS-000480-GPOS-00227 CM-6(a)
xccdf_org.ssgproject.content_rule_package_s-nail_installed medium The s-nail Package Is Installed Emails can be used to notify designated personnel about important system events such as failures or warnings. A mail server is required for sending emails. The s-nail package can be installed with the following command: 
$ sudo yum install s-nail
 
Run the following command to determine if the s-nail package is installed: 
$ rpm -q s-nail

      Is it the case that the package is not installed?
 SRG-OS-000363-GPOS-00150 CM-3(5)
xccdf_org.ssgproject.content_rule_package_sendmail_removed medium Uninstall Sendmail Package The sendmail software was not developed with security in mind and its design prevents it from being effectively contained by SELinux. Postfix should be used instead. Sendmail is not the default mail transfer agent and is not installed by default. The sendmail package can be removed with the following command: 
$ sudo yum erase sendmail
 
Run the following command to determine if the sendmail package is installed:

$ rpm -q sendmail

      Is it the case that the package is installed?
 SRG-OS-000480-GPOS-00227, SRG-OS-000095-GPOS-00049 CM-7(a), CM-7(b), CM-6(a)
xccdf_org.ssgproject.content_rule_package_sssd_installed medium Install the SSSD Package The sssd package should be installed. The sssd package can be installed with the following command: 
$ sudo yum install sssd
 
Run the following command to determine if the sssd package is installed: 
$ rpm -q sssd

      Is it the case that the package is not installed?
 SRG-OS-000375-GPOS-00160 CM-6(a)
xccdf_org.ssgproject.content_rule_package_sudo_installed medium Install sudo Package sudo is a program designed to allow a system administrator to give limited root privileges to users and log root activity. The basic philosophy is to give as few privileges as possible but still allow system users to get their work done. The sudo package can be installed with the following command: 
$ sudo yum install sudo
 
Run the following command to determine if the sudo package is installed: 
$ rpm -q sudo

      Is it the case that the package is not installed?
 SRG-OS-000324-GPOS-00125 CM-6(a)
xccdf_org.ssgproject.content_rule_package_telnet-server_removed high Uninstall telnet-server Package It is detrimental for operating systems to provide, or install by default, functionality exceeding requirements or mission objectives. These unnecessary capabilities are often overlooked and therefore may remain insecure. They increase the risk to the platform by providing additional attack vectors.
The telnet service provides an unencrypted remote access service which does not provide for the confidentiality and integrity of user passwords or the remote session. If a privileged user were to login using this service, the privileged user password could be compromised.
Removing the telnet-server package decreases the risk of the telnet service's accidental (or intentional) activation.		 The telnet-server package can be removed with the following command: 
$ sudo yum erase telnet-server
 
Run the following command to determine if the telnet-server package is installed:

$ rpm -q telnet-server

      Is it the case that the package is installed?
 SRG-OS-000095-GPOS-00049 CM-7(a), CM-7(b), CM-6(a)
xccdf_org.ssgproject.content_rule_package_tftp-server_removed high Uninstall tftp-server Package Removing the tftp-server package decreases the risk of the accidental (or intentional) activation of tftp services.

If TFTP is required for operational support (such as transmission of router configurations), its use must be documented with the Information Systems Security Manager (ISSM), restricted to only authorized personnel, and have access control rules established.		 The tftp-server package can be removed with the following command: 
 $ sudo yum erase tftp-server
 
Run the following command to determine if the tftp-server package is installed:

$ rpm -q tftp-server

      Is it the case that the package is installed?
 SRG-OS-000480-GPOS-00227 CM-7(a), CM-7(b), CM-6(a)
xccdf_org.ssgproject.content_rule_package_tuned_removed medium Uninstall tuned Package tuned contains a daemon that tunes the system settings dynamically. It does so by monitoring the usage of several system components periodically. Based on that information, components will then be put into lower or higher power savings modes to adapt to the current usage. The tuned package can be removed with the following command: 
$ sudo yum erase tuned
 
Run the following command to determine if the tuned package is installed:

$ rpm -q tuned

      Is it the case that the package is installed?
 SRG-OS-000095-GPOS-00049, SRG-OS-000480-GPOS-00227
xccdf_org.ssgproject.content_rule_package_usbguard_installed medium Install usbguard Package usbguard is a software framework that helps to protect against rogue USB devices by implementing basic whitelisting/blacklisting capabilities based on USB device attributes. The usbguard package can be installed with the following command: 
$ sudo yum install usbguard
 
Run the following command to determine if the usbguard package is installed: 
$ rpm -q usbguard

      Is it the case that the package is not installed?
 SRG-OS-000378-GPOS-00163, SRG-APP-000141-CTR-000315 CM-8(3), IA-3
xccdf_org.ssgproject.content_rule_package_vsftpd_removed high Uninstall vsftpd Package Removing the vsftpd package decreases the risk of its accidental activation. The vsftpd package can be removed with the following command: 
 $ sudo yum erase vsftpd
 
Run the following command to determine if the vsftpd package is installed:

$ rpm -q vsftpd

      Is it the case that the package is installed?
 SRG-OS-000074-GPOS-00042, SRG-OS-000095-GPOS-00049, SRG-OS-000480-GPOS-00227 CM-7(a), CM-7(b), CM-6(a), IA-5(1)(c), IA-5(1).1(v), CM-7, CM-7.1(ii)
xccdf_org.ssgproject.content_rule_partition_for_home low Ensure /home Located On Separate Partition Ensuring that /home is mounted on its own partition enables the setting of more restrictive mount options, and also helps ensure that users cannot trivially fill partitions used for log or audit data storage. If user home directories will be stored locally, create a separate partition for /home at installation time (or migrate it later using LVM). If /home will be mounted from another system such as an NFS server, then creating a separate partition is not necessary at installation time, and the mountpoint can instead be configured later. 
Verify that a separate file system/partition has been created for /home with the following command:


$ mountpoint /home


      Is it the case that "/home is not a mountpoint" is returned?
 SRG-OS-000480-GPOS-00227 CM-6(a), SC-5(2)
xccdf_org.ssgproject.content_rule_partition_for_tmp low Ensure /tmp Located On Separate Partition The /tmp partition is used as temporary storage by many programs. Placing /tmp in its own partition enables the setting of more restrictive mount options, which can help protect programs which use it. The /tmp directory is a world-writable directory used for temporary file storage. Ensure it has its own partition or logical volume at installation time, or migrate it using LVM. 
Verify that a separate file system/partition has been created for /tmp with the following command:


$ mountpoint /tmp


      Is it the case that "/tmp is not a mountpoint" is returned?
 SRG-OS-000480-GPOS-00227 CM-6(a), SC-5(2)
xccdf_org.ssgproject.content_rule_partition_for_var low Ensure /var Located On Separate Partition Ensuring that /var is mounted on its own partition enables the setting of more restrictive mount options. This helps protect system services such as daemons or other programs which use it. It is not uncommon for the /var directory to contain world-writable directories installed by other software packages. The /var directory is used by daemons and other system services to store frequently-changing data. Ensure that /var has its own partition or logical volume at installation time, or migrate it using LVM. 
Verify that a separate file system/partition has been created for /var with the following command:


$ mountpoint /var


      Is it the case that "/var is not a mountpoint" is returned?
 SRG-OS-000480-GPOS-00227 CM-6(a), SC-5(2)
xccdf_org.ssgproject.content_rule_partition_for_var_log low Ensure /var/log Located On Separate Partition Placing /var/log in its own partition enables better separation between log files and other files in /var/. System logs are stored in the /var/log directory. Ensure that /var/log has its own partition or logical volume at installation time, or migrate it using LVM. 
Verify that a separate file system/partition has been created for /var/log with the following command:


$ mountpoint /var/log


      Is it the case that "/var/log is not a mountpoint" is returned?
 SRG-OS-000480-GPOS-00227 CM-6(a), AU-4, SC-5(2)
xccdf_org.ssgproject.content_rule_partition_for_var_log_audit low Ensure /var/log/audit Located On Separate Partition Placing /var/log/audit in its own partition enables better separation between audit files and other files, and helps ensure that auditing cannot be halted due to the partition running out of space. Audit logs are stored in the /var/log/audit directory. Ensure that /var/log/audit has its own partition or logical volume at installation time, or migrate it using LVM. Make absolutely certain that it is large enough to store all audit logs that will be created by the auditing daemon. 
Verify that a separate file system/partition has been created for /var/log/audit with the following command:


$ mountpoint /var/log/audit


      Is it the case that "/var/log/audit is not a mountpoint" is returned?
 SRG-OS-000341-GPOS-00132, SRG-OS-000480-GPOS-00227, SRG-APP-000357-CTR-000800 CM-6(a), AU-4, SC-5(2)
xccdf_org.ssgproject.content_rule_partition_for_var_tmp medium Ensure /var/tmp Located On Separate Partition The /var/tmp partition is used as temporary storage by many programs. Placing /var/tmp in its own partition enables the setting of more restrictive mount options, which can help protect programs which use it. The /var/tmp directory is a world-writable directory used for temporary file storage. Ensure it has its own partition or logical volume at installation time, or migrate it using LVM. 
Verify that a separate file system/partition has been created for /var/tmp with the following command:


$ mountpoint /var/tmp


      Is it the case that "/var/tmp is not a mountpoint" is returned?
 SRG-OS-000480-GPOS-00227
xccdf_org.ssgproject.content_rule_postfix_client_configure_mail_alias medium Configure System to Forward All Mail For The Root Account A number of system services utilize email messages sent to the root user to notify system administrators of active or impending issues. These messages must be forwarded to at least one monitored email address. Make sure that mails delivered to root user are forwarded to a monitored email address. Make sure that the address None is a valid email address reachable from the system in question. Use the following command to configure the alias: 
$ sudo echo "root: None" >> /etc/aliases
$ sudo newaliases
 
Find the list of alias maps used by the Postfix mail server:

$ sudo postconf alias_maps

Query the Postfix alias maps for an alias for the root user:

$ sudo postmap -q root hash:/etc/aliases

The output should return an alias.
      Is it the case that the alias is not set?
 SRG-OS-000046-GPOS-00022 CM-6(a)
xccdf_org.ssgproject.content_rule_postfix_client_configure_mail_alias_postmaster medium Configure System to Forward All Mail From Postmaster to The Root Account It is critical for the appropriate personnel to be aware if a system is at risk of failing to process audit logs as required. Without this notification, the security personnel may be unaware of an impending failure of the audit capability, and system operation may be adversely affected. Audit processing failures include software/hardware errors, failures in the audit capturing mechanisms, and audit storage capacity being reached or exceeded. Verify the administrators are notified in the event of an audit processing failure. Check that the "/etc/aliases" file has a defined value for "root". 
$ sudo grep "postmaster:\s*root$" /etc/aliases

postmaster: root
 
Find the list of alias maps used by the Postfix mail server:

$ sudo postconf alias_maps

Query the Postfix alias maps for an alias for the postmaster user:

$ sudo postmap -q postmaster hash:/etc/aliases

The output should return root.
      Is it the case that the alias is not set or is not root?
 SRG-OS-000046-GPOS-00022 AU-5(a), AU-5.1(ii)
xccdf_org.ssgproject.content_rule_postfix_prevent_unrestricted_relay medium Prevent Unrestricted Mail Relaying If unrestricted mail relaying is permitted, unauthorized senders could use this host as a mail relay for the purpose of sending spam or other unauthorized activity. Modify the 
/etc/postfix/main.cf
file to restrict client connections to the local network with the following command: 
$ sudo postconf -e 'smtpd_client_restrictions = permit_mynetworks,reject'
 
Verify that Oracle Linux 9 is configured to prevent unrestricted mail relaying,
run the following command:

$ sudo postconf -n smtpd_client_restrictions

      Is it the case that the "smtpd_client_restrictions" parameter contains any entries other than "permit_mynetworks" and "reject"?
 SRG-OS-000480-GPOS-00227
xccdf_org.ssgproject.content_rule_require_emergency_target_auth medium Require Authentication for Emergency Systemd Target This prevents attackers with physical access from trivially bypassing security on the machine and gaining root access. Such accesses are further prevented by configuring the bootloader password. Emergency mode is intended as a system recovery method, providing a single user root access to the system during a failed boot sequence.

By default, Emergency mode is protected by requiring a password and is set in /usr/lib/systemd/system/emergency.service.		 
To check if authentication is required for emergency mode, run the following command:

$ grep sulogin /usr/lib/systemd/system/emergency.service

The output should be similar to the following, and the line must begin with
ExecStart and /usr/lib/systemd/systemd-sulogin-shell.
    
ExecStart=-/usr/lib/systemd/systemd-sulogin-shell emergency


Then, check if the emergency target requires the emergency service:
Run the following command:

$ sudo grep Requires /usr/lib/systemd/system/emergency.target

The output should be the following:

Requires=emergency.service


Then, check if there is no custom emergency target configured in systemd configuration.
Run the following command:

$ sudo grep -r emergency.target /etc/systemd/system/

The output should be empty.

Then, check if there is no custom emergency service configured in systemd configuration.
Run the following command:

$ sudo grep -r emergency.service /etc/systemd/system/

The output should be empty.
      Is it the case that the output is different?
 SRG-OS-000080-GPOS-00048 IA-2, AC-3, CM-6(a)
xccdf_org.ssgproject.content_rule_require_singleuser_auth medium Require Authentication for Single User Mode This prevents attackers with physical access from trivially bypassing security on the machine and gaining root access. Such accesses are further prevented by configuring the bootloader password. Single-user mode is intended as a system recovery method, providing a single user root access to the system by providing a boot option at startup.

By default, single-user mode is protected by requiring a password and is set in /usr/lib/systemd/system/rescue.service.		 
To check if authentication is required for single-user mode, run the following command:

$ grep sulogin /usr/lib/systemd/system/rescue.service

The output should be similar to the following, and the line must begin with
ExecStart and /usr/lib/systemd/systemd-sulogin-shell.
    
ExecStart=-/usr/lib/systemd/systemd-sulogin-shell rescue


In case the output does not match, check if the ExecStart directive is not overridden:

grep ExecStart /etc/systemd/system/rescue.service.d/*.conf

The output should contain two lines:

ExecStart=
ExecStart=-/usr/lib/systemd/systemd-sulogin-shell rescue




Then, verify that the rescue service is in the runlevel1.target.
Run the following command:

$ sudo grep "^Requires=.*rescue\.service" /usr/lib/systemd/system/runlevel1.target

The output should be the following:

Requires=sysinit.target rescue.service


Then, check if there is no custom runlevel1 target configured in systemd configuration.
Run the following command:

$ sudo grep -r "^runlevel1.target$" /etc/systemd/system

There should be no output.

Then, check if there is no custom rescue service configured in systemd configuration.
Run the following command:

$ sudo grep -r "^rescue.service$" /etc/systemd/system

There should be no output.
      Is it the case that the output is different?
 SRG-OS-000080-GPOS-00048 IA-2, AC-3, CM-6(a)
xccdf_org.ssgproject.content_rule_root_permissions_syslibrary_files medium Verify the system-wide library files in directories "/lib", "/lib64", "/usr/lib/" and "/usr/lib64" are group-owned by root. If the operating system were to allow any user to make changes to software libraries, then those changes might be implemented without undergoing the appropriate testing and approvals that are part of a robust change management process. This requirement applies to operating systems with software libraries that are accessible and configurable, as in the case of interpreted languages. Software libraries also include privileged programs which execute with escalated privileges. Only qualified and authorized individuals must be allowed to obtain access to information system components for purposes of initiating changes, including upgrades and modifications. System-wide library files are stored in the following directories by default: 
/lib
/lib64
/usr/lib
/usr/lib64
All system-wide shared library files should be protected from unauthorised access. If any of these files is not group-owned by root, correct its group-owner with the following command: 
$ sudo chgrp root FILE
 
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 {} \;
      Is it the case that any system wide shared library file is returned and is not group-owned by root?
 SRG-OS-000259-GPOS-00100 CM-5(6), CM-5(6).1
xccdf_org.ssgproject.content_rule_rpm_verify_crypto_policies high Verify crypto-policies with RPM The crypto-policies package defines the cryptography policies for the system. If the files are changed from those shipped with the operating system, It may be possible for Oracle Linux 9 to use cryptographic functions that are not FIPS 140-3 approved. Without cryptographic integrity protections, system executables and files can be altered by unauthorized users without detection. The RPM package management system can check the hashes of installed software packages, including many that are important to system security. If the file was not expected to change, investigate the cause of the change using audit logs or other means. The package can then be reinstalled to restore the file. Run the following command to determine which package owns the file: 
$ rpm -qf FILENAME
The package can be reinstalled from a yum repository using the command: 
$ sudo yum reinstall crypto-policies
 
Verify that Oracle Linux 9 crypto-policies package has not been modified with the following command:
$ rpm -V crypto-policies
If the command has any output, this is a finding.
      Is it the case that there is output?
 SRG-OS-000478-GPOS-00223, SRG-OS-000396-GPOS-00176
xccdf_org.ssgproject.content_rule_rpm_verify_hashes high Verify File Hashes with RPM The hashes of important files like system executables should match the information given by the RPM database. Executables with erroneous hashes could be a sign of nefarious activity on the system. Without cryptographic integrity protections, system executables and files can be altered by unauthorized users without detection. The RPM package management system can check the hashes of installed software packages, including many that are important to system security. To verify that the cryptographic hash of system files and commands matches vendor values, run the following command to list which files on the system have hashes that differ from what is expected by the RPM database: 
$ rpm -Va --noconfig | grep '^..5'
If the file was not expected to change, investigate the cause of the change using audit logs or other means. The package can then be reinstalled to restore the file. Run the following command to determine which package owns the file: 
$ rpm -qf FILENAME
The package can be reinstalled from a yum repository using the command: 
$ sudo yum reinstall PACKAGENAME
Alternatively, the package can be reinstalled from trusted media using the command: 
$ sudo rpm -Uvh PACKAGENAME
 
The following command will list which files on the system have file hashes different from what
is expected by the RPM database.

$ rpm -Va --noconfig | awk '$1 ~ /..5/'

      Is it the case that there is output?
 SRG-OS-000480-GPOS-00227 CM-6(d), CM-6(c), SI-7, SI-7(1), SI-7(6), AU-9(3)
xccdf_org.ssgproject.content_rule_rsyslog_cron_logging medium Ensure cron Is Logging To Rsyslog Cron logging can be used to trace the successful or unsuccessful execution of cron jobs. It can also be used to spot intrusions into the use of the cron facility by unauthorized and malicious users. Cron logging must be implemented to spot intrusions or trace cron job status. If cron is not logging to rsyslog, it can be implemented by adding the following to the RULES section of /etc/rsyslog.conf: If the legacy syntax is used: 
cron.*                                                  /var/log/cron
If the modern syntax (RainerScript) is used: 
cron.* action(type="omfile" file="/var/log/cron")
 
Verify that cron is logging to rsyslog,
run the following command:

grep -rni "cron\.\*" /etc/rsyslog.*


cron.*                                                  /var/log/cron

or

cron.* action(type="omfile" file="/var/log/cron")

      Is it the case that cron is not logging to rsyslog?
 SRG-OS-000480-GPOS-00227 CM-6(a)
xccdf_org.ssgproject.content_rule_rsyslog_encrypt_offload_actionsendstreamdriverauthmode medium Ensure Rsyslog Authenticates Off-Loaded Audit Records The audit records generated by Rsyslog contain valuable information regarding system configuration, user authentication, and other such information. Audit records should be protected from unauthorized access. Rsyslogd is a system utility providing support for message logging. Support for both internet and UNIX domain sockets enables this utility to support both local and remote logging. Couple this utility with gnutls (which is a secure communications library implementing the SSL, TLS and DTLS protocols), and you have a method to securely encrypt and off-load auditing. When using rsyslogd to off-load logs the remote system must be authenticated. Set the following configuration option in /etc/rsyslog.conf or in a file in /etc/rsyslog.d (using legacy syntax): 
$ActionSendStreamDriverAuthMode x509/name
Alternatively, use the RainerScript syntax: 
action(type="omfwd" Target="some.example.com" StreamDriverAuthMode="x509/name")
 
Verify the operating system authenticates the remote logging server for off-loading audit logs with the following command:


$ sudo grep -i '$ActionSendStreamDriverAuthMode' /etc/rsyslog.conf /etc/rsyslog.d/*.conf

The output should be

$/etc/rsyslog.conf:$ActionSendStreamDriverAuthMode x509/name

      Is it the case that $ActionSendStreamDriverAuthMode in /etc/rsyslog.conf is not set to x509/name?
 SRG-OS-000342-GPOS-00133, SRG-OS-000479-GPOS-00224 AU-4(1)
xccdf_org.ssgproject.content_rule_rsyslog_encrypt_offload_actionsendstreamdrivermode medium Ensure Rsyslog Encrypts Off-Loaded Audit Records The audit records generated by Rsyslog contain valuable information regarding system configuration, user authentication, and other such information. Audit records should be protected from unauthorized access. Rsyslogd is a system utility providing support for message logging. Support for both internet and UNIX domain sockets enables this utility to support both local and remote logging. Couple this utility with gnutls (which is a secure communications library implementing the SSL, TLS and DTLS protocols), and you have a method to securely encrypt and off-load auditing. When using rsyslogd to off-load logs off a encryption system must be used. Set the following configuration option in /etc/rsyslog.conf or in a file in /etc/rsyslog.d (using legacy syntax): 
$ActionSendStreamDriverMode 1
Alternatively, use the RainerScript syntax: 
action(type="omfwd" ... StreamDriverMode="1")
 
Verify the operating system encrypts audit records off-loaded onto a different system
or media from the system being audited with the following commands:


$ sudo grep -i '$ActionSendStreamDriverMode' /etc/rsyslog.conf /etc/rsyslog.d/*.conf


The output should be:


/etc/rsyslog.conf:$ActionSendStreamDriverMode 1

      Is it the case that rsyslogd ActionSendStreamDriverMode is not set to 1?
 SRG-OS-000342-GPOS-00133, SRG-OS-000479-GPOS-00224 AU-4(1)
xccdf_org.ssgproject.content_rule_rsyslog_encrypt_offload_defaultnetstreamdriver medium Ensure Rsyslog Encrypts Off-Loaded Audit Records The audit records generated by Rsyslog contain valuable information regarding system configuration, user authentication, and other such information. Audit records should be protected from unauthorized access. Rsyslogd is a system utility providing support for message logging. Support for both internet and UNIX domain sockets enables this utility to support both local and remote logging. Couple this utility with gnutls (which is a secure communications library implementing the SSL, TLS and DTLS protocols), and you have a method to securely encrypt and off-load auditing. When using rsyslogd to off-load logs off an encryption system must be used. Set the following configuration option in /etc/rsyslog.conf or in a file in /etc/rsyslog.d (using legacy syntax): 
$DefaultNetstreamDriver gtls
Alternatively, use the RainerScript syntax: 
global(DefaultNetstreamDriver="gtls")
 
Verify the operating system encrypts audit records off-loaded onto a different system
or media from the system being audited with the following commands:


$ sudo grep -i '$DefaultNetstreamDriver' /etc/rsyslog.conf /etc/rsyslog.d/*.conf


The output should be:


/etc/rsyslog.conf:$DefaultNetstreamDriver gtls

      Is it the case that rsyslogd DefaultNetstreamDriver not set to gtls?
 SRG-OS-000342-GPOS-00133, SRG-OS-000479-GPOS-00224 AU-4(1)
xccdf_org.ssgproject.content_rule_rsyslog_nolisten medium Ensure rsyslog Does Not Accept Remote Messages Unless Acting As Log Server Any process which receives messages from the network incurs some risk of receiving malicious messages. This risk can be eliminated for rsyslog by configuring it not to listen on the network. The rsyslog daemon should not accept remote messages unless the system acts as a log server. To ensure that it is not listening on the network, ensure any of the following lines are not found in rsyslog configuration files. If using legacy syntax: 
$ModLoad imtcp
$InputTCPServerRun port
$ModLoad imudp
$UDPServerRun port
$ModLoad imrelp
$InputRELPServerRun port
If using RainerScript syntax: 
module(load="imtcp")
module(load="imudp")
input(type="imtcp" port="514")
input(type="imudp" port="514")

Verify that the system is not accepting "rsyslog" messages from other systems unless it is
documented as a log aggregation server.
Display the contents of the rsyslog configuration files:

find /etc -maxdepth 2 -regex '/etc/rsyslog\(\.conf\|\.d\/.*\.conf\)' -exec cat '{}' \;


If any of the below lines are found, ask to see the documentation for the system being used
for log aggregation:

If using legacy syntax:

$ModLoad imtcp
$InputTCPServerRun port
$ModLoad imudp
$UDPServerRun port
$ModLoad imrelp
$InputRELPServerRun port


If using RainerScript syntax:

module(load="imtcp")
module(load="imudp")
input(type="imtcp" port="514")
input(type="imudp" port="514")


      Is it the case that rsyslog accepts remote messages and is not documented as a log aggregation system?
 SRG-OS-000480-GPOS-00227 CM-7(a), CM-7(b), CM-6(a)
xccdf_org.ssgproject.content_rule_rsyslog_remote_access_monitoring medium Ensure remote access methods are monitored in Rsyslog Logging remote access methods can be used to trace the decrease the risks associated with remote user access management. It can also be used to spot cyber attacks and ensure ongoing compliance with organizational policies surrounding the use of remote access methods. Logging of remote access methods must be implemented to help identify cyber attacks and ensure ongoing compliance with remote access policies are being audited and upheld. An examples of a remote access method is the use of the Remote Desktop Protocol (RDP) from an external, non-organization controlled network. The /etc/rsyslog.conf or /etc/rsyslog.d/*.conf file should contain a match for the following selectors: auth.*, authpriv.*, and daemon.*. If not, use the following as an example configuration: auth.*;authpriv.* /var/log/secure daemon.* /var/log/messages 
To verify that remote access methods are logging to rsyslog,
run the following command:


grep -rE '(auth.\*|authpriv.\*|daemon.\*)' /etc/rsyslog.*


The output should contain auth.*, authpriv.*, and daemon.*
pointing to a log file.
      Is it the case that remote access methods are not logging to rsyslog?
 SRG-OS-000032-GPOS-00013 AC-17(1)
xccdf_org.ssgproject.content_rule_rsyslog_remote_loghost medium Ensure Logs Sent To Remote Host A log server (loghost) receives syslog messages from one or more systems. This data can be used as an additional log source in the event a system is compromised and its local logs are suspect. Forwarding log messages to a remote loghost also provides system administrators with a centralized place to view the status of multiple hosts within the enterprise. To configure rsyslog to send logs to a remote log server, open /etc/rsyslog.conf and read and understand the last section of the file, which describes the multiple directives necessary to activate remote logging. Along with these other directives, the system can be configured to forward its logs to a particular log server by adding or correcting one of the following lines, substituting None appropriately. The choice of protocol depends on the environment of the system; although TCP and RELP provide more reliable message delivery, they may not be supported in all environments.
To use UDP for log message delivery: 
*.* @None

Or in RainerScript: 
*.* action(type="omfwd" ... target="None" protocol="udp")

To use TCP for log message delivery: 
*.* @@None

Or in RainerScript: 
*.* action(type="omfwd" ... target="None" protocol="tcp")

To use RELP for log message delivery: 
*.* :omrelp:None

Or in RainerScript: 
*.* action(type="omfwd" ... target="None" protocol="relp")

There must be a resolvable DNS CNAME or Alias record set to "None" for logs to be sent correctly to the centralized logging utility.		 
To ensure logs are sent to a remote host, examine the file
/etc/rsyslog.conf.
If using UDP, a line similar to the following should be present:

 *.* @None

or

*.* action(type="omfwd" ... target="None" protocol="udp")

If using TCP, a line similar to the following should be present:

 *.* @@None

or

*.* action(type="omfwd" ... target="None" protocol="tcp")

If using RELP, a line similar to the following should be present:

 *.* :omrelp:None

or

*.* action(type="omfwd" ... target="None" protocol="relp")

      Is it the case that no evidence that the audit logs are being off-loaded to another system or media?
 SRG-OS-000479-GPOS-00224, SRG-OS-000480-GPOS-00227, SRG-OS-000342-GPOS-00133 CM-6(a), AU-4(1), AU-9(2)
xccdf_org.ssgproject.content_rule_security_patches_up_to_date medium Ensure Software Patches Installed Installing software updates is a fundamental mitigation against the exploitation of publicly-known vulnerabilities. If the most recent security patches and updates are not installed, unauthorized users may take advantage of weaknesses in the unpatched software. The lack of prompt attention to patching could result in a system compromise. If the system is joined to the ULN or a yum server, run the following command to install updates: 
$ sudo yum update
If the system is not configured to use one of these sources, updates (in the form of RPM packages) can be manually downloaded from the ULN and installed using rpm.

NOTE: U.S. Defense systems are required to be patched within 30 days or sooner as local policy dictates.		 
Verify Oracle Linux 9 security patches and updates are installed and up to date.
Updates are required to be applied with a frequency determined by organizational policy.



Typical update frequency may be overridden by Information Assurance Vulnerability Alert (IAVA) notifications from CYBERCOM.
      Is it the case that Oracle Linux 9 is in non-compliance with the organizational patching policy?
 SRG-OS-000480-GPOS-00227 SI-2(5), SI-2(c), CM-6(a)
xccdf_org.ssgproject.content_rule_selinux_all_devicefiles_labeled medium Ensure No Device Files are Unlabeled by SELinux If a device file carries the SELinux type device_t or unlabeled_t, then SELinux cannot properly restrict access to the device file. Device files, which are used for communication with important system resources, should be labeled with proper SELinux types. If any device files carry the SELinux type device_t or unlabeled_t, report the bug so that policy can be corrected. Supply information about what the device is and what programs use it.

To check for incorrectly labeled device files, run following commands: 
$ sudo find /dev -context *:device_t:* \( -type c -o -type b \) -printf "%p %Z\n"
$ sudo find /dev -context *:unlabeled_t:* \( -type c -o -type b \) -printf "%p %Z\n"
It should produce no output in a well-configured system.		 
To check for incorrectly labeled device files, run following commands:

$ sudo find /dev -context *:device_t:* \( -type c -o -type b \) -printf "%p %Z\n"


$ sudo find /dev -context *:unlabeled_t:* \( -type c -o -type b \) -printf "%p %Z\n"

It should produce no output in a well-configured system.
      Is it the case that there is output?
 SRG-OS-000480-GPOS-00227 CM-7(a), CM-7(b), CM-6(a), AC-3(3)(a), AC-6
xccdf_org.ssgproject.content_rule_selinux_policytype medium Configure SELinux Policy Setting the SELinux policy to targeted or a more specialized policy ensures the system will confine processes that are likely to be targeted for exploitation, such as network or system services.

Note: During the development or debugging of SELinux modules, it is common to temporarily place non-production systems in permissive mode. In such temporary cases, SELinux policies should be developed, and once work is completed, the system should be reconfigured to .		 The SELinux targeted policy is appropriate for general-purpose desktops and servers, as well as systems in many other roles. To configure the system to use this policy, add or correct the following line in /etc/selinux/config: 
SELINUXTYPE=targeted
Other policies, such as mls, provide additional security labeling and greater confinement but are not compatible with many general-purpose use cases.		 
Verify the SELINUX on Oracle Linux 9 is using the targeted policy with the following command:

$ sestatus | grep policy

Loaded policy name:             targeted
      Is it the case that the loaded policy name is not "targeted"?
 SRG-OS-000445-GPOS-00199, SRG-APP-000233-CTR-000585 AC-3, AC-3(3)(a), AU-9, SC-7(21)
xccdf_org.ssgproject.content_rule_selinux_state high Ensure SELinux State is Enforcing Setting the SELinux state to enforcing ensures SELinux is able to confine potentially compromised processes to the security policy, which is designed to prevent them from causing damage to the system or further elevating their privileges. The SELinux state should be set to enforcing at system boot time. In the file /etc/selinux/config, add or correct the following line to configure the system to boot into enforcing mode: 
SELINUX=enforcing
Ensure that all files have correct SELinux labels by running: 
fixfiles onboot
Then reboot the system.		 
Ensure that Oracle Linux 9 verifies correct operation of security functions.

Check if "SELinux" is active and in "enforcing" mode with the following command:

$ sudo getenforce
enforcing
      Is it the case that SELINUX is not set to enforcing?
 SRG-OS-000445-GPOS-00199, SRG-OS-000134-GPOS-00068 AC-3, AC-3(3)(a), AU-9, SC-7(21)
xccdf_org.ssgproject.content_rule_service_auditd_enabled medium Enable auditd Service Without establishing what type of events occurred, it would be difficult to establish, correlate, and investigate the events leading up to an outage or attack. Ensuring the auditd service is active ensures audit records generated by the kernel are appropriately recorded.

Additionally, a properly configured audit subsystem ensures that actions of individual system users can be uniquely traced to those users so they can be held accountable for their actions.		 The auditd service is an essential userspace component of the Linux Auditing System, as it is responsible for writing audit records to disk. The auditd service can be enabled with the following command: 
$ sudo systemctl enable auditd.service
 

Run the following command to determine the current status of the
auditd service:

$ sudo systemctl is-active auditd

If the service is running, it should return the following: 
active

      Is it the case that the auditd service is not running?
 SRG-OS-000062-GPOS-00031, SRG-OS-000037-GPOS-00015, SRG-OS-000038-GPOS-00016, SRG-OS-000039-GPOS-00017, SRG-OS-000040-GPOS-00018, SRG-OS-000041-GPOS-00019, SRG-OS-000042-GPOS-00021, SRG-OS-000051-GPOS-00024, SRG-OS-000054-GPOS-00025, SRG-OS-000122-GPOS-00063, SRG-OS-000254-GPOS-00095, SRG-OS-000255-GPOS-00096, SRG-OS-000337-GPOS-00129, SRG-OS-000348-GPOS-00136, SRG-OS-000349-GPOS-00137, SRG-OS-000350-GPOS-00138, SRG-OS-000351-GPOS-00139, SRG-OS-000352-GPOS-00140, SRG-OS-000353-GPOS-00141, SRG-OS-000354-GPOS-00142, SRG-OS-000358-GPOS-00145, SRG-OS-000365-GPOS-00152, SRG-OS-000392-GPOS-00172, SRG-OS-000475-GPOS-00220, SRG-APP-000095-CTR-000170, SRG-APP-000409-CTR-000990, SRG-APP-000508-CTR-001300, SRG-APP-000510-CTR-001310 AC-2(g), AU-3, AU-10, AU-2(d), AU-12(c), AU-14(1), AC-6(9), CM-6(a), SI-4(23)
xccdf_org.ssgproject.content_rule_service_autofs_disabled medium Disable the Automounter Disabling the automounter permits the administrator to statically control filesystem mounting through /etc/fstab.

Additionally, automatically mounting filesystems permits easy introduction of unknown devices, thereby facilitating malicious activity.		 The autofs daemon mounts and unmounts filesystems, such as user home directories shared via NFS, on demand. In addition, autofs can be used to handle removable media, and the default configuration provides the cdrom device as /misc/cd. However, this method of providing access to removable media is not common, so autofs can almost always be disabled if NFS is not in use. Even if NFS is required, it may be possible to configure filesystem mounts statically by editing /etc/fstab rather than relying on the automounter.

The autofs service can be disabled with the following command: 
$ sudo systemctl mask --now autofs.service
 
To check that the autofs service is disabled in system boot configuration,
run the following command:

$ sudo systemctl is-enabled autofs

Output should indicate the autofs service has either not been installed,
or has been disabled at all runlevels, as shown in the example below:

$ sudo systemctl is-enabled autofs
 disabled


Run the following command to verify autofs is not active (i.e. not running) through current runtime configuration:

$ sudo systemctl is-active autofs


If the service is not running the command will return the following output:

inactive


The service will also be masked, to check that the autofs is masked, run the following command:

$ sudo systemctl show autofs | grep "LoadState\|UnitFileState"


If the service is masked the command will return the following outputs:


LoadState=masked



UnitFileState=masked

      Is it the case that the "autofs" is loaded and not masked?
 SRG-OS-000114-GPOS-00059, SRG-OS-000378-GPOS-00163, SRG-OS-000480-GPOS-00227 CM-7(a), CM-7(b), CM-6(a), MP-7
xccdf_org.ssgproject.content_rule_service_chronyd_enabled medium The Chronyd service is enabled If chrony is in use on the system proper configuration is vital to ensuring time synchronization is working properly. chrony is a daemon which implements the Network Time Protocol (NTP) is designed to synchronize system clocks across a variety of systems and use a source that is highly accurate. More information on chrony can be found at https://chrony-project.org/. Chrony can be configured to be a client and/or a server. To enable Chronyd service, you can run: # systemctl enable chronyd.service This recommendation only applies if chrony is in use on the system. 

Run the following command to determine the current status of the
chronyd service:

$ sudo systemctl is-active chronyd

If the service is running, it should return the following: 
active

      Is it the case that the chronyd process is not running?
 SRG-OS-000355-GPOS-00143
xccdf_org.ssgproject.content_rule_service_debug-shell_disabled medium Disable debug-shell SystemD Service This prevents attackers with physical access from trivially bypassing security on the machine through valid troubleshooting configurations and gaining root access when the system is rebooted. SystemD's debug-shell service is intended to diagnose SystemD related boot issues with various systemctl commands. Once enabled and following a system reboot, the root shell will be available on tty9 which is access by pressing CTRL-ALT-F9. The debug-shell service should only be used for SystemD related issues and should otherwise be disabled.

By default, the debug-shell SystemD service is already disabled. The debug-shell service can be disabled with the following command: 
$ sudo systemctl mask --now debug-shell.service
 
To check that the debug-shell service is disabled in system boot configuration,
run the following command:

$ sudo systemctl is-enabled debug-shell

Output should indicate the debug-shell service has either not been installed,
or has been disabled at all runlevels, as shown in the example below:

$ sudo systemctl is-enabled debug-shell
 disabled


Run the following command to verify debug-shell is not active (i.e. not running) through current runtime configuration:

$ sudo systemctl is-active debug-shell


If the service is not running the command will return the following output:

inactive


The service will also be masked, to check that the debug-shell is masked, run the following command:

$ sudo systemctl show debug-shell | grep "LoadState\|UnitFileState"


If the service is masked the command will return the following outputs:


LoadState=masked



UnitFileState=masked

      Is it the case that the "debug-shell" is loaded and not masked?
 SRG-OS-000324-GPOS-00125, SRG-OS-000480-GPOS-00227 CM-6
xccdf_org.ssgproject.content_rule_service_fapolicyd_enabled medium Enable the File Access Policy Service The fapolicyd service (File Access Policy Daemon) implements application whitelisting to decide file access rights. The File Access Policy service should be enabled. The fapolicyd service can be enabled with the following command: 
$ sudo systemctl enable fapolicyd.service
 

Run the following command to determine the current status of the
fapolicyd service:

$ sudo systemctl is-active fapolicyd

If the service is running, it should return the following: 
active

      Is it the case that the service is not enabled?
 SRG-OS-000370-GPOS-00155, SRG-OS-000368-GPOS-00154, SRG-OS-000480-GPOS-00230 CM-6(a), SI-4(22)
xccdf_org.ssgproject.content_rule_service_firewalld_enabled medium Verify firewalld Enabled Access control methods provide the ability to enhance system security posture by restricting services and known good IP addresses and address ranges. This prevents connections from unknown hosts and protocols. The firewalld service can be enabled with the following command: 
$ sudo systemctl enable firewalld.service
 

Run the following command to determine the current status of the
firewalld service:

$ sudo systemctl is-active firewalld

If the service is running, it should return the following: 
active

      Is it the case that the "firewalld" service is disabled, masked, or not started.?
 SRG-OS-000096-GPOS-00050, SRG-OS-000297-GPOS-00115, SRG-OS-000480-GPOS-00227, SRG-OS-000480-GPOS-00231, SRG-OS-000480-GPOS-00232 AC-4, CM-7(b), CA-3(5), SC-7(21), CM-6(a)
xccdf_org.ssgproject.content_rule_service_kdump_disabled medium Disable KDump Kernel Crash Analyzer (kdump) Kernel core dumps may contain the full contents of system memory at the time of the crash. Kernel core dumps consume a considerable amount of disk space and may result in denial of service by exhausting the available space on the target file system partition. Unless the system is used for kernel development or testing, there is little need to run the kdump service. The kdump service provides a kernel crash dump analyzer. It uses the kexec system call to boot a secondary kernel ("capture" kernel) following a system crash, which can load information from the crashed kernel for analysis. The kdump service can be disabled with the following command: 
$ sudo systemctl mask --now kdump.service
 
To check that the kdump service is disabled in system boot configuration,
run the following command:

$ sudo systemctl is-enabled kdump

Output should indicate the kdump service has either not been installed,
or has been disabled at all runlevels, as shown in the example below:

$ sudo systemctl is-enabled kdump
 disabled


Run the following command to verify kdump is not active (i.e. not running) through current runtime configuration:

$ sudo systemctl is-active kdump


If the service is not running the command will return the following output:

inactive


The service will also be masked, to check that the kdump is masked, run the following command:

$ sudo systemctl show kdump | grep "LoadState\|UnitFileState"


If the service is masked the command will return the following outputs:


LoadState=masked



UnitFileState=masked

      Is it the case that the "kdump" is loaded and not masked?
 SRG-OS-000269-GPOS-00103, SRG-OS-000480-GPOS-00227 CM-7(a), CM-7(b), CM-6(a)
xccdf_org.ssgproject.content_rule_service_pcscd_enabled medium Enable the pcscd Service Using an authentication device, such as a CAC or token that is separate from the information system, ensures that even if the information system is compromised, that compromise will not affect credentials stored on the authentication device.

Multifactor solutions that require devices separate from information systems gaining access include, for example, hardware tokens providing time-based or challenge-response authenticators and smart cards or similar secure authentication devices issued by an organization or identity provider.		 The pcscd service can be enabled with the following command: 
$ sudo systemctl enable pcscd.service
 

Run the following command to determine the current status of the
pcscd service:

$ sudo systemctl is-active pcscd

If the service is running, it should return the following: 
active

      Is it the case that the pcscd service is not enabled?
 SRG-OS-000375-GPOS-00160 IA-2(1), IA-2(2), IA-2(3), IA-2(4), IA-2(6), IA-2(7), IA-2(11), CM-6(a)
xccdf_org.ssgproject.content_rule_service_rsyslog_enabled medium Enable rsyslog Service The rsyslog service must be running in order to provide logging services, which are essential to system administration. The rsyslog service provides syslog-style logging by default on Oracle Linux 9. The rsyslog service can be enabled with the following command: 
$ sudo systemctl enable rsyslog.service
 

Run the following command to determine the current status of the
rsyslog service:

$ sudo systemctl is-active rsyslog

If the service is running, it should return the following: 
active

      Is it the case that the "rsyslog" service is disabled, masked, or not started.?
 SRG-OS-000480-GPOS-00227 CM-6(a), AU-4(1)
xccdf_org.ssgproject.content_rule_service_sshd_enabled medium Enable the OpenSSH Service Without protection of the transmitted information, confidentiality, and integrity may be compromised because unprotected communications can be intercepted and either read or altered.

This checklist item applies to both internal and external networks and all types of information system components from which information can be transmitted (e.g., servers, mobile devices, notebook computers, printers, copiers, scanners, etc). Communication paths outside the physical protection of a controlled boundary are exposed to the possibility of interception and modification.		 The SSH server service, sshd, is commonly needed. The sshd service can be enabled with the following command: 
$ sudo systemctl enable sshd.service
 

Run the following command to determine the current status of the
sshd service:

$ sudo systemctl is-active sshd

If the service is running, it should return the following: 
active

      Is it the case that sshd service is disabled?
 SRG-OS-000423-GPOS-00187, SRG-OS-000424-GPOS-00188, SRG-OS-000425-GPOS-00189, SRG-OS-000426-GPOS-00190 CM-6(a), SC-8, SC-8(1), SC-8(2), SC-8(3), SC-8(4)
xccdf_org.ssgproject.content_rule_service_sssd_enabled medium Enable the SSSD Service The SSSD service should be enabled. The sssd service can be enabled with the following command: 
$ sudo systemctl enable sssd.service
 

Run the following command to determine the current status of the
sssd service:

$ sudo systemctl is-active sssd

If the service is running, it should return the following: 
active

      Is it the case that the service is not enabled?
 SRG-OS-000375-GPOS-00160 CM-6(a), IA-5(10)
xccdf_org.ssgproject.content_rule_service_systemd-coredump_disabled medium Disable acquiring, saving, and processing core dumps A core dump includes a memory image taken at the time the operating system terminates an application. The memory image could contain sensitive data and is generally useful only for developers trying to debug problems. The systemd-coredump.socket unit is a socket activation of the systemd-coredump@.service which processes core dumps. By masking the unit, core dump processing is disabled. 
To verify that acquiring, saving, and processing core dumps is disabled, run the
following command:

$ systemctl status systemd-coredump.socket

The output should be similar to:

â—Ź systemd-coredump.socket
   Loaded: masked (Reason: Unit systemd-coredump.socket is masked.)
   Active: inactive (dead) ...


      Is it the case that unit systemd-coredump.socket is not masked or running?
 SRG-OS-000480-GPOS-00227 SC-7(10)
xccdf_org.ssgproject.content_rule_service_systemd-journald_enabled medium Enable systemd-journald Service In the event of a system failure, Oracle Linux 9 must preserve any information necessary to determine cause of failure and any information necessary to return to operations with least disruption to system processes. The systemd-journald service is an essential component of systemd. The systemd-journald service can be enabled with the following command: 
$ sudo systemctl enable systemd-journald.service
 

Run the following command to determine the current status of the
systemd-journald service:

$ sudo systemctl is-active systemd-journald

If the service is running, it should return the following: 
active

      Is it the case that the systemd-journald service is not running?
 SRG-OS-000269-GPOS-00103 SC-24
xccdf_org.ssgproject.content_rule_service_usbguard_enabled medium Enable the USBGuard Service The usbguard service must be running in order to enforce the USB device authorization policy for all USB devices. The USBGuard service should be enabled. The usbguard service can be enabled with the following command: 
$ sudo systemctl enable usbguard.service
 

Run the following command to determine the current status of the
usbguard service:

$ sudo systemctl is-active usbguard

If the service is running, it should return the following: 
active

      Is it the case that the service is not enabled?
 SRG-OS-000378-GPOS-00163, SRG-APP-000141-CTR-000315 CM-8(3)(a), IA-3
xccdf_org.ssgproject.content_rule_set_password_hashing_algorithm_libuserconf medium Set Password Hashing Algorithm in /etc/libuser.conf Passwords need to be protected at all times, and encryption is the standard method for protecting passwords. If passwords are not encrypted, they can be plainly read (i.e., clear text) and easily compromised. Passwords that are encrypted with a weak algorithm are no more protected than if they are kept in plain text.

This setting ensures user and group account administration utilities are configured to store only encrypted representations of passwords. Additionally, the crypt_style configuration option in /etc/libuser.conf ensures the use of a strong hashing algorithm that makes password cracking attacks more difficult.		 In /etc/libuser.conf, add or correct the following line in its [defaults] section to ensure the system will use the sha512 algorithm for password hashing: 
crypt_style = sha512
 
Verify that the libuser is set to encrypt password with a FIPS 140-3 approved cryptographic hashing algorithm.


Check the hashing algorithm that is being used to hash passwords with the following command:

$ sudo grep -i crypt_style /etc/libuser.conf

crypt_style = sha512
      Is it the case that crypt_style is not set to sha512?
 SRG-OS-000073-GPOS-00041 IA-5(c), IA-5(1)(c), CM-6(a)
xccdf_org.ssgproject.content_rule_set_password_hashing_algorithm_logindefs medium Set Password Hashing Algorithm in /etc/login.defs Passwords need to be protected at all times, and encryption is the standard method for protecting passwords. If passwords are not encrypted, they can be plainly read (i.e., clear text) and easily compromised. Passwords that are encrypted with a weak algorithm are no more protected than if they are kept in plain text.

Using a stronger hashing algorithm makes password cracking attacks more difficult.		 In /etc/login.defs, add or update the following line to ensure the system will use SHA512 as the hashing algorithm: 
ENCRYPT_METHOD SHA512
 
Verify that the shadow password suite configuration is set to encrypt password with a FIPS 140-3 approved cryptographic hashing algorithm.


Check the hashing algorithm that is being used to hash passwords with the following command:

$ sudo grep -i ENCRYPT_METHOD  /etc/login.defs

ENCRYPT_METHOD SHA512
      Is it the case that ENCRYPT_METHOD is not set to SHA512?
 SRG-OS-000073-GPOS-00041 IA-5(c), IA-5(1)(c), CM-6(a)
xccdf_org.ssgproject.content_rule_set_password_hashing_algorithm_passwordauth medium Set PAM Password Hashing Algorithm - password-auth Passwords need to be protected at all times, and encryption is the standard method for protecting passwords. If passwords are not encrypted, they can be plainly read (i.e., clear text) and easily compromised. Passwords that are encrypted with a weak algorithm are no more protected than if they are kept in plain text.

This setting ensures user and group account administration utilities are configured to store only encrypted representations of passwords. Additionally, the crypt_style configuration option in /etc/libuser.conf ensures the use of a strong hashing algorithm that makes password cracking attacks more difficult.		 The PAM system service can be configured to only store encrypted representations of passwords. In /etc/pam.d/password-auth, the password section of the file controls which PAM modules to execute during a password change. Set the pam_unix.so module in the password section to include the option sha512 and no other hashing algorithms as shown below: 
password    sufficient    pam_unix.so sha512 other arguments...

This will help ensure that new passwords for local users will be stored using the sha512 algorithm.		 
Inspect the password section of /etc/pam.d/password-auth
and ensure that the pam_unix.so module is configured to use the argument
sha512:


$ grep sha512 /etc/pam.d/password-auth

      Is it the case that it does not?
 SRG-OS-000073-GPOS-00041, SRG-OS-000120-GPOS-00061 IA-5(c), IA-5(1)(c), CM-6(a)
xccdf_org.ssgproject.content_rule_set_password_hashing_min_rounds_logindefs medium Set Password Hashing Rounds in /etc/login.defs Passwords need to be protected at all times, and hashing is the standard method for protecting passwords. If passwords are not hashed, they can be plainly read (i.e., clear text) and easily compromised. Passwords that are hashed with a weak algorithm are no more protected than if they are kept in plain text.

Using more hashing rounds makes password cracking attacks more difficult.		 In /etc/login.defs, ensure SHA_CRYPT_MIN_ROUNDS and SHA_CRYPT_MAX_ROUNDS has the minimum value of 100000. For example: 
SHA_CRYPT_MIN_ROUNDS 100000
SHA_CRYPT_MAX_ROUNDS 100000
Notice that if neither are set, they already have the default value of 5000. If either is set, they must have the minimum value of 100000.		 
Inspect /etc/login.defs and ensure that if either
SHA_CRYPT_MIN_ROUNDS or SHA_CRYPT_MAX_ROUNDS
are set, they must have the minimum value of 100000.
      Is it the case that it does not?
 SRG-OS-000073-GPOS-00041, SRG-OS-000120-GPOS-00061
xccdf_org.ssgproject.content_rule_ssh_keys_passphrase_protected medium Verify the SSH Private Key Files Have a Passcode If an unauthorized user obtains access to a private key without a passcode, that user would have unauthorized access to any system where the associated public key has been installed. When creating SSH key pairs, always use a passcode.
You can create such keys with the following command: 
$ sudo ssh-keygen -n [passphrase]
Oracle Linux 9, for certificate-based authentication, must enforce authorized access to the corresponding private key.		 
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.
      Is it the case that no ssh private key is accessible without a passcode?
 SRG-OS-000067-GPOS-00035
xccdf_org.ssgproject.content_rule_sshd_disable_compression medium Disable Compression Or Set Compression to delayed If compression is allowed in an SSH connection prior to authentication, vulnerabilities in the compression software could result in compromise of the system from an unauthenticated connection, potentially with root privileges. Compression is useful for slow network connections over long distances but can cause performance issues on local LANs. If use of compression is required, it should be enabled only after a user has authenticated; otherwise, it should be disabled. To disable compression or delay compression until after a user has successfully authenticated, add or correct the following line in the /etc/ssh/sshd_config file: 
Compression no
 
To check if compression is enabled or set correctly, run the
following command:

$ sudo grep Compression /etc/ssh/sshd_config

If configured properly, output should be 
no
 or 
delayed
.
      Is it the case that it is commented out, or is not set to no or delayed?
 SRG-OS-000480-GPOS-00227 AC-17(a), CM-7(a), CM-7(b), CM-6(a)
xccdf_org.ssgproject.content_rule_sshd_disable_empty_passwords high Disable SSH Access via Empty Passwords Configuring this setting for the SSH daemon provides additional assurance that remote login via SSH will require a password, even in the event of misconfiguration elsewhere. Disallow SSH login with empty passwords. The default SSH configuration disables logins with empty passwords. The appropriate configuration is used if no value is set for PermitEmptyPasswords.
To explicitly disallow SSH login from accounts with empty passwords, add or correct the following line in /etc/ssh/sshd_config.d/00-complianceascode-hardening.conf: 
PermitEmptyPasswords no
Any accounts with empty passwords should be disabled immediately, and PAM configuration should prevent users from being able to assign themselves empty passwords.		 
To determine how the SSH daemon's PermitEmptyPasswords option is set, run the following command:


$ sudo grep -i PermitEmptyPasswords /etc/ssh/sshd_config.d/00-complianceascode-hardening.conf


$ sudo grep -i PermitEmptyPasswords /etc/ssh/sshd_config.d/01-complianceascode-reinforce-os-defaults.conf


If a line indicating no is returned, then the required value is set.

      Is it the case that the required value is not set?
 SRG-OS-000106-GPOS-00053, SRG-OS-000480-GPOS-00229, SRG-OS-000480-GPOS-00227 AC-17(a), CM-7(a), CM-7(b), CM-6(a)
xccdf_org.ssgproject.content_rule_sshd_disable_gssapi_auth medium Disable GSSAPI Authentication GSSAPI authentication is used to provide additional authentication mechanisms to applications. Allowing GSSAPI authentication through SSH exposes the system's GSSAPI to remote hosts, increasing the attack surface of the system. Unless needed, SSH should not permit extraneous or unnecessary authentication mechanisms like GSSAPI.
The default SSH configuration disallows authentications based on GSSAPI. The appropriate configuration is used if no value is set for GSSAPIAuthentication.
To explicitly disable GSSAPI authentication, add or correct the following line in /etc/ssh/sshd_config.d/00-complianceascode-hardening.conf: 
GSSAPIAuthentication no
 
To determine how the SSH daemon's GSSAPIAuthentication option is set, run the following command:


$ sudo grep -i GSSAPIAuthentication /etc/ssh/sshd_config.d/00-complianceascode-hardening.conf


$ sudo grep -i GSSAPIAuthentication /etc/ssh/sshd_config.d/01-complianceascode-reinforce-os-defaults.conf


If a line indicating no is returned, then the required value is set.

      Is it the case that the required value is not set?
 SRG-OS-000364-GPOS-00151, SRG-OS-000480-GPOS-00227 CM-7(a), CM-7(b), CM-6(a), AC-17(a)
xccdf_org.ssgproject.content_rule_sshd_disable_kerb_auth medium Disable Kerberos Authentication Kerberos authentication for SSH is often implemented using GSSAPI. If Kerberos is enabled through SSH, the SSH daemon provides a means of access to the system's Kerberos implementation. Configuring these settings for the SSH daemon provides additional assurance that remote logon via SSH will not use unused methods of authentication, even in the event of misconfiguration elsewhere. Unless needed, SSH should not permit extraneous or unnecessary authentication mechanisms like Kerberos.
The default SSH configuration disallows authentication validation through Kerberos. The appropriate configuration is used if no value is set for KerberosAuthentication.
To explicitly disable Kerberos authentication, add or correct the following line in /etc/ssh/sshd_config.d/00-complianceascode-hardening.conf: 
KerberosAuthentication no
 
To determine how the SSH daemon's KerberosAuthentication option is set, run the following command:


$ sudo grep -i KerberosAuthentication /etc/ssh/sshd_config.d/00-complianceascode-hardening.conf


$ sudo grep -i KerberosAuthentication /etc/ssh/sshd_config.d/01-complianceascode-reinforce-os-defaults.conf


If a line indicating no is returned, then the required value is set.

      Is it the case that the required value is not set?
 SRG-OS-000364-GPOS-00151, SRG-OS-000480-GPOS-00227 AC-17(a), CM-7(a), CM-7(b), CM-6(a)
xccdf_org.ssgproject.content_rule_sshd_disable_rhosts medium Disable SSH Support for .rhosts Files SSH trust relationships mean a compromise on one host can allow an attacker to move trivially to other hosts. SSH can emulate the behavior of the obsolete rsh command in allowing users to enable insecure access to their accounts via .rhosts files.
The default SSH configuration disables support for .rhosts. The appropriate configuration is used if no value is set for IgnoreRhosts.
To explicitly disable support for .rhosts files, add or correct the following line in /etc/ssh/sshd_config.d/00-complianceascode-hardening.conf: 
IgnoreRhosts yes
 
To determine how the SSH daemon's IgnoreRhosts option is set, run the following command:


$ sudo grep -i IgnoreRhosts /etc/ssh/sshd_config.d/00-complianceascode-hardening.conf


$ sudo grep -i IgnoreRhosts /etc/ssh/sshd_config.d/01-complianceascode-reinforce-os-defaults.conf


If a line indicating yes is returned, then the required value is set.

      Is it the case that the required value is not set?
 SRG-OS-000480-GPOS-00227 AC-17(a), CM-7(a), CM-7(b), CM-6(a)
xccdf_org.ssgproject.content_rule_sshd_disable_root_login medium Disable SSH Root Login Even though the communications channel may be encrypted, an additional layer of security is gained by extending the policy of not logging directly on as root. In addition, logging in with a user-specific account provides individual accountability of actions performed on the system and also helps to minimize direct attack attempts on root's password. The root user should never be allowed to login to a system directly over a network. To disable root login via SSH, add or correct the following line in /etc/ssh/sshd_config.d/00-complianceascode-hardening.conf: 
PermitRootLogin no
 
To determine how the SSH daemon's PermitRootLogin option is set, run the following command:


$ sudo grep -i PermitRootLogin /etc/ssh/sshd_config.d/00-complianceascode-hardening.conf



If a line indicating no is returned, then the required value is set.

      Is it the case that the required value is not set?
 SRG-OS-000109-GPOS-00056, SRG-OS-000480-GPOS-00227, SRG-APP-000148-CTR-000335, SRG-APP-000190-CTR-000500 AC-6(2), AC-17(a), IA-2, IA-2(5), CM-7(a), CM-7(b), CM-6(a)
xccdf_org.ssgproject.content_rule_sshd_disable_user_known_hosts medium Disable SSH Support for User Known Hosts Configuring this setting for the SSH daemon provides additional assurance that remote login via SSH will require a password, even in the event of misconfiguration elsewhere. SSH can allow system users to connect to systems if a cache of the remote systems public keys is available. This should be disabled.

To ensure this behavior is disabled, add or correct the following line in /etc/ssh/sshd_config.d/00-complianceascode-hardening.conf: 
IgnoreUserKnownHosts yes
 
To determine how the SSH daemon's IgnoreUserKnownHosts option is set, run the following command:


$ sudo grep -i IgnoreUserKnownHosts /etc/ssh/sshd_config.d/00-complianceascode-hardening.conf



If a line indicating yes is returned, then the required value is set.

      Is it the case that the required value is not set?
 SRG-OS-000480-GPOS-00227 AC-17(a), CM-7(a), CM-7(b), CM-6(a)
xccdf_org.ssgproject.content_rule_sshd_disable_x11_forwarding medium Disable X11 Forwarding Disable X11 forwarding unless there is an operational requirement to use X11 applications directly. There is a small risk that the remote X11 servers of users who are logged in via SSH with X11 forwarding could be compromised by other users on the X11 server. Note that even if X11 forwarding is disabled, users can always install their own forwarders. The X11Forwarding parameter provides the ability to tunnel X11 traffic through the connection to enable remote graphic connections. SSH has the capability to encrypt remote X11 connections when SSH's X11Forwarding option is enabled.
The default SSH configuration disables X11Forwarding. The appropriate configuration is used if no value is set for X11Forwarding.
To explicitly disable X11 Forwarding, add or correct the following line in /etc/ssh/sshd_config.d/00-complianceascode-hardening.conf: 
X11Forwarding no
 
To determine how the SSH daemon's X11Forwarding option is set, run the following command:


$ sudo grep -i X11Forwarding /etc/ssh/sshd_config.d/00-complianceascode-hardening.conf


$ sudo grep -i X11Forwarding /etc/ssh/sshd_config.d/01-complianceascode-reinforce-os-defaults.conf


If a line indicating no is returned, then the required value is set.

      Is it the case that the required value is not set?
 SRG-OS-000480-GPOS-00227 CM-6(b)
xccdf_org.ssgproject.content_rule_sshd_do_not_permit_user_env medium Do Not Allow SSH Environment Options SSH environment options potentially allow users to bypass access restriction in some configurations. Ensure that users are not able to override environment variables of the SSH daemon.
The default SSH configuration disables environment processing. The appropriate configuration is used if no value is set for PermitUserEnvironment.
To explicitly disable Environment options, add or correct the following /etc/ssh/sshd_config.d/00-complianceascode-hardening.conf: 
PermitUserEnvironment no
 
To determine how the SSH daemon's PermitUserEnvironment option is set, run the following command:


$ sudo grep -i PermitUserEnvironment /etc/ssh/sshd_config.d/00-complianceascode-hardening.conf


$ sudo grep -i PermitUserEnvironment /etc/ssh/sshd_config.d/01-complianceascode-reinforce-os-defaults.conf


If a line indicating no is returned, then the required value is set.

      Is it the case that the required value is not set?
 SRG-OS-000480-GPOS-00229 AC-17(a), CM-7(a), CM-7(b), CM-6(a)
xccdf_org.ssgproject.content_rule_sshd_enable_pam medium Enable PAM When UsePAM is set to yes, PAM runs through account and session types properly. This is important if you want to restrict access to services based off of IP, time or other factors of the account. Additionally, you can make sure users inherit certain environment variables on login or disallow access to the server. UsePAM Enables the Pluggable Authentication Module interface. If set to “yes” this will enable PAM authentication using ChallengeResponseAuthentication and PasswordAuthentication in addition to PAM account and session module processing for all authentication types. To enable PAM authentication, add or correct the following line in /etc/ssh/sshd_config.d/00-complianceascode-hardening.conf: 
UsePAM yes
 
To determine how the SSH daemon's UsePAM option is set, run the following command:


$ sudo grep -i UsePAM /etc/ssh/sshd_config.d/00-complianceascode-hardening.conf



If a line indicating yes is returned, then the required value is set.

      Is it the case that the required value is not set?
 SRG-OS-000125-GPOS-00065
xccdf_org.ssgproject.content_rule_sshd_enable_pubkey_auth medium Enable Public Key Authentication Without the use of multifactor authentication, the ease of access to privileged functions is greatly increased. Multifactor authentication requires using two or more factors to achieve authentication. A privileged account is defined as an information system account with authorizations of a privileged user. Smart cards or hardware tokens paired with digital certificates are common examples of multifactor implementations. Enable SSH login with public keys.
The default SSH configuration enables authentication based on public keys. The appropriate configuration is used if no value is set for PubkeyAuthentication.
To explicitly enable Public Key Authentication, add or correct the following /etc/ssh/sshd_config.d/00-complianceascode-hardening.conf: 
PubkeyAuthentication yes
 
To determine how the SSH daemon's PubkeyAuthentication option is set, run the following command:


$ sudo grep -i PubkeyAuthentication /etc/ssh/sshd_config.d/00-complianceascode-hardening.conf



If a line indicating yes is returned, then the required value is set.

      Is it the case that the required value is not set?
 SRG-OS-000105-GPOS-00052, SRG-OS-000106-GPOS-00053, SRG-OS-000107-GPOS-00054, SRG-OS-000108-GPOS-00055
xccdf_org.ssgproject.content_rule_sshd_enable_strictmodes medium Enable Use of Strict Mode Checking If other users have access to modify user-specific SSH configuration files, they may be able to log into the system as another user. SSHs StrictModes option checks file and ownership permissions in the user's home directory .ssh folder before accepting login. If world- writable permissions are found, logon is rejected.
The default SSH configuration has StrictModes enabled. The appropriate configuration is used if no value is set for StrictModes.
To explicitly enable StrictModes in SSH, add or correct the following line in /etc/ssh/sshd_config.d/00-complianceascode-hardening.conf: 
StrictModes yes
 
To determine how the SSH daemon's StrictModes option is set, run the following command:


$ sudo grep -i StrictModes /etc/ssh/sshd_config.d/00-complianceascode-hardening.conf


$ sudo grep -i StrictModes /etc/ssh/sshd_config.d/01-complianceascode-reinforce-os-defaults.conf


If a line indicating yes is returned, then the required value is set.

      Is it the case that the required value is not set?
 SRG-OS-000480-GPOS-00227 AC-6, AC-17(a), CM-6(a)
xccdf_org.ssgproject.content_rule_sshd_enable_warning_banner medium Enable SSH Warning Banner The warning message reinforces policy awareness during the logon process and facilitates possible legal action against attackers. Alternatively, systems whose ownership should not be obvious should ensure usage of a banner that does not provide easy attribution. To enable the warning banner and ensure it is consistent across the system, add or correct the following line in /etc/ssh/sshd_config.d/00-complianceascode-hardening.conf: 
Banner /etc/issue
Another section contains information on how to create an appropriate system-wide warning banner.		 
To determine how the SSH daemon's Banner option is set, run the following command:


$ sudo grep -i Banner /etc/ssh/sshd_config.d/00-complianceascode-hardening.conf



If a line indicating /etc/issue is returned, then the required value is set.

      Is it the case that the required value is not set?
 SRG-OS-000023-GPOS-00006, SRG-OS-000228-GPOS-00088 AC-8(a), AC-8(c), AC-17(a), CM-6(a)
xccdf_org.ssgproject.content_rule_sshd_include_crypto_policy medium SSHD Must Include System Crypto Policy Config File Without cryptographic integrity protections, information can be altered by unauthorized users without detection. SSHD should follow the system cryptographic policy. In order to accomplish this the SSHD configuration should include the configuration file provided by the system crypto policy. The following line should be present in /etc/ssh/sshd_config or in a file included by this file (a file within the /etc/ssh/sshd_config.d directory): 
Include /etc/crypto-policies/back-ends/opensshserver.config
 
None
      Is it the case that None?
 SRG-OS-000250-GPOS-00093 AC-17 (2)
xccdf_org.ssgproject.content_rule_sshd_print_last_log medium Enable SSH Print Last Log Providing users feedback on when account accesses last occurred facilitates user recognition and reporting of unauthorized account use. Ensure that SSH will display the date and time of the last successful account logon.
The default SSH configuration enables print of the date and time of the last login. The appropriate configuration is used if no value is set for PrintLastLog.
To explicitly enable LastLog in SSH, add or correct the following line in /etc/ssh/sshd_config.d/00-complianceascode-hardening.conf: 
PrintLastLog yes
 
To determine how the SSH daemon's PrintLastLog option is set, run the following command:


$ sudo grep -i PrintLastLog /etc/ssh/sshd_config.d/00-complianceascode-hardening.conf


$ sudo grep -i PrintLastLog /etc/ssh/sshd_config.d/01-complianceascode-reinforce-os-defaults.conf


If a line indicating yes is returned, then the required value is set.

      Is it the case that the required value is not set?
 SRG-OS-000480-GPOS-00227 AC-9, AC-9(1)
xccdf_org.ssgproject.content_rule_sshd_rekey_limit medium Force frequent session key renegotiation By decreasing the limit based on the amount of data and enabling time-based limit, effects of potential attacks against encryption keys are limited. The RekeyLimit parameter specifies how often the session key of the is renegotiated, both in terms of amount of data that may be transmitted and the time elapsed.
To decrease the default limits, add or correct the following line in /etc/ssh/sshd_config.d/00-complianceascode-hardening.conf: 
RekeyLimit 1G 1h
 
To check if RekeyLimit is set correctly, run the
following command:


$ sudo grep RekeyLimit /etc/ssh/sshd_config /etc/ssh/sshd_config.d/*


If configured properly, output should be

RekeyLimit 1G 1h

      Is it the case that it is commented out or is not set?
 SRG-OS-000480-GPOS-00227, SRG-OS-000033-GPOS-00014
xccdf_org.ssgproject.content_rule_sshd_set_idle_timeout medium Set SSH Client Alive Interval Terminating an idle ssh session within a short time period reduces the window of opportunity for unauthorized personnel to take control of a management session enabled on the console or console port that has been let unattended. SSH allows administrators to set a network responsiveness timeout interval. After this interval has passed, the unresponsive client will be automatically logged out.

To set this timeout interval, edit the following line in /etc/ssh/sshd_config as follows: 
ClientAliveInterval 600


The timeout interval is given in seconds. For example, have a timeout of 10 minutes, set interval to 600.

If a shorter timeout has already been set for the login shell, that value will preempt any SSH setting made in /etc/ssh/sshd_config. Keep in mind that some processes may stop SSH from correctly detecting that the user is idle.		 
Run the following command to see what the timeout interval is:

$ sudo grep ClientAliveInterval /etc/ssh/sshd_config

If properly configured, the output should be:

ClientAliveInterval 600

      Is it the case that it is commented out or not configured properly?
 SRG-OS-000126-GPOS-00066, SRG-OS-000163-GPOS-00072, SRG-OS-000279-GPOS-00109, SRG-OS-000395-GPOS-00175 CM-6(a), AC-17(a), AC-2(5), AC-12, AC-17(a), SC-10, CM-6(a)
xccdf_org.ssgproject.content_rule_sshd_set_keepalive medium Set SSH Client Alive Count Max This ensures a user login will be terminated as soon as the ClientAliveInterval is reached. The SSH server sends at most ClientAliveCountMax messages during a SSH session and waits for a response from the SSH client. The option ClientAliveInterval configures timeout after each ClientAliveCountMax message. If the SSH server does not receive a response from the client, then the connection is considered unresponsive and terminated. For SSH earlier than v8.2, a ClientAliveCountMax value of 0 causes a timeout precisely when the ClientAliveInterval is set. Starting with v8.2, a value of 0 disables the timeout functionality completely. If the option is set to a number greater than 0, then the session will be disconnected after ClientAliveInterval * ClientAliveCountMax seconds without receiving a keep alive message. 
To ensure ClientAliveInterval is set correctly, run the following command:

$ sudo grep ClientAliveCountMax /etc/ssh/sshd_config

If properly configured, the output should be:

ClientAliveCountMax 

For SSH earlier than v8.2, a ClientAliveCountMax value of 0 causes a timeout precisely when
the ClientAliveInterval is set.  Starting with v8.2, a value of 0 disables the timeout
functionality completely.
If the option is set to a number greater than 0, then the session will be disconnected after
ClientAliveInterval * ClientAliveCountMax seconds without receiving a keep alive message.
      Is it the case that it is commented out or not configured properly?
 SRG-OS-000163-GPOS-00072, SRG-OS-000279-GPOS-00109 AC-2(5), AC-12, AC-17(a), SC-10, CM-6(a)
xccdf_org.ssgproject.content_rule_sshd_set_loglevel_verbose medium Set SSH Daemon LogLevel to VERBOSE SSH provides several logging levels with varying amounts of verbosity. DEBUG is specifically not recommended other than strictly for debugging SSH communications since it provides so much data that it is difficult to identify important security information. INFO or VERBOSE level is the basic level that only records login activity of SSH users. In many situations, such as Incident Response, it is important to determine when a particular user was active on a system. The logout record can eliminate those users who disconnected, which helps narrow the field. The VERBOSE parameter configures the SSH daemon to record login and logout activity. To specify the log level in SSH, add or correct the following line in /etc/ssh/sshd_config.d/00-complianceascode-hardening.conf: 
LogLevel VERBOSE
 
To determine how the SSH daemon's LogLevel option is set, run the following command:


$ sudo grep -i LogLevel /etc/ssh/sshd_config.d/00-complianceascode-hardening.conf



If a line indicating VERBOSE is returned, then the required value is set.

      Is it the case that the required value is not set?
 SRG-OS-000032-GPOS-00013 AC-17(a), AC-17(1), CM-6(a)
xccdf_org.ssgproject.content_rule_sshd_x11_use_localhost medium Prevent remote hosts from connecting to the proxy display When X11 forwarding is enabled, there may be additional exposure to the server and client displays if the sshd proxy display is configured to listen on the wildcard address. By default, sshd binds the forwarding server to the loopback address and sets the hostname part of the DISPLAY environment variable to localhost. This prevents remote hosts from connecting to the proxy display. The SSH daemon should prevent remote hosts from connecting to the proxy display.
The default SSH configuration for X11UseLocalhost is yes, which prevents remote hosts from connecting to the proxy display.
To explicitly prevent remote connections to the proxy display, add or correct the following line in /etc/ssh/sshd_config.d/00-complianceascode-hardening.conf: X11UseLocalhost yes		 
To determine how the SSH daemon's X11UseLocalhost option is set, run the following command:


$ sudo grep -i X11UseLocalhost /etc/ssh/sshd_config.d/00-complianceascode-hardening.conf


$ sudo grep -i X11UseLocalhost /etc/ssh/sshd_config.d/01-complianceascode-reinforce-os-defaults.conf


If a line indicating yes is returned, then the required value is set.
      Is it the case that the display proxy is listening on wildcard address?
 SRG-OS-000480-GPOS-00227 CM-6(b)
xccdf_org.ssgproject.content_rule_sssd_certificate_verification medium Certificate status checking in SSSD Ensuring that multifactor solutions certificates are checked via Online Certificate Status Protocol (OCSP) ensures the security of the system. Multifactor solutions that require devices separate from information systems gaining access include, for example, hardware tokens providing time-based or challenge-response authenticators and smart cards. Configuring certificate_verification to ocsp_dgst=sha512 ensures that certificates for multifactor solutions are checked via Online Certificate Status Protocol (OCSP). 
Check to see 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 "^#"

If configured properly, output should look like

    certificate_verification = ocsp_dgst=sha512


      Is it the case that certificate_verification in sssd is not configured?
 SRG-OS-000375-GPOS-00160, SRG-OS-000377-GPOS-00162 IA-2(11)
xccdf_org.ssgproject.content_rule_sssd_enable_certmap medium Enable Certmap in SSSD Without mapping the certificate used to authenticate to the user account, the ability to determine the identity of the individual user or group will not be available for forensic analysis. SSSD should be configured to verify the certificate of the user or group. To set this up ensure that section like certmap/testing.test/rule_name is setup in /etc/sssd/sssd.conf. For example 
[certmap/testing.test/rule_name]
matchrule =<SAN>.*EDIPI@mil
maprule = (userCertificate;binary={cert!bin})
domains = testing.test

To verify Certmap is enabled in SSSD, run the following command:

$ sudo cat /etc/sssd/sssd.conf

If configured properly, output should contain section like the following

[certmap/testing.test/rule_name]
matchrule =<SAN>.*EDIPI@mil
maprule = (userCertificate;binary={cert!bin})
domains = testing.test


      Is it the case that Certmap is not configured in SSSD?
 SRG-OS-000068-GPOS-00036 IA-5 (2) (c)
xccdf_org.ssgproject.content_rule_sssd_enable_smartcards medium Enable Smartcards in SSSD Using an authentication device, such as a CAC or token that is separate from the information system, ensures that even if the information system is compromised, that compromise will not affect credentials stored on the authentication device.

Multi-Factor Authentication (MFA) solutions that require devices separate from information systems gaining access include, for example, hardware tokens providing time-based or challenge-response authenticators and smart cards or similar secure authentication devices issued by an organization or identity provider.		 SSSD should be configured to authenticate access to the system using smart cards. To enable smart cards in SSSD, set pam_cert_auth to True under the [pam] section in /etc/sssd/sssd.conf. For example: 
[pam]
pam_cert_auth = True
Add or update "pam_sss.so" line in auth section of "/etc/pam.d/system-auth" file to include "try_cert_auth" or "require_cert_auth" option, like in the following example: 
/etc/pam.d/system-auth:auth [success=done authinfo_unavail=ignore ignore=ignore default=die] pam_sss.so try_cert_auth
Also add or update "pam_sss.so" line in auth section of "/etc/pam.d/smartcard-auth" file to include the "allow_missing_name" option, like in the following example: 
/etc/pam.d/smartcard-auth:auth sufficient pam_sss.so allow_missing_name
 
To verify that smart cards are enabled in SSSD, run the following command:

$ sudo grep pam_cert_auth /etc/sssd/sssd.conf

If configured properly, output should be

pam_cert_auth = True



To verify that smart cards are enabled in PAM files, run the following command:

$ sudo grep -e "auth.*pam_sss\.so.*\(allow_missing_name\|try_cert_auth\)" /etc/pam.d/smartcard-auth /etc/pam.d/system-auth

If configured properly, output should be

/etc/pam.d/smartcard-auth:auth        sufficient                                   pam_sss.so allow_missing_name
/etc/pam.d/system-auth:auth        [success=done authinfo_unavail=ignore ignore=ignore default=die] pam_sss.so try_cert_auth


      Is it the case that smart cards are not enabled in SSSD?
 SRG-OS-000375-GPOS-00160, SRG-OS-000105-GPOS-00052, SRG-OS-000106-GPOS-00053, SRG-OS-000107-GPOS-00054, SRG-OS-000108-GPOS-00055
xccdf_org.ssgproject.content_rule_sssd_has_trust_anchor medium SSSD Has a Correct Trust Anchor Without path validation, an informed trust decision by the relying party cannot be made when presented with any certificate not already explicitly trusted. A trust anchor is an authoritative entity represented via a public key and associated data. It is used in the context of public key infrastructures, X.509 digital certificates, and DNSSEC. When there is a chain of trust, usually the top entity to be trusted becomes the trust anchor; it can be, for example, a Certification Authority (CA). A certification path starts with the subject certificate and proceeds through a number of intermediate certificates up to a trusted root certificate, typically issued by a trusted CA. This requirement verifies that a certification path to an accepted trust anchor is used for certificate validation and that the path includes status information. Path validation is necessary for a relying party to make an informed trust decision when presented with any certificate not already explicitly trusted. Status information for certification paths includes certificate revocation lists or online certificate status protocol responses. Validation of the certificate status information is out of scope for this requirement. SSSD must have acceptable trust anchor present. 
Verify Oracle Linux 9 for PKI-based authentication has valid certificates by constructing a
certification path (which includes status information) to an accepted trust anchor.

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
      Is it the case that root CA file is not a DoD-issued certificate with a valid date and installed in the /etc/sssd/pki/sssd_auth_ca_db.pem location?
 SRG-OS-000066-GPOS-00034, SRG-OS-000384-GPOS-00167 IA-5 (2) (a)
xccdf_org.ssgproject.content_rule_sssd_offline_cred_expiration medium Configure SSSD to Expire Offline Credentials If cached authentication information is out-of-date, the validity of the authentication information may be questionable. SSSD should be configured to expire offline credentials after 1 day. Check if SSSD allows cached authentications with the following command: 
$ sudo grep cache_credentials /etc/sssd/sssd.conf
cache_credentials = true
If "cache_credentials" is set to "false" or is missing no further checks are required.
To configure SSSD to expire offline credentials, set offline_credentials_expiration to 1 under the [pam] section in /etc/sssd/sssd.conf. For example: 
[pam]
offline_credentials_expiration = 1

Check if SSSD allows cached authentications with the following command:

$ sudo grep cache_credentials /etc/sssd/sssd.conf
cache_credentials = true


If "cache_credentials" is set to "false" or is missing no further checks are required.


To verify that SSSD expires offline credentials, run the following command:

$ sudo grep offline_credentials_expiration /etc/sssd/sssd.conf /etc/sssd/conf.d/*.conf

If configured properly, output should be

offline_credentials_expiration = 1

      Is it the case that it does not exist or is not configured properly?
 SRG-OS-000383-GPOS-00166 CM-6(a), IA-5(13)
xccdf_org.ssgproject.content_rule_sudo_remove_no_authenticate medium Ensure Users Re-Authenticate for Privilege Escalation - sudo !authenticate Without re-authentication, users may access resources or perform tasks for which they do not have authorization.

When operating systems provide the capability to escalate a functional capability, it is critical that the user re-authenticate.		 The sudo !authenticate option, when specified, allows a user to execute commands using sudo without having to authenticate. This should be disabled by making sure that the !authenticate option does not exist in /etc/sudoers configuration file or any sudo configuration snippets in /etc/sudoers.d/. 
To determine if !authenticate has not been configured for sudo, run the following command:

$ sudo grep -r \!authenticate /etc/sudoers /etc/sudoers.d/

The command should return no output.
      Is it the case that !authenticate is specified in the sudo config files?
 SRG-OS-000373-GPOS-00156, SRG-OS-000373-GPOS-00157, SRG-OS-000373-GPOS-00158 IA-11, CM-6(a)
xccdf_org.ssgproject.content_rule_sudo_remove_nopasswd medium Ensure Users Re-Authenticate for Privilege Escalation - sudo NOPASSWD Without re-authentication, users may access resources or perform tasks for which they do not have authorization.

When operating systems provide the capability to escalate a functional capability, it is critical that the user re-authenticate.		 The sudo NOPASSWD tag, when specified, allows a user to execute commands using sudo without having to authenticate. This should be disabled by making sure that the NOPASSWD tag does not exist in /etc/sudoers configuration file or any sudo configuration snippets in /etc/sudoers.d/. 
To determine if NOPASSWD has been configured for sudo, run the following command:

$ sudo grep -ri nopasswd /etc/sudoers /etc/sudoers.d/

The command should return no output.
      Is it the case that nopasswd is specified in the sudo config files?
 SRG-OS-000373-GPOS-00156, SRG-OS-000373-GPOS-00157, SRG-OS-000373-GPOS-00158 IA-11, CM-6(a)
xccdf_org.ssgproject.content_rule_sudo_require_reauthentication medium Require Re-Authentication When Using the sudo Command Without re-authentication, users may access resources or perform tasks for which they do not have authorization.

When operating systems provide the capability to escalate a functional capability, it is critical that the user re-authenticate.		 The sudo timestamp_timeout tag sets the amount of time sudo password prompt waits. The default timestamp_timeout value is 5 minutes. The timestamp_timeout should be configured by making sure that the timestamp_timeout tag exists in /etc/sudoers configuration file or any sudo configuration snippets in /etc/sudoers.d/. If the value is set to an integer less than 0, the user's time stamp will not expire and the user will not have to re-authenticate for privileged actions until the user's session is terminated. 
Verify the operating system requires re-authentication
when using the "sudo" command to elevate privileges, run the following command:

sudo grep -ri '^Defaults.*timestamp_timeout' /etc/sudoers /etc/sudoers.d

The output should be:

/etc/sudoers:Defaults timestamp_timeout=0
 or "timestamp_timeout" is set to a positive number.
If conflicting results are returned, this is a finding.
      Is it the case that timestamp_timeout is not set with the appropriate value for sudo?
 SRG-OS-000373-GPOS-00156, SRG-OS-000373-GPOS-00157, SRG-OS-000373-GPOS-00158 IA-11
xccdf_org.ssgproject.content_rule_sudo_restrict_privilege_elevation_to_authorized medium The operating system must restrict privilege elevation to authorized personnel If the "sudoers" file is not configured correctly, any user defined on the system can initiate privileged actions on the target system. The sudo command allows a user to execute programs with elevated (administrator) privileges. It prompts the user for their password and confirms your request to execute a command by checking a file, called sudoers. Restrict privileged actions by removing the following entries from the sudoers file: ALL ALL=(ALL) ALL ALL ALL=(ALL:ALL) ALL 
Determine if "sudoers" file restricts sudo access run the following commands:

$ sudo grep -PR '^\s*ALL\s+ALL\=\(ALL\)\s+ALL\s*$' /etc/sudoers /etc/sudoers.d/*


$ sudo grep -PR '^\s*ALL\s+ALL\=\(ALL\:ALL\)\s+ALL\s*$' /etc/sudoers /etc/sudoers.d/*

      Is it the case that either of the commands returned a line?
 SRG-OS-000480-GPOS-00227 CM-6(b), CM-6(iv)
xccdf_org.ssgproject.content_rule_sudoers_validate_passwd medium Ensure invoking users password for privilege escalation when using sudo If the rootpw, targetpw, or runaspw flags are defined and not disabled, by default the operating system will prompt the invoking user for the "root" user password. The sudoers security policy requires that users authenticate themselves before they can use sudo. When sudoers requires authentication, it validates the invoking user's credentials. The expected output for: 
 sudo cvtsudoers -f sudoers /etc/sudoers | grep -E '^Defaults !?(rootpw|targetpw|runaspw)$' 
 Defaults !targetpw
      Defaults !rootpw
      Defaults !runaspw
or if cvtsudoers not supported: 
 sudo find /etc/sudoers /etc/sudoers.d \( \! -name '*~' -a \! -name '*.*' \) -exec grep -E --with-filename '^[[:blank:]]*Defaults[[:blank:]](.*[[:blank:]])?!?\b(rootpw|targetpw|runaspw)' -- {} \; 
 /etc/sudoers:Defaults !targetpw
      /etc/sudoers:Defaults !rootpw
      /etc/sudoers:Defaults !runaspw 
Run the following command to Verify that the sudoers security policy is configured to use the invoking user's password for privilege escalation:

 sudo cvtsudoers -f sudoers /etc/sudoers | grep -E '^Defaults !?(rootpw|targetpw|runaspw)' 

or if cvtsudoers not supported:

 sudo find /etc/sudoers /etc/sudoers.d \( \! -name '*~' -a \! -name '*.*' \) -exec grep -E --with-filename '^[[:blank:]]*Defaults[[:blank:]](.*[[:blank:]])?!?\b(rootpw|targetpw|runaspw)' -- {} \; 

If no results are returned, this is a finding.
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.
      Is it the case that invoke user passwd when using sudo?
 SRG-OS-000480-GPOS-00227 CM-6(b), CM-6.1(iv)
xccdf_org.ssgproject.content_rule_sysctl_crypto_fips_enabled high Set kernel parameter 'crypto.fips_enabled' to 1 Use of weak or untested encryption algorithms undermines the purposes of utilizing encryption to protect data. The operating system must implement cryptographic modules adhering to the higher standards approved by the federal government since this provides assurance they have been tested and validated. System running in FIPS mode is indicated by kernel parameter 'crypto.fips_enabled'. This parameter should be set to 1 in FIPS mode. To enable FIPS mode, run the following command: 
fips-mode-setup --enable
To enable strict FIPS compliance, the fips=1 kernel option needs to 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.		 
To verify that kernel parameter 'crypto.fips_enabled' is set properly, run the following command:

sysctl crypto.fips_enabled

The output should contain the following:

crypto.fips_enabled = 1

      Is it the case that crypto.fips_enabled is not 1?
 SRG-OS-000033-GPOS-00014, SRG-OS-000125-GPOS-00065, SRG-OS-000250-GPOS-00093, SRG-OS-000393-GPOS-00173, SRG-OS-000394-GPOS-00174, SRG-OS-000396-GPOS-00176, SRG-OS-000423-GPOS-00187, SRG-OS-000478-GPOS-00223 SC-12(2), SC-12(3), IA-7, SC-13, CM-6(a), SC-12
xccdf_org.ssgproject.content_rule_sysctl_fs_protected_hardlinks medium Enable Kernel Parameter to Enforce DAC on Hardlinks By enabling this kernel parameter, users can no longer create soft or hard links to files which they do not own. Disallowing such hardlinks mitigate vulnerabilities based on insecure file system accessed by privileged programs, avoiding an exploitation vector exploiting unsafe use of open() or creat(). To set the runtime status of the fs.protected_hardlinks kernel parameter, run the following command: 
$ sudo sysctl -w fs.protected_hardlinks=1
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d: 
fs.protected_hardlinks = 1
 
The runtime status of the fs.protected_hardlinks kernel parameter can be queried
by running the following command:

$ sysctl fs.protected_hardlinks

1.

      Is it the case that the correct value is not returned?
 SRG-OS-000312-GPOS-00122, SRG-OS-000312-GPOS-00123, SRG-OS-000324-GPOS-00125 CM-6(a), AC-6(1)
xccdf_org.ssgproject.content_rule_sysctl_fs_protected_symlinks medium Enable Kernel Parameter to Enforce DAC on Symlinks By enabling this kernel parameter, symbolic links are permitted to be followed only when outside a sticky world-writable directory, or when the UID of the link and follower match, or when the directory owner matches the symlink's owner. Disallowing such symlinks helps mitigate vulnerabilities based on insecure file system accessed by privileged programs, avoiding an exploitation vector exploiting unsafe use of open() or creat(). To set the runtime status of the fs.protected_symlinks kernel parameter, run the following command: 
$ sudo sysctl -w fs.protected_symlinks=1
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d: 
fs.protected_symlinks = 1
 
The runtime status of the fs.protected_symlinks kernel parameter can be queried
by running the following command:

$ sysctl fs.protected_symlinks

1.

      Is it the case that the correct value is not returned?
 SRG-OS-000312-GPOS-00122, SRG-OS-000312-GPOS-00123, SRG-OS-000324-GPOS-00125 CM-6(a), AC-6(1)
xccdf_org.ssgproject.content_rule_sysctl_kernel_core_pattern medium Disable storing core dumps A core dump includes a memory image taken at the time the operating system terminates an application. The memory image could contain sensitive data and is generally useful only for developers trying to debug problems. To set the runtime status of the kernel.core_pattern kernel parameter, run the following command: 
$ sudo sysctl -w kernel.core_pattern=|/bin/false
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d: 
kernel.core_pattern = |/bin/false
 
The runtime status of the kernel.core_pattern kernel parameter can be queried
by running the following command:

$ sysctl kernel.core_pattern

|/bin/false.

      Is it the case that 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?
 SRG-OS-000480-GPOS-00227 SC-7(10)
xccdf_org.ssgproject.content_rule_sysctl_kernel_dmesg_restrict low Restrict Access to Kernel Message Buffer Unprivileged access to the kernel syslog can expose sensitive kernel address information. To set the runtime status of the kernel.dmesg_restrict kernel parameter, run the following command: 
$ sudo sysctl -w kernel.dmesg_restrict=1
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d: 
kernel.dmesg_restrict = 1
 
The runtime status of the kernel.dmesg_restrict kernel parameter can be queried
by running the following command:

$ sysctl kernel.dmesg_restrict

1.

      Is it the case that the correct value is not returned?
 SRG-OS-000132-GPOS-00067, SRG-OS-000138-GPOS-00069, SRG-APP-000243-CTR-000600 SI-11(a), SI-11(b)
xccdf_org.ssgproject.content_rule_sysctl_kernel_exec_shield medium Enable ExecShield via sysctl ExecShield uses the segmentation feature on all x86 systems to prevent execution in memory higher than a certain address. It writes an address as a limit in the code segment descriptor, to control where code can be executed, on a per-process basis. When the kernel places a process's memory regions such as the stack and heap higher than this address, the hardware prevents execution in that address range. This is enabled by default on the latest Red Hat and Fedora systems if supported by the hardware. By default on Oracle Linux 9 64-bit systems, ExecShield is enabled and can only be disabled if the hardware does not support ExecShield or is disabled in /etc/default/grub. 
To verify ExecShield is enabled on 64-bit Oracle Linux 9 systems,
run the following command:

$ dmesg | grep '[NX|DX]*protection'

The output should not contain 'disabled by kernel command line option'.
Inspect the form of default GRUB 2 command line for the Linux operating system
in /etc/default/grub. If it includes noexec=off,
then the parameter will be configured for newly installed kernels.
First check if the GRUB recovery is enabled:

$ sudo grep 'GRUB_DISABLE_RECOVERY' /etc/default/grub

If this option is set to true, then check that a line is output by the following command:

$ sudo grep 'GRUB_CMDLINE_LINUX_DEFAULT.*noexec=off.*' /etc/default/grub

If the recovery is disabled, check the line with

$ sudo grep 'GRUB_CMDLINE_LINUX.*noexec=off.*' /etc/default/grub
.Moreover, command line parameters for currently installed kernels should be checked as well.
Run the following command:

$ sudo grubby --info=ALL | grep args | grep -v 'noexec=off'

The command should not return any output.
      Is it the case that ExecShield is not supported by the hardware, is not enabled, or has been disabled by the kernel configuration.?
 SRG-OS-000433-GPOS-00192 SC-39, CM-6(a)
xccdf_org.ssgproject.content_rule_sysctl_kernel_kexec_load_disabled medium Disable Kernel Image Loading Disabling kexec_load allows greater control of the kernel memory. It makes it impossible to load another kernel image after it has been disabled. To set the runtime status of the kernel.kexec_load_disabled kernel parameter, run the following command: 
$ sudo sysctl -w kernel.kexec_load_disabled=1
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d: 
kernel.kexec_load_disabled = 1
 
The runtime status of the kernel.kexec_load_disabled kernel parameter can be queried
by running the following command:

$ sysctl kernel.kexec_load_disabled

1.

      Is it the case that the correct value is not returned?
 SRG-OS-000480-GPOS-00227, SRG-OS-000366-GPOS-00153 CM-6
xccdf_org.ssgproject.content_rule_sysctl_kernel_kptr_restrict medium Restrict Exposed Kernel Pointer Addresses Access Exposing kernel pointers (through procfs or seq_printf()) exposes kernel writeable structures which may contain functions pointers. If a write vulnerability occurs in the kernel, allowing write access to any of this structure, the kernel can be compromised. This option disallow any program without the CAP_SYSLOG capability to get the addresses of kernel pointers by replacing them with 0. To set the runtime status of the kernel.kptr_restrict kernel parameter, run the following command: 
$ sudo sysctl -w kernel.kptr_restrict=None
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d: 
kernel.kptr_restrict = None
 
The runtime status of the kernel.kptr_restrict kernel parameter can be queried
by running the following command:

$ sysctl kernel.kptr_restrict

The output of the command should indicate either:
kernel.kptr_restrict = 1
or:
kernel.kptr_restrict = 2
The output of the command should not indicate:
kernel.kptr_restrict = 0

The preferable way how to assure the runtime compliance is to have
correct persistent configuration, and rebooting the system.

The persistent kernel parameter configuration is performed by specifying the appropriate
assignment in any file located in the 
/etc/sysctl.d
 directory.
Verify that there is not any existing incorrect configuration by executing the following command:

$ grep -r '^\s*kernel.kptr_restrict\s*=' /etc/sysctl.conf /etc/sysctl.d

The command should not find any assignments other than:
kernel.kptr_restrict = 1
or:
kernel.kptr_restrict = 2

Conflicting assignments are not allowed.
      Is it the case that the kernel.kptr_restrict is not set to 1 or 2 or is configured to be 0?
 SRG-OS-000132-GPOS-00067, SRG-OS-000433-GPOS-00192, SRG-OS-000480-GPOS-00227 SC-30, SC-30(2), SC-30(5), CM-6(a)
xccdf_org.ssgproject.content_rule_sysctl_kernel_perf_event_paranoid low Disallow kernel profiling by unprivileged users Kernel profiling can reveal sensitive information about kernel behaviour. To set the runtime status of the kernel.perf_event_paranoid kernel parameter, run the following command: 
$ sudo sysctl -w kernel.perf_event_paranoid=2
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d: 
kernel.perf_event_paranoid = 2
 
The runtime status of the kernel.perf_event_paranoid kernel parameter can be queried
by running the following command:

$ sysctl kernel.perf_event_paranoid

2.

      Is it the case that the correct value is not returned?
 SRG-OS-000132-GPOS-00067, SRG-OS-000138-GPOS-00069, SRG-APP-000243-CTR-000600 AC-6
xccdf_org.ssgproject.content_rule_sysctl_kernel_randomize_va_space medium Enable Randomized Layout of Virtual Address Space Address space layout randomization (ASLR) makes it more difficult for an attacker to predict the location of attack code they have introduced into a process's address space during an attempt at exploitation. Additionally, ASLR makes it more difficult for an attacker to know the location of existing code in order to re-purpose it using return oriented programming (ROP) techniques. To set the runtime status of the kernel.randomize_va_space kernel parameter, run the following command: 
$ sudo sysctl -w kernel.randomize_va_space=2
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d: 
kernel.randomize_va_space = 2
 
The runtime status of the kernel.randomize_va_space kernel parameter can be queried
by running the following command:

$ sysctl kernel.randomize_va_space

2.

      Is it the case that the correct value is not returned?
 SRG-OS-000433-GPOS-00193, SRG-OS-000480-GPOS-00227, SRG-APP-000450-CTR-001105 SC-30, SC-30(2), CM-6(a)
xccdf_org.ssgproject.content_rule_sysctl_kernel_unprivileged_bpf_disabled medium Disable Access to Network bpf() Syscall From Unprivileged Processes Loading and accessing the packet filters programs and maps using the bpf() syscall has the potential of revealing sensitive information about the kernel state. To set the runtime status of the kernel.unprivileged_bpf_disabled kernel parameter, run the following command: 
$ sudo sysctl -w kernel.unprivileged_bpf_disabled=1
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d: 
kernel.unprivileged_bpf_disabled = 1
 
The runtime status of the kernel.unprivileged_bpf_disabled kernel parameter can be queried
by running the following command:

$ sysctl kernel.unprivileged_bpf_disabled

1.

      Is it the case that the correct value is not returned?
 SRG-OS-000132-GPOS-00067, SRG-OS-000480-GPOS-00227 AC-6, SC-7(10)
xccdf_org.ssgproject.content_rule_sysctl_kernel_yama_ptrace_scope medium Restrict usage of ptrace to descendant processes Unrestricted usage of ptrace allows compromised binaries to run ptrace on another processes of the user. Like this, the attacker can steal sensitive information from the target processes (e.g. SSH sessions, web browser, ...) without any additional assistance from the user (i.e. without resorting to phishing). To set the runtime status of the kernel.yama.ptrace_scope kernel parameter, run the following command: 
$ sudo sysctl -w kernel.yama.ptrace_scope=1
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d: 
kernel.yama.ptrace_scope = 1
 
The runtime status of the kernel.yama.ptrace_scope kernel parameter can be queried
by running the following command:

$ sysctl kernel.yama.ptrace_scope

1.

      Is it the case that the correct value is not returned?
 SRG-OS-000132-GPOS-00067, SRG-OS-000480-GPOS-00227 SC-7(10)
xccdf_org.ssgproject.content_rule_sysctl_net_core_bpf_jit_harden medium Harden the operation of the BPF just-in-time compiler When hardened, the extended Berkeley Packet Filter just-in-time compiler will randomize any kernel addresses in the BPF programs and maps, and will not expose the JIT addresses in /proc/kallsyms. To set the runtime status of the net.core.bpf_jit_harden kernel parameter, run the following command: 
$ sudo sysctl -w net.core.bpf_jit_harden=2
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d: 
net.core.bpf_jit_harden = 2
 
The runtime status of the net.core.bpf_jit_harden kernel parameter can be queried
by running the following command:

$ sysctl net.core.bpf_jit_harden

2.

      Is it the case that the correct value is not returned?
 SRG-OS-000480-GPOS-00227 CM-6, SC-7(10)
xccdf_org.ssgproject.content_rule_sysctl_net_ipv4_conf_all_accept_redirects medium Disable Accepting ICMP Redirects for All IPv4 Interfaces ICMP redirect messages are used by routers to inform hosts that a more direct route exists for a particular destination. These messages modify the host's route table and are unauthenticated. An illicit ICMP redirect message could result in a man-in-the-middle attack.
This feature of the IPv4 protocol has few legitimate uses. It should be disabled unless absolutely required."		 To set the runtime status of the net.ipv4.conf.all.accept_redirects kernel parameter, run the following command: 
$ sudo sysctl -w net.ipv4.conf.all.accept_redirects=0
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d: 
net.ipv4.conf.all.accept_redirects = 0
 
The runtime status of the net.ipv4.conf.all.accept_redirects kernel parameter can be queried
by running the following command:

$ sysctl net.ipv4.conf.all.accept_redirects

0.

      Is it the case that the correct value is not returned?
 SRG-OS-000480-GPOS-00227 CM-7(a), CM-7(b), CM-6(a), SC-7(a)
xccdf_org.ssgproject.content_rule_sysctl_net_ipv4_conf_all_accept_source_route medium Disable Kernel Parameter for Accepting Source-Routed Packets on all IPv4 Interfaces Source-routed packets allow the source of the packet to suggest routers forward the packet along a different path than configured on the router, which can be used to bypass network security measures. This requirement applies only to the forwarding of source-routerd traffic, such as when IPv4 forwarding is enabled and the system is functioning as a router.

Accepting source-routed packets in the IPv4 protocol has few legitimate uses. It should be disabled unless it is absolutely required.		 To set the runtime status of the net.ipv4.conf.all.accept_source_route kernel parameter, run the following command: 
$ sudo sysctl -w net.ipv4.conf.all.accept_source_route=0
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d: 
net.ipv4.conf.all.accept_source_route = 0
 
The runtime status of the net.ipv4.conf.all.accept_source_route kernel parameter can be queried
by running the following command:

$ sysctl net.ipv4.conf.all.accept_source_route

0.

      Is it the case that the correct value is not returned?
 SRG-OS-000480-GPOS-00227 CM-7(a), CM-7(b), SC-5, CM-6(a), SC-7(a)
xccdf_org.ssgproject.content_rule_sysctl_net_ipv4_conf_all_forwarding medium Disable Kernel Parameter for IPv4 Forwarding on all IPv4 Interfaces IP forwarding permits the kernel to forward packets from one network interface to another. The ability to forward packets between two networks is only appropriate for systems acting as routers. To set the runtime status of the net.ipv4.conf.all.forwarding kernel parameter, run the following command: 
$ sudo sysctl -w net.ipv4.conf.all.forwarding=0
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d: 
net.ipv4.conf.all.forwarding = 0
 
The runtime status of the net.ipv4.conf.all.forwarding kernel parameter can be queried
by running the following command:

$ sysctl net.ipv4.conf.all.forwarding

0.
The ability to forward packets is only appropriate for routers.
      Is it the case that IP forwarding value is "1" and the system is not router?
 SRG-OS-000480-GPOS-00227 CM-6(b)
xccdf_org.ssgproject.content_rule_sysctl_net_ipv4_conf_all_log_martians unknown Enable Kernel Parameter to Log Martian Packets on all IPv4 Interfaces The presence of "martian" packets (which have impossible addresses) as well as spoofed packets, source-routed packets, and redirects could be a sign of nefarious network activity. Logging these packets enables this activity to be detected. To set the runtime status of the net.ipv4.conf.all.log_martians kernel parameter, run the following command: 
$ sudo sysctl -w net.ipv4.conf.all.log_martians=1
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d: 
net.ipv4.conf.all.log_martians = 1
 
The runtime status of the net.ipv4.conf.all.log_martians kernel parameter can be queried
by running the following command:

$ sysctl net.ipv4.conf.all.log_martians

1.

      Is it the case that the correct value is not returned?
 SRG-OS-000480-GPOS-00227 CM-7(a), CM-7(b), SC-5(3)(a)
xccdf_org.ssgproject.content_rule_sysctl_net_ipv4_conf_all_rp_filter medium Enable Kernel Parameter to Use Reverse Path Filtering on all IPv4 Interfaces Enabling reverse path filtering drops packets with source addresses that should not have been able to be received on the interface they were received on. It should not be used on systems which are routers for complicated networks, but is helpful for end hosts and routers serving small networks. To set the runtime status of the net.ipv4.conf.all.rp_filter kernel parameter, run the following command: 
$ sudo sysctl -w net.ipv4.conf.all.rp_filter=1
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d: 
net.ipv4.conf.all.rp_filter = 1
 
The runtime status of the net.ipv4.conf.all.rp_filter parameter can be queried
by running the following command:

$ sysctl net.ipv4.conf.all.rp_filter

The output of the command should indicate either:
net.ipv4.conf.all.rp_filter = 1

The output of the command should not indicate:
net.ipv4.conf.all.rp_filter = 0

The preferable way how to assure the runtime compliance is to have
correct persistent configuration, and rebooting the system.

The persistent sysctl parameter configuration is performed by specifying the appropriate
assignment in any file located in the 
/etc/sysctl.d
 directory.
Verify that there is not any existing incorrect configuration by executing the following command:

$ grep -r '^\s*net.ipv4.conf.all.rp_filter\s*=' /etc/sysctl.conf /etc/sysctl.d

The command should not find any assignments other than:
net.ipv4.conf.all.rp_filter = 1


Conflicting assignments are not allowed.
      Is it the case that the net.ipv4.conf.all.rp_filter is not set to 1 or is configured to be 0 or 2?
 SRG-OS-000480-GPOS-00227 CM-7(a), CM-7(b), CM-6(a), SC-7(a)
xccdf_org.ssgproject.content_rule_sysctl_net_ipv4_conf_all_send_redirects medium Disable Kernel Parameter for Sending ICMP Redirects on all IPv4 Interfaces ICMP redirect messages are used by routers to inform hosts that a more direct route exists for a particular destination. These messages contain information from the system's route table possibly revealing portions of the network topology.
The ability to send ICMP redirects is only appropriate for systems acting as routers.		 To set the runtime status of the net.ipv4.conf.all.send_redirects kernel parameter, run the following command: 
$ sudo sysctl -w net.ipv4.conf.all.send_redirects=0
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d: 
net.ipv4.conf.all.send_redirects = 0
 
The runtime status of the net.ipv4.conf.all.send_redirects kernel parameter can be queried
by running the following command:

$ sysctl net.ipv4.conf.all.send_redirects

0.

      Is it the case that the correct value is not returned?
 SRG-OS-000480-GPOS-00227 CM-7(a), CM-7(b), SC-5, CM-6(a), SC-7(a)
xccdf_org.ssgproject.content_rule_sysctl_net_ipv4_conf_default_accept_redirects medium Disable Kernel Parameter for Accepting ICMP Redirects by Default on IPv4 Interfaces ICMP redirect messages are used by routers to inform hosts that a more direct route exists for a particular destination. These messages modify the host's route table and are unauthenticated. An illicit ICMP redirect message could result in a man-in-the-middle attack.
This feature of the IPv4 protocol has few legitimate uses. It should be disabled unless absolutely required.		 To set the runtime status of the net.ipv4.conf.default.accept_redirects kernel parameter, run the following command: 
$ sudo sysctl -w net.ipv4.conf.default.accept_redirects=0
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d: 
net.ipv4.conf.default.accept_redirects = 0
 
The runtime status of the net.ipv4.conf.default.accept_redirects kernel parameter can be queried
by running the following command:

$ sysctl net.ipv4.conf.default.accept_redirects

0.

      Is it the case that the correct value is not returned?
 SRG-OS-000480-GPOS-00227 CM-7(a), CM-7(b), CM-6(a), SC-7(a)
xccdf_org.ssgproject.content_rule_sysctl_net_ipv4_conf_default_accept_source_route medium Disable Kernel Parameter for Accepting Source-Routed Packets on IPv4 Interfaces by Default Source-routed packets allow the source of the packet to suggest routers forward the packet along a different path than configured on the router, which can be used to bypass network security measures.
Accepting source-routed packets in the IPv4 protocol has few legitimate uses. It should be disabled unless it is absolutely required, such as when IPv4 forwarding is enabled and the system is legitimately functioning as a router.		 To set the runtime status of the net.ipv4.conf.default.accept_source_route kernel parameter, run the following command: 
$ sudo sysctl -w net.ipv4.conf.default.accept_source_route=0
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d: 
net.ipv4.conf.default.accept_source_route = 0
 
The runtime status of the net.ipv4.conf.default.accept_source_route kernel parameter can be queried
by running the following command:

$ sysctl net.ipv4.conf.default.accept_source_route

0.

      Is it the case that the correct value is not returned?
 SRG-OS-000480-GPOS-00227 CM-7(a), CM-7(b), SC-5, SC-7(a)
xccdf_org.ssgproject.content_rule_sysctl_net_ipv4_conf_default_log_martians unknown Enable Kernel Parameter to Log Martian Packets on all IPv4 Interfaces by Default The presence of "martian" packets (which have impossible addresses) as well as spoofed packets, source-routed packets, and redirects could be a sign of nefarious network activity. Logging these packets enables this activity to be detected. To set the runtime status of the net.ipv4.conf.default.log_martians kernel parameter, run the following command: 
$ sudo sysctl -w net.ipv4.conf.default.log_martians=1
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d: 
net.ipv4.conf.default.log_martians = 1
 
The runtime status of the net.ipv4.conf.default.log_martians kernel parameter can be queried
by running the following command:

$ sysctl net.ipv4.conf.default.log_martians

1.

      Is it the case that the correct value is not returned?
 SRG-OS-000480-GPOS-00227 CM-7(a), CM-7(b), SC-5(3)(a)
xccdf_org.ssgproject.content_rule_sysctl_net_ipv4_conf_default_rp_filter medium Enable Kernel Parameter to Use Reverse Path Filtering on all IPv4 Interfaces by Default Enabling reverse path filtering drops packets with source addresses that should not have been able to be received on the interface they were received on. It should not be used on systems which are routers for complicated networks, but is helpful for end hosts and routers serving small networks. To set the runtime status of the net.ipv4.conf.default.rp_filter kernel parameter, run the following command: 
$ sudo sysctl -w net.ipv4.conf.default.rp_filter=1
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d: 
net.ipv4.conf.default.rp_filter = 1
 
The runtime status of the net.ipv4.conf.default.rp_filter kernel parameter can be queried
by running the following command:

$ sysctl net.ipv4.conf.default.rp_filter

1.

      Is it the case that the correct value is not returned?
 SRG-OS-000480-GPOS-00227 CM-7(a), CM-7(b), CM-6(a), SC-7(a)
xccdf_org.ssgproject.content_rule_sysctl_net_ipv4_conf_default_send_redirects medium Disable Kernel Parameter for Sending ICMP Redirects on all IPv4 Interfaces by Default ICMP redirect messages are used by routers to inform hosts that a more direct route exists for a particular destination. These messages contain information from the system's route table possibly revealing portions of the network topology.
The ability to send ICMP redirects is only appropriate for systems acting as routers.		 To set the runtime status of the net.ipv4.conf.default.send_redirects kernel parameter, run the following command: 
$ sudo sysctl -w net.ipv4.conf.default.send_redirects=0
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d: 
net.ipv4.conf.default.send_redirects = 0
 
The runtime status of the net.ipv4.conf.default.send_redirects kernel parameter can be queried
by running the following command:

$ sysctl net.ipv4.conf.default.send_redirects

0.

      Is it the case that the correct value is not returned?
 SRG-OS-000480-GPOS-00227 CM-7(a), CM-7(b), SC-5, CM-6(a), SC-7(a)
xccdf_org.ssgproject.content_rule_sysctl_net_ipv4_icmp_echo_ignore_broadcasts medium Enable Kernel Parameter to Ignore ICMP Broadcast Echo Requests on IPv4 Interfaces Responding to broadcast (ICMP) echoes facilitates network mapping and provides a vector for amplification attacks.
Ignoring ICMP echo requests (pings) sent to broadcast or multicast addresses makes the system slightly more difficult to enumerate on the network.		 To set the runtime status of the net.ipv4.icmp_echo_ignore_broadcasts kernel parameter, run the following command: 
$ sudo sysctl -w net.ipv4.icmp_echo_ignore_broadcasts=1
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d: 
net.ipv4.icmp_echo_ignore_broadcasts = 1
 
The runtime status of the net.ipv4.icmp_echo_ignore_broadcasts kernel parameter can be queried
by running the following command:

$ sysctl net.ipv4.icmp_echo_ignore_broadcasts

1.

      Is it the case that the correct value is not returned?
 SRG-OS-000480-GPOS-00227 CM-7(a), CM-7(b), SC-5
xccdf_org.ssgproject.content_rule_sysctl_net_ipv4_icmp_ignore_bogus_error_responses unknown Enable Kernel Parameter to Ignore Bogus ICMP Error Responses on IPv4 Interfaces Ignoring bogus ICMP error responses reduces log size, although some activity would not be logged. To set the runtime status of the net.ipv4.icmp_ignore_bogus_error_responses kernel parameter, run the following command: 
$ sudo sysctl -w net.ipv4.icmp_ignore_bogus_error_responses=1
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d: 
net.ipv4.icmp_ignore_bogus_error_responses = 1
 
The runtime status of the net.ipv4.icmp_ignore_bogus_error_responses kernel parameter can be queried
by running the following command:

$ sysctl net.ipv4.icmp_ignore_bogus_error_responses

1.

      Is it the case that the correct value is not returned?
 SRG-OS-000480-GPOS-00227 CM-7(a), CM-7(b), SC-5
xccdf_org.ssgproject.content_rule_sysctl_net_ipv4_tcp_syncookies medium Enable Kernel Parameter to Use TCP Syncookies on Network Interfaces A TCP SYN flood attack can cause a denial of service by filling a system's TCP connection table with connections in the SYN_RCVD state. Syncookies can be used to track a connection when a subsequent ACK is received, verifying the initiator is attempting a valid connection and is not a flood source. This feature is activated when a flood condition is detected, and enables the system to continue servicing valid connection requests. To set the runtime status of the net.ipv4.tcp_syncookies kernel parameter, run the following command: 
$ sudo sysctl -w net.ipv4.tcp_syncookies=1
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d: 
net.ipv4.tcp_syncookies = 1
 
The runtime status of the net.ipv4.tcp_syncookies kernel parameter can be queried
by running the following command:

$ sysctl net.ipv4.tcp_syncookies

1.

      Is it the case that the correct value is not returned?
 SRG-OS-000480-GPOS-00227, SRG-OS-000420-GPOS-00186, SRG-OS-000142-GPOS-00071 CM-7(a), CM-7(b), SC-5(1), SC-5(2), SC-5(3)(a), CM-6(a)
xccdf_org.ssgproject.content_rule_sysctl_net_ipv6_conf_all_accept_ra medium Configure Accepting Router Advertisements on All IPv6 Interfaces An illicit router advertisement message could result in a man-in-the-middle attack. To set the runtime status of the net.ipv6.conf.all.accept_ra kernel parameter, run the following command: 
$ sudo sysctl -w net.ipv6.conf.all.accept_ra=0
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d: 
net.ipv6.conf.all.accept_ra = 0
 
The runtime status of the net.ipv6.conf.all.accept_ra kernel parameter can be queried
by running the following command:

$ sysctl net.ipv6.conf.all.accept_ra

0.

      Is it the case that the correct value is not returned?
 SRG-OS-000480-GPOS-00227 CM-7(a), CM-7(b), CM-6(a)
xccdf_org.ssgproject.content_rule_sysctl_net_ipv6_conf_all_accept_redirects medium Disable Accepting ICMP Redirects for All IPv6 Interfaces An illicit ICMP redirect message could result in a man-in-the-middle attack. To set the runtime status of the net.ipv6.conf.all.accept_redirects kernel parameter, run the following command: 
$ sudo sysctl -w net.ipv6.conf.all.accept_redirects=0
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d: 
net.ipv6.conf.all.accept_redirects = 0
 
The runtime status of the net.ipv6.conf.all.accept_redirects kernel parameter can be queried
by running the following command:

$ sysctl net.ipv6.conf.all.accept_redirects

0.

      Is it the case that the correct value is not returned?
 SRG-OS-000480-GPOS-00227 CM-7(a), CM-7(b), CM-6(a), CM-6(b), CM-6.1(iv)
xccdf_org.ssgproject.content_rule_sysctl_net_ipv6_conf_all_accept_source_route medium Disable Kernel Parameter for Accepting Source-Routed Packets on all IPv6 Interfaces Source-routed packets allow the source of the packet to suggest routers forward the packet along a different path than configured on the router, which can be used to bypass network security measures. This requirement applies only to the forwarding of source-routerd traffic, such as when IPv6 forwarding is enabled and the system is functioning as a router.

Accepting source-routed packets in the IPv6 protocol has few legitimate uses. It should be disabled unless it is absolutely required.		 To set the runtime status of the net.ipv6.conf.all.accept_source_route kernel parameter, run the following command: 
$ sudo sysctl -w net.ipv6.conf.all.accept_source_route=0
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d: 
net.ipv6.conf.all.accept_source_route = 0
 
The runtime status of the net.ipv6.conf.all.accept_source_route kernel parameter can be queried
by running the following command:

$ sysctl net.ipv6.conf.all.accept_source_route

0.

      Is it the case that the correct value is not returned?
 SRG-OS-000480-GPOS-00227 CM-7(a), CM-7(b), CM-6(a)
xccdf_org.ssgproject.content_rule_sysctl_net_ipv6_conf_all_forwarding medium Disable Kernel Parameter for IPv6 Forwarding IP forwarding permits the kernel to forward packets from one network interface to another. The ability to forward packets between two networks is only appropriate for systems acting as routers. To set the runtime status of the net.ipv6.conf.all.forwarding kernel parameter, run the following command: 
$ sudo sysctl -w net.ipv6.conf.all.forwarding=0
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d: 
net.ipv6.conf.all.forwarding = 0
 
The runtime status of the net.ipv6.conf.all.forwarding kernel parameter can be queried
by running the following command:

$ sysctl net.ipv6.conf.all.forwarding

0.
The ability to forward packets is only appropriate for routers.
      Is it the case that IP forwarding value is "1" and the system is not router?
 SRG-OS-000480-GPOS-00227 CM-7(a), CM-7(b), CM-6(a), CM-6(b), CM-6.1(iv)
xccdf_org.ssgproject.content_rule_sysctl_net_ipv6_conf_default_accept_ra medium Disable Accepting Router Advertisements on all IPv6 Interfaces by Default An illicit router advertisement message could result in a man-in-the-middle attack. To set the runtime status of the net.ipv6.conf.default.accept_ra kernel parameter, run the following command: 
$ sudo sysctl -w net.ipv6.conf.default.accept_ra=0
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d: 
net.ipv6.conf.default.accept_ra = 0
 
The runtime status of the net.ipv6.conf.default.accept_ra kernel parameter can be queried
by running the following command:

$ sysctl net.ipv6.conf.default.accept_ra

0.

      Is it the case that the correct value is not returned?
 SRG-OS-000480-GPOS-00227 CM-7(a), CM-7(b), CM-6(a)
xccdf_org.ssgproject.content_rule_sysctl_net_ipv6_conf_default_accept_redirects medium Disable Kernel Parameter for Accepting ICMP Redirects by Default on IPv6 Interfaces An illicit ICMP redirect message could result in a man-in-the-middle attack. To set the runtime status of the net.ipv6.conf.default.accept_redirects kernel parameter, run the following command: 
$ sudo sysctl -w net.ipv6.conf.default.accept_redirects=0
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d: 
net.ipv6.conf.default.accept_redirects = 0
 
The runtime status of the net.ipv6.conf.default.accept_redirects kernel parameter can be queried
by running the following command:

$ sysctl net.ipv6.conf.default.accept_redirects

0.

      Is it the case that the correct value is not returned?
 SRG-OS-000480-GPOS-00227 CM-7(a), CM-7(b), CM-6(a)
xccdf_org.ssgproject.content_rule_sysctl_net_ipv6_conf_default_accept_source_route medium Disable Kernel Parameter for Accepting Source-Routed Packets on IPv6 Interfaces by Default Source-routed packets allow the source of the packet to suggest routers forward the packet along a different path than configured on the router, which can be used to bypass network security measures. This requirement applies only to the forwarding of source-routerd traffic, such as when IPv6 forwarding is enabled and the system is functioning as a router. Accepting source-routed packets in the IPv6 protocol has few legitimate uses. It should be disabled unless it is absolutely required. To set the runtime status of the net.ipv6.conf.default.accept_source_route kernel parameter, run the following command: 
$ sudo sysctl -w net.ipv6.conf.default.accept_source_route=0
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d: 
net.ipv6.conf.default.accept_source_route = 0
 
The runtime status of the net.ipv6.conf.default.accept_source_route kernel parameter can be queried
by running the following command:

$ sysctl net.ipv6.conf.default.accept_source_route

0.

      Is it the case that the correct value is not returned?
 SRG-OS-000480-GPOS-00227 CM-7(a), CM-7(b), CM-6(a), CM-6(b), CM-6.1(iv)
xccdf_org.ssgproject.content_rule_sysctl_user_max_user_namespaces medium Disable the use of user namespaces It is detrimental for operating systems to provide, or install by default, functionality exceeding requirements or system objectives. These unnecessary capabilities or services are often overlooked and therefore may remain unsecured. They increase the risk to the platform by providing additional attack vectors. User namespaces are used primarily for Linux containers. The value 0 disallows the use of user namespaces. To set the runtime status of the user.max_user_namespaces kernel parameter, run the following command: 
$ sudo sysctl -w user.max_user_namespaces=0
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d: 
user.max_user_namespaces = 0
When containers are deployed on the machine, the value should be set to large non-zero value.		 
Verify that Oracle Linux 9 disables the use of user namespaces with the following commands:

Note: User namespaces are used primarily for Linux containers. If containers are in use, this requirement is not applicable.

The runtime status of the user.max_user_namespaces kernel parameter can be queried
by running the following command:

$ sysctl user.max_user_namespaces

0.

      Is it the case that the correct value is not returned?
 SRG-OS-000480-GPOS-00227 SC-39, CM-6(a)
xccdf_org.ssgproject.content_rule_tftp_uses_secure_mode_systemd medium Ensure tftp systemd Service Uses Secure Mode Using the -s option causes the TFTP service to only serve files from the given directory. Serving files from an intentionally-specified directory reduces the risk of sharing files which should remain private. If running the Trivial File Transfer Protocol (TFTP) service is necessary, it should be configured to change its root directory at startup. To do so, find the path for the tftp systemd service: 
$ sudo systemctl show tftp | grep ExecStart=
ExecStart={ path=/usr/sbin/in.tftpd ; argv[]=/usr/sbin/in.tftpd -s /var/lib/tftpboot ; ignore_errors=no ; start_time=[n/a] ; stop_time=[n/a] ; pid=0 ; code=(null) ; status=0/0 }e
and ensure the ExecStart line on that file includes the -s option with a subdirectory: 
ExecStart=/usr/sbin/in.tftpd -s None
 
Use sudo systemctl show tftp to verify that tftp service is using secure mode.

$ sudo systemctl show tftp | grep ExecStart=
ExecStart={ path=/usr/sbin/in.tftpd ; argv[]=/usr/sbin/in.tftpd -s /var/lib/tftpboot ; ignore_errors=no ; start_time=[n/a] ; stop_time=[n/a] ; pid=0 ; code=(null) ; status=0/0 }e



and ensure the ExecStart line on that file includes the -s option with a subdirectory:

ExecStart=/usr/sbin/in.tftpd -s None

      Is it the case that the ExecStart property of tftp does not contain correctly set -s flag?
 SRG-OS-000074-GPOS-00042 IA-5 (1) (c)
xccdf_org.ssgproject.content_rule_usbguard_generate_policy medium Generate USBGuard Policy The usbguard must be configured to allow connected USB devices to work properly, avoiding the system to become inaccessible. By default USBGuard when enabled prevents access to all USB devices and this lead to inaccessible system if they use USB mouse/keyboard. To prevent this scenario, the initial policy configuration must be generated based on current connected USB devices. 
Verify the USBGuard has a policy configured with the following command:

$ usbguard list-rules

allow id 1d6b:0001 serial

If the command does not return results or an error is returned, ask the SA to indicate how unauthorized peripherals are being blocked.
      Is it the case that there is no evidence that unauthorized peripherals are being blocked before establishing a connection?
 SRG-OS-000378-GPOS-00163 CM-8(3)(a), IA-3
xccdf_org.ssgproject.content_rule_use_pam_wheel_for_su medium Enforce usage of pam_wheel for su authentication The su program allows to run commands with a substitute user and group ID. It is commonly used to run commands as the root user. Limiting access to such command is considered a good security practice. To ensure that only users who are members of the wheel group can run commands with altered privileges through the su command, make sure that the following line exists in the file /etc/pam.d/su: 
auth required pam_wheel.so use_uid
 
Run the following command to check if the line is present:

grep pam_wheel /etc/pam.d/su

The output should contain the following line:

auth required pam_wheel.so use_uid

      Is it the case that the line is not in the file or it is commented?
 SRG-OS-000373-GPOS-00156, SRG-OS-000312-GPOS-00123
xccdf_org.ssgproject.content_rule_wireless_disable_interfaces medium Deactivate Wireless Network Interfaces The use of wireless networking can introduce many different attack vectors into the organization's network. Common attack vectors such as malicious association and ad hoc networks will allow an attacker to spoof a wireless access point (AP), allowing validated systems to connect to the malicious AP and enabling the attacker to monitor and record network traffic. These malicious APs can also serve to create a man-in-the-middle attack or be used to create a denial of service to valid network resources. Deactivating wireless network interfaces should prevent normal usage of the wireless capability.

Configure the system to disable all wireless network interfaces with the following command: 
$ sudo nmcli radio all off
 
Verify that there are no wireless interfaces configured on the system
with the following command:

Note: This requirement is Not Applicable for systems that do not have physical wireless network radios.


$ nmcli device status


DEVICE          TYPE      STATE         CONNECTION
virbr0          bridge    connected     virbr0
wlp7s0          wifi      connected     wifiSSID
enp6s0          ethernet  disconnected  --
p2p-dev-wlp7s0  wifi-p2p  disconnected  --
lo              loopback  unmanaged     --
virbr0-nic      tun       unmanaged     --

      Is it the case that a wireless interface is configured and has not been documented and approved by the Information System Security Officer (ISSO)?
 SRG-OS-000299-GPOS-00117, SRG-OS-000300-GPOS-00118, SRG-OS-000424-GPOS-00188, SRG-OS-000481-GPOS-00481 AC-18(a), AC-18(3), CM-7(a), CM-7(b), CM-6(a), MP-7
xccdf_org.ssgproject.content_rule_xwindows_remove_packages medium Disable graphical user interface Unnecessary service packages must not be installed to decrease the attack surface of the system. X windows has a long history of security vulnerabilities and should not be installed unless approved and documented. By removing the following packages, the system no longer has X Windows installed. xorg-x11-server-Xorg xorg-x11-server-common xorg-x11-server-utils xorg-x11-server-Xwayland If X Windows is not installed then the system cannot boot into graphical user mode. This prevents the system from being accidentally or maliciously booted into a graphical.target mode. To do so, run the following command: 
sudo yum remove xorg-x11-server-Xorg xorg-x11-server-common xorg-x11-server-utils xorg-x11-server-Xwayland
 
To ensure the X Windows package group is removed, run the following command:

$ rpm -qi xorg-x11-server-Xorg


$ rpm -qi xorg-x11-server-common


$ rpm -qi xorg-x11-server-utils


$ rpm -qi xorg-x11-server-Xwayland

For each package mentioned above you should receive following line:

package <package> is not installed

      Is it the case that xorg related packages are not removed and run level is not correctly configured?
 SRG-OS-000480-GPOS-00227 CM-6(b)
xccdf_org.ssgproject.content_rule_xwindows_runlevel_target medium Disable Graphical Environment Startup By Setting Default Target Services that are not required for system and application processes must not be active to decrease the attack surface of the system. Systems that do not require a graphical user interface should only boot by default into multi-user.target mode. This prevents accidental booting of the system into a graphical.target mode. Setting the system's default target to multi-user.target will prevent automatic startup of the graphical environment. To do so, run: 
$ systemctl set-default multi-user.target
You should see the following output: 
Removed symlink /etc/systemd/system/default.target.
Created symlink from /etc/systemd/system/default.target to /usr/lib/systemd/system/multi-user.target.
 
Verify that Oracle Linux 9 is configured to boot to the command line:

$ systemctl get-default


multi-user.target

      Is it the case that the system default target is not set to "multi-user.target" and the Information System Security Officer (ISSO) lacks a documented requirement for a graphical user interface?
 SRG-OS-000480-GPOS-00227 CM-7(a), CM-7(b), CM-6(a)