Oracle Linux 7 Security Technical Implementation Guide

Checks: C-97893r1_chk

Verify the operating system displays the Standard Mandatory DoD Notice and Consent Banner before granting access to the operating system via a graphical user logon. Note: If the system does not have GNOME installed, this requirement is Not Applicable. Check to see if the operating system displays a banner at the logon screen with the following command: # grep banner-message-enable /etc/dconf/db/local.d/* banner-message-enable=true If "banner-message-enable" is set to "false" or is missing, this is a finding.

Fix: F-104729r1_fix

Configure the operating system to display the Standard Mandatory DoD Notice and Consent Banner before granting access to the system. Note: If the system does not have GNOME installed, this requirement is Not Applicable. Create a database to contain the system-wide graphical user logon settings (if it does not already exist) with the following command: # touch /etc/dconf/db/local.d/01-banner-message Add the following line to the [org/gnome/login-screen] section of the "/etc/dconf/db/local.d/01-banner-message": [org/gnome/login-screen] banner-message-enable=true Update the system databases: # dconf update Users must log out, and then log in again before the system-wide settings take effect.

Generate Mitigation Statement:

Checks: C-97895r2_chk

Verify the operating system displays the approved Standard Mandatory DoD Notice and Consent Banner before granting access to the operating system via a graphical user logon. Note: If the system does not have GNOME installed, this requirement is Not Applicable. Check that the operating system displays the exact approved Standard Mandatory DoD Notice and Consent Banner text with the command: # grep banner-message-text /etc/dconf/db/local.d/* banner-message-text= 'You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only.\nBy using this IS (which includes any device attached to this IS), you consent to the following conditions:\n-The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations.\n-At any time, the USG may inspect and seize data stored on this IS.\n-Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose.\n-This IS includes security measures (e.g., authentication and access controls) to protect USG interests--not for your personal benefit or privacy.\n-Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details.' Note: The "\n" characters are for formatting only. They will not be displayed on the GUI. If the banner does not match the approved Standard Mandatory DoD Notice and Consent Banner, this is a finding.

Fix: F-104731r2_fix

Configure the operating system to display the approved Standard Mandatory DoD Notice and Consent Banner before granting access to the system. Note: If the system does not have GNOME installed, this requirement is Not Applicable. Create a database to contain the system-wide graphical user logon settings (if it does not already exist) with the following command: # touch /etc/dconf/db/local.d/01-banner-message Add the following line to the [org/gnome/login-screen] section of the "/etc/dconf/db/local.d/01-banner-message": [org/gnome/login-screen] banner-message-enable=true banner-message-text='You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only.\nBy using this IS (which includes any device attached to this IS), you consent to the following conditions:\n-The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations.\n-At any time, the USG may inspect and seize data stored on this IS.\n-Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose.\n-This IS includes security measures (e.g., authentication and access controls) to protect USG interests--not for your personal benefit or privacy.\n-Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details.' Note: The "\n" characters are for formatting only. They will not be displayed on the GUI. Run the following command to update the database: # dconf update

Generate Mitigation Statement:

Checks: C-97897r1_chk

Verify the operating system displays the Standard Mandatory DoD Notice and Consent Banner before granting access to the operating system via a command line user logon. Check to see if the operating system displays a banner at the command line logon screen with the following command: # more /etc/issue The command should return the following text: "You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only. By using this IS (which includes any device attached to this IS), you consent to the following conditions: -The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations. -At any time, the USG may inspect and seize data stored on this IS. -Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose. -This IS includes security measures (e.g., authentication and access controls) to protect USG interests--not for your personal benefit or privacy. -Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details." If the operating system does not display a graphical logon banner or the banner does not match the Standard Mandatory DoD Notice and Consent Banner, this is a finding. If the text in the "/etc/issue" file does not match the Standard Mandatory DoD Notice and Consent Banner, this is a finding.

Fix: F-104733r1_fix

Configure the operating system to display the Standard Mandatory DoD Notice and Consent Banner before granting access to the system via the command line by editing the "/etc/issue" file. Replace the default text with the Standard Mandatory DoD Notice and Consent Banner. The DoD required text is: "You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only. By using this IS (which includes any device attached to this IS), you consent to the following conditions: -The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations. -At any time, the USG may inspect and seize data stored on this IS. -Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose. -This IS includes security measures (e.g., authentication and access controls) to protect USG interests--not for your personal benefit or privacy. -Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details."

Generate Mitigation Statement:

Checks: C-97899r1_chk

Verify the operating system enables a user's session lock until that user re-establishes access using established identification and authentication procedures. The screen program must be installed to lock sessions on the console. Note: If the system does not have GNOME installed, this requirement is Not Applicable. Check to see if the screen lock is enabled with the following command: # grep -i lock-enabled /etc/dconf/db/local.d/* lock-enabled=true If the "lock-enabled" setting is missing or is not set to "true", this is a finding.

Fix: F-104735r1_fix

Configure the operating system to enable a user's session lock until that user re-establishes access using established identification and authentication procedures. Create a database to contain the system-wide screensaver settings (if it does not already exist) with the following example: # touch /etc/dconf/db/local.d/00-screensaver Edit the "[org/gnome/desktop/screensaver]" section of the database file and add or update the following lines: # Set this to true to lock the screen when the screensaver activates lock-enabled=true Update the system databases: # dconf update Users must log out and then log in again before the system-wide settings take effect.

Generate Mitigation Statement:

Checks: C-97901r1_chk

Verify the operating system uniquely identifies and authenticates users using multifactor authentication via a graphical user logon. Note: If the system does not have GNOME installed, this requirement is Not Applicable. Determine which profile the system database is using with the following command: # grep system-db /etc/dconf/profile/user system-db:local Note: The example is using the database local for the system, so the path is "/etc/dconf/db/local.d". This path must be modified if a database other than local is being used. # grep enable-smartcard-authentication /etc/dconf/db/local.d/* enable-smartcard-authentication=true If "enable-smartcard-authentication" is set to "false" or the keyword is missing, this is a finding.

Fix: F-104737r1_fix

Configure the operating system to uniquely identify and authenticate users using multifactor authentication via a graphical user logon. Note: If the system does not have GNOME installed, this requirement is Not Applicable. Create a database to contain the system-wide screensaver settings (if it does not already exist) with the following command: Note: The example is using the local system database, so if the system is using another database in "/etc/dconf/profile/user", create the file under the appropriate subdirectory. # touch /etc/dconf/db/local.d/00-defaults Edit "[org/gnome/login-screen]" and add or update the following line: enable-smartcard-authentication=true Update the system databases: # dconf update

Generate Mitigation Statement:

Checks: C-97903r1_chk

Verify the operating system prevents a user from overriding the screensaver lock-enabled setting for the graphical user interface. Note: If the system does not have GNOME installed, this requirement is Not Applicable. The screen program must be installed to lock sessions on the console. Determine which profile the system database is using with the following command: # grep system-db /etc/dconf/profile/user system-db:local Check for the lock-enabled setting with the following command: Note: The example below is using the database "local" for the system, so the path is "/etc/dconf/db/local.d". This path must be modified if a database other than "local" is being used. # grep -i lock-enabled /etc/dconf/db/local.d/locks/* /org/gnome/desktop/screensaver/lock-enabled If the command does not return a result, this is a finding.

Fix: F-104739r1_fix

Configure the operating system to prevent a user from overriding a screensaver lock after a 15-minute period of inactivity for graphical user interfaces. Create a database to contain the system-wide screensaver settings (if it does not already exist) with the following command: Note: The example below is using the database "local" for the system, so if the system is using another database in "/etc/dconf/profile/user", the file should be created under the appropriate subdirectory. # touch /etc/dconf/db/local.d/locks/session Add the setting to lock the screensaver lock-enabled setting: /org/gnome/desktop/screensaver/lock-enabled

Generate Mitigation Statement:

Checks: C-97905r1_chk

Verify the operating system initiates a screensaver after a 15-minute period of inactivity for graphical user interfaces. The screen program must be installed to lock sessions on the console. Note: If the system does not have GNOME installed, this requirement is Not Applicable. Check to see if GNOME is configured to display a screensaver after a 15 minute delay with the following command: # grep -i idle-delay /etc/dconf/db/local.d/* idle-delay=uint32 900 If the "idle-delay" setting is missing or is not set to "900" or less, this is a finding.

Fix: F-104741r1_fix

Configure the operating system to initiate a screensaver after a 15-minute period of inactivity for graphical user interfaces. Create a database to contain the system-wide screensaver settings (if it does not already exist) with the following command: # touch /etc/dconf/db/local.d/00-screensaver Edit /etc/dconf/db/local.d/00-screensaver and add or update the following lines: [org/gnome/desktop/session] # Set the lock time out to 900 seconds before the session is considered idle idle-delay=uint32 900 You must include the "uint32" along with the integer key values as shown. Update the system databases: # dconf update Users must log out and then log in again before the system-wide settings take effect.

Generate Mitigation Statement:

Checks: C-97907r1_chk

Verify the operating system prevents a user from overriding a screensaver lock after a 15-minute period of inactivity for graphical user interfaces. Note: If the system does not have GNOME installed, this requirement is Not Applicable. The screen program must be installed to lock sessions on the console. Determine which profile the system database is using with the following command: # grep system-db /etc/dconf/profile/user system-db:local Check for the lock delay setting with the following command: Note: The example below is using the database "local" for the system, so the path is "/etc/dconf/db/local.d". This path must be modified if a database other than "local" is being used. # grep -i lock-delay /etc/dconf/db/local.d/locks/* /org/gnome/desktop/screensaver/lock-delay If the command does not return a result, this is a finding.

Fix: F-104743r1_fix

Configure the operating system to prevent a user from overriding a screensaver lock after a 15-minute period of inactivity for graphical user interfaces. Create a database to contain the system-wide screensaver settings (if it does not already exist) with the following command: Note: The example below is using the database "local" for the system, so if the system is using another database in "/etc/dconf/profile/user", the file should be created under the appropriate subdirectory. # touch /etc/dconf/db/local.d/locks/session Add the setting to lock the screensaver lock delay: /org/gnome/desktop/screensaver/lock-delay

Generate Mitigation Statement:

Checks: C-97909r1_chk

Verify the operating system prevents a user from overriding session idle delay after a 15-minute period of inactivity for graphical user interfaces. Note: If the system does not have GNOME installed, this requirement is Not Applicable. The screen program must be installed to lock sessions on the console. Determine which profile the system database is using with the following command: # grep system-db /etc/dconf/profile/user system-db:local Check for the session idle delay setting with the following command: Note: The example below is using the database "local" for the system, so the path is "/etc/dconf/db/local.d". This path must be modified if a database other than "local" is being used. # grep -i idle-delay /etc/dconf/db/local.d/locks/* /org/gnome/desktop/session/idle-delay If the command does not return a result, this is a finding.

Fix: F-104745r1_fix

Configure the operating system to prevent a user from overriding a session lock after a 15-minute period of inactivity for graphical user interfaces. Create a database to contain the system-wide screensaver settings (if it does not already exist) with the following command: Note: The example below is using the database "local" for the system, so if the system is using another database in /etc/dconf/profile/user, the file should be created under the appropriate subdirectory. # touch /etc/dconf/db/local.d/locks/session Add the setting to lock the session idle delay: /org/gnome/desktop/session/idle-delay

Generate Mitigation Statement:

Checks: C-97911r1_chk

Verify the operating system has the screen package installed. Check to see if the screen package is installed with the following command: # yum list installed screen screen-4.3.1-3-x86_64.rpm If the screen package is not installed, check to see if the tmux package is installed with the following command: #yum list installed tmux tmux-1.8-4.el7.x86_64.rpm If either the screen package or the tmux package is not installed, this is a finding.

Fix: F-104747r1_fix

Install the screen package to allow the initiation of a session lock after a 15-minute period of inactivity. Install the screen program (if it is not on the system) with the following command: # yum install screen OR Install the tmux program (if it is not on the system) with the following command: #yum install tmux

Generate Mitigation Statement:

Checks: C-97913r1_chk

Verify the operating system initiates a session lock after a 15-minute period of inactivity for graphical user interfaces. The screen program must be installed to lock sessions on the console. If it is installed, GNOME must be configured to enforce a session lock after a 15-minute delay. Check for the session lock settings with the following commands: # grep -i idle-activation-enabled /etc/dconf/db/local.d/* idle-activation-enabled=true If "idle-activation-enabled" is not set to "true", this is a finding.

Fix: F-104749r1_fix

Configure the operating system to initiate a session lock after a 15-minute period of inactivity for graphical user interfaces. Create a database to contain the system-wide screensaver settings (if it does not already exist) with the following command: # touch /etc/dconf/db/local.d/00-screensaver Add the setting to enable screensaver locking after 15 minutes of inactivity: [org/gnome/desktop/screensaver] idle-activation-enabled=true Update the system databases: # dconf update Users must log out and then log in again before the system-wide settings take effect.

Generate Mitigation Statement:

Checks: C-97915r1_chk

Verify the operating system prevents a user from overriding the screensaver idle-activation-enabled setting for the graphical user interface. Note: If the system does not have GNOME installed, this requirement is Not Applicable. The screen program must be installed to lock sessions on the console. Determine which profile the system database is using with the following command: # grep system-db /etc/dconf/profile/user system-db:local Check for the idle-activation-enabled setting with the following command: Note: The example below is using the database "local" for the system, so the path is "/etc/dconf/db/local.d". This path must be modified if a database other than "local" is being used. # grep -i idle-activation-enabled /etc/dconf/db/local.d/locks/* /org/gnome/desktop/screensaver/idle-activation-enabled If the command does not return a result, this is a finding.

Fix: F-104751r1_fix

Configure the operating system to prevent a user from overriding a screensaver lock after a 15-minute period of inactivity for graphical user interfaces. Create a database to contain the system-wide screensaver settings (if it does not already exist) with the following command: Note: The example below is using the database "local" for the system, so if the system is using another database in "/etc/dconf/profile/user", the file should be created under the appropriate subdirectory. # touch /etc/dconf/db/local.d/locks/session Add the setting to lock the screensaver idle-activation-enabled setting: /org/gnome/desktop/screensaver/idle-activation-enabled

Generate Mitigation Statement:

Checks: C-97917r1_chk

Verify the operating system initiates a session lock a for graphical user interfaces when the screensaver is activated. Note: If the system does not have GNOME installed, this requirement is Not Applicable. The screen program must be installed to lock sessions on the console. If GNOME is installed, check to see a session lock occurs when the screensaver is activated with the following command: # grep -i lock-delay /etc/dconf/db/local.d/* lock-delay=uint32 5 If the "lock-delay" setting is missing, or is not set to "5" or less, this is a finding.

Fix: F-104753r1_fix

Configure the operating system to initiate a session lock for graphical user interfaces when a screensaver is activated. Create a database to contain the system-wide screensaver settings (if it does not already exist) with the following command: # touch /etc/dconf/db/local.d/00-screensaver Add the setting to enable session locking when a screensaver is activated: [org/gnome/desktop/screensaver] lock-delay=uint32 5 The "uint32" must be included along with the integer key values as shown. Update the system databases: # dconf update Users must log out and then log in again before the system-wide settings take effect.

Generate Mitigation Statement:

Checks: C-97919r1_chk

Verify that /etc/pam.d/passwd is configured to use /etc/pam.d/system-auth when changing passwords: # cat /etc/pam.d/passwd | grep -i substack | grep -i system-auth password substack system-auth If no results are returned, the line is commented out, this is a finding.

Fix: F-104755r1_fix

Configure PAM to utilize /etc/pam.d/system-auth when changing passwords. Add the following line to "/etc/pam.d/passwd" (or modify the line to have the required value): password substack system-auth

Generate Mitigation Statement:

Checks: C-97921r1_chk

Verify the operating system uses "pwquality" to enforce the password complexity rules. Check for the use of "pwquality" with the following command: # cat /etc/pam.d/system-auth | grep pam_pwquality password required pam_pwquality.so retry=3 If the command does not return an uncommented line containing the value "pam_pwquality.so", this is a finding. If the value of "retry" is set to "0" or greater than "3", this is a finding.

Fix: F-104757r1_fix

Configure the operating system to use "pwquality" to enforce password complexity rules. Add the following line to "/etc/pam.d/system-auth" (or modify the line to have the required value): password required pam_pwquality.so retry=3 Note: The value of "retry" should be between "1" and "3".

Generate Mitigation Statement:

Checks: C-97923r1_chk

Note: The value to require a number of upper-case characters to be set is expressed as a negative number in "/etc/security/pwquality.conf". Check the value for "ucredit" in "/etc/security/pwquality.conf" with the following command: # grep ucredit /etc/security/pwquality.conf ucredit = -1 If the value of "ucredit" is not set to a negative value, this is a finding.

Fix: F-104759r1_fix

Configure the operating system to enforce password complexity by requiring that at least one upper-case character be used by setting the "ucredit" option. Add the following line to "/etc/security/pwquality.conf" (or modify the line to have the required value): ucredit = -1

Generate Mitigation Statement:

Checks: C-97925r1_chk

Note: The value to require a number of lower-case characters to be set is expressed as a negative number in "/etc/security/pwquality.conf". Check the value for "lcredit" in "/etc/security/pwquality.conf" with the following command: # grep lcredit /etc/security/pwquality.conf lcredit = -1 If the value of "lcredit" is not set to a negative value, this is a finding.

Fix: F-104761r1_fix

Configure the system to require at least one lower-case character when creating or changing a password. Add or modify the following line in "/etc/security/pwquality.conf": lcredit = -1

Generate Mitigation Statement:

Checks: C-97927r1_chk

Note: The value to require a number of numeric characters to be set is expressed as a negative number in "/etc/security/pwquality.conf". Check the value for "dcredit" in "/etc/security/pwquality.conf" with the following command: # grep dcredit /etc/security/pwquality.conf dcredit = -1 If the value of "dcredit" is not set to a negative value, this is a finding.

Fix: F-104763r1_fix

Configure the operating system to enforce password complexity by requiring that at least one numeric character be used by setting the "dcredit" option. Add the following line to /etc/security/pwquality.conf (or modify the line to have the required value): dcredit = -1

Generate Mitigation Statement:

Checks: C-97929r1_chk

Verify the operating system enforces password complexity by requiring that at least one special character be used. Note: The value to require a number of special characters to be set is expressed as a negative number in "/etc/security/pwquality.conf". Check the value for "ocredit" in "/etc/security/pwquality.conf" with the following command: # grep ocredit /etc/security/pwquality.conf ocredit=-1 If the value of "ocredit" is not set to a negative value, this is a finding.

Fix: F-104765r1_fix

Configure the operating system to enforce password complexity by requiring that at least one special character be used by setting the "ocredit" option. Add the following line to "/etc/security/pwquality.conf" (or modify the line to have the required value): ocredit = -1

Generate Mitigation Statement:

Checks: C-97931r1_chk

The "difok" option sets the number of characters in a password that must not be present in the old password. Check for the value of the "difok" option in "/etc/security/pwquality.conf" with the following command: # grep difok /etc/security/pwquality.conf difok = 8 If the value of "difok" is set to less than "8", this is a finding.

Fix: F-104767r1_fix

Configure the operating system to require the change of at least eight of the total number of characters when passwords are changed by setting the "difok" option. Add the following line to "/etc/security/pwquality.conf" (or modify the line to have the required value): difok = 8

Generate Mitigation Statement:

Checks: C-97933r1_chk

The "minclass" option sets the minimum number of required classes of characters for the new password (digits, uppercase, lower-case, others). Check for the value of the "minclass" option in "/etc/security/pwquality.conf" with the following command: # grep minclass /etc/security/pwquality.conf minclass = 4 If the value of "minclass" is set to less than "4", this is a finding.

Fix: F-104769r1_fix

Configure the operating system to require the change of at least four character classes when passwords are changed by setting the "minclass" option. Add the following line to "/etc/security/pwquality.conf conf" (or modify the line to have the required value): minclass = 4

Generate Mitigation Statement:

Checks: C-97935r1_chk

The "maxrepeat" option sets the maximum number of allowed same consecutive characters in a new password. Check for the value of the "maxrepeat" option in "/etc/security/pwquality.conf" with the following command: # grep maxrepeat /etc/security/pwquality.conf maxrepeat = 3 If the value of "maxrepeat" is set to more than "3", this is a finding.

Fix: F-104771r1_fix

Configure the operating system to require the change of the number of repeating consecutive characters when passwords are changed by setting the "maxrepeat" option. Add the following line to "/etc/security/pwquality.conf conf" (or modify the line to have the required value): maxrepeat = 3

Generate Mitigation Statement:

Checks: C-97937r1_chk

The "maxclassrepeat" option sets the maximum number of allowed same consecutive characters in the same class in the new password. Check for the value of the "maxclassrepeat" option in "/etc/security/pwquality.conf" with the following command: # grep maxclassrepeat /etc/security/pwquality.conf maxclassrepeat = 4 If the value of "maxclassrepeat" is set to more than "4", this is a finding.

Fix: F-104773r1_fix

Configure the operating system to require the change of the number of repeating characters of the same character class when passwords are changed by setting the "maxclassrepeat" option. Add the following line to "/etc/security/pwquality.conf" conf (or modify the line to have the required value): maxclassrepeat = 4

Generate Mitigation Statement:

Checks: C-97939r1_chk

Verify the PAM system service is configured to store only encrypted representations of passwords. The strength of encryption that must be used to hash passwords for all accounts is SHA512. Check that the system is configured to create SHA512 hashed passwords with the following command: # grep password /etc/pam.d/system-auth /etc/pam.d/password-auth Outcome should look like following: /etc/pam.d/system-auth-ac:password sufficient pam_unix.so sha512 shadow try_first_pass use_authtok /etc/pam.d/password-auth:password sufficient pam_unix.so sha512 shadow try_first_pass use_authtok If the "/etc/pam.d/system-auth" and "/etc/pam.d/password-auth" configuration files allow for password hashes other than SHA512 to be used, this is a finding.

Fix: F-104775r1_fix

Configure the operating system to store only SHA512 encrypted representations of passwords. Add the following line in "/etc/pam.d/system-auth": pam_unix.so sha512 shadow try_first_pass use_authtok Add the following line in "/etc/pam.d/password-auth": pam_unix.so sha512 shadow try_first_pass use_authtok Note: Manual changes to the listed files may be overwritten by the "authconfig" program. The "authconfig" program should not be used to update the configurations listed in this requirement.

Generate Mitigation Statement:

Checks: C-97941r1_chk

Verify the system's shadow file is configured to store only encrypted representations of passwords. The strength of encryption that must be used to hash passwords for all accounts is SHA512. Check that the system is configured to create SHA512 hashed passwords with the following command: # grep -i encrypt /etc/login.defs ENCRYPT_METHOD SHA512 If the "/etc/login.defs" configuration file does not exist or allows for password hashes other than SHA512 to be used, this is a finding.

Fix: F-104777r1_fix

Configure the operating system to store only SHA512 encrypted representations of passwords. Add or update the following line in "/etc/login.defs": ENCRYPT_METHOD SHA512

Generate Mitigation Statement:

Checks: C-97943r1_chk

Verify the user and group account administration utilities are configured to store only encrypted representations of passwords. The strength of encryption that must be used to hash passwords for all accounts is "SHA512". Check that the system is configured to create "SHA512" hashed passwords with the following command: # grep -i sha512 /etc/libuser.conf crypt_style = sha512 If the "crypt_style" variable is not set to "sha512", is not in the defaults section, is commented out, or does not exist, this is a finding.

Fix: F-104779r1_fix

Configure the operating system to store only SHA512 encrypted representations of passwords. Add or update the following line in "/etc/libuser.conf" in the [defaults] section: crypt_style = sha512

Generate Mitigation Statement:

Checks: C-97945r1_chk

Verify the operating system enforces 24 hours/1 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 If the "PASS_MIN_DAYS" parameter value is not "1" or greater, or is commented out, this is a finding.

Fix: F-104781r1_fix

Configure the operating system to enforce 24 hours/1 day as the minimum password lifetime. Add the following line in "/etc/login.defs" (or modify the line to have the required value): PASS_MIN_DAYS 1

Generate Mitigation Statement:

Checks: C-97947r1_chk

Check whether the minimum time period between password changes for each user account is one day or greater. # awk -F: '$4 < 1 {print $1 " " $4}' /etc/shadow If any results are returned that are not associated with a system account, this is a finding.

Fix: F-104783r1_fix

Configure non-compliant accounts to enforce a 24 hours/1 day minimum password lifetime: # chage -m 1 [user]

Generate Mitigation Statement:

Checks: C-97949r1_chk

If passwords are not being used for authentication, this is Not Applicable. Verify the operating system enforces a 60-day maximum password lifetime restriction for new user accounts. Check for the value of "PASS_MAX_DAYS" in "/etc/login.defs" with the following command: # grep -i pass_max_days /etc/login.defs PASS_MAX_DAYS 60 If the "PASS_MAX_DAYS" parameter value is not 60 or less, or is commented out, this is a finding.

Fix: F-104785r1_fix

Configure the operating system to enforce a 60-day maximum password lifetime restriction. Add the following line in "/etc/login.defs" (or modify the line to have the required value): PASS_MAX_DAYS 60

Generate Mitigation Statement:

Checks: C-97951r1_chk

Check whether the maximum time period for existing passwords is restricted to 60 days. # awk -F: '$5 > 60 {print $1 " " $5}' /etc/shadow If any results are returned that are not associated with a system account, this is a finding.

Fix: F-104787r1_fix

Configure non-compliant accounts to enforce a 60-day maximum password lifetime restriction. # chage -M 60 [user]

Generate Mitigation Statement:

Checks: C-97953r1_chk

Verify the operating system prohibits password reuse for a minimum of five generations. Check for the value of the "remember" argument in "/etc/pam.d/system-auth" and "/etc/pam.d/password-auth" with the following command: # grep -i remember /etc/pam.d/system-auth /etc/pam.d/password-auth password requisite pam_pwhistory.so use_authtok remember=5 retry=3 If the line containing the "pam_pwhistory.so" line does not have the "remember" module argument set, is commented out, or the value of the "remember" module argument is set to less than "5", this is a finding.

Fix: F-104789r1_fix

Configure the operating system to prohibit password reuse for a minimum of five generations. Add the following line in "/etc/pam.d/system-auth" and "/etc/pam.d/password-auth" (or modify the line to have the required value): password requisite pam_pwhistory.so use_authtok remember=5 retry=3 Note: Manual changes to the listed files may be overwritten by the "authconfig" program. The "authconfig" program should not be used to update the configurations listed in this requirement.

Generate Mitigation Statement:

Checks: C-97955r1_chk

Verify the operating system enforces a minimum 15-character password length. The "minlen" option sets the minimum number of characters in a new password. Check for the value of the "minlen" option in "/etc/security/pwquality.conf" with the following command: # grep minlen /etc/security/pwquality.conf minlen = 15 If the command does not return a "minlen" value of 15 or greater, this is a finding.

Fix: F-104791r1_fix

Configure operating system to enforce a minimum 15-character password length. Add the following line to "/etc/security/pwquality.conf" (or modify the line to have the required value): minlen = 15

Generate Mitigation Statement:

Checks: C-97961r1_chk

If passwords are not being used for authentication, this is Not Applicable. Verify the operating system disables account identifiers (individuals, groups, roles, and devices) after the password expires with the following command: # grep -i inactive /etc/default/useradd INACTIVE=0 If the value is not set to "0", is commented out, or is not defined, this is a finding.

Fix: F-104797r1_fix

Configure the operating system to disable account identifiers (individuals, groups, roles, and devices) after the password expires. Add the following line to "/etc/default/useradd" (or modify the line to have the required value): INACTIVE=0

Generate Mitigation Statement:

Checks: C-97963r1_chk

Verify the operating system automatically locks an account for the maximum period for which the system can be configured. Check that the system locks an account for the maximum period after three unsuccessful logon attempts within a period of 15 minutes, using the following command: # grep pam_faillock.so /etc/pam.d/password-auth auth required pam_faillock.so preauth silent audit deny=3 even_deny_root fail_interval=900 unlock_time=900 auth [default=die] pam_faillock.so authfail audit deny=3 even_deny_root fail_interval=900 unlock_time=900 account required pam_faillock.so If the "unlock_time" parameter is not set to "0", "never", or is set to a value less than "900" on both "auth" lines with the "pam_faillock.so" module, or is missing from these lines, this is a finding. Note: The maximum configurable value for "unlock_time" is "604800". If any line referencing the "pam_faillock.so" module is commented out, this is a finding. # grep pam_faillock.so /etc/pam.d/system-auth auth required pam_faillock.so preauth silent audit deny=3 even_deny_root fail_interval=900 unlock_time=900 auth [default=die] pam_faillock.so authfail audit deny=3 even_deny_root fail_interval=900 unlock_time=900 account required pam_faillock.so If the "unlock_time" parameter is not set to "0", "never", or is set to a value less than "900" on both "auth" lines with the "pam_faillock.so" module or is missing from these lines, this is a finding. Note: The maximum configurable value for "unlock_time" is "604800". If any line referencing the "pam_faillock.so" module is commented out, this is a finding.

Fix: F-104799r1_fix

Configure the operating system to lock an account for the maximum period when three unsuccessful logon attempts in 15 minutes are made. Modify the first three lines of the auth section and the first line of the account section of the "/etc/pam.d/system-auth" and "/etc/pam.d/password-auth" files to match the following lines: auth required pam_faillock.so preauth silent audit deny=3 even_deny_root fail_interval=900 unlock_time=900 auth sufficient pam_unix.so try_first_pass auth [default=die] pam_faillock.so authfail audit deny=3 even_deny_root fail_interval=900 unlock_time=900 account required pam_faillock.so Note: Manual changes to the listed files may be overwritten by the "authconfig" program. The "authconfig" program should not be used to update the configurations listed in this requirement.

Generate Mitigation Statement:

Checks: C-97965r1_chk

Verify the operating system automatically locks the root account until it is released by an administrator when three unsuccessful logon attempts in 15 minutes are made. # grep pam_faillock.so /etc/pam.d/password-auth auth required pam_faillock.so preauth silent audit deny=3 even_deny_root fail_interval=900 unlock_time=900 auth [default=die] pam_faillock.so authfail audit deny=3 even_deny_root fail_interval=900 unlock_time=900 account required pam_faillock.so If the "even_deny_root" setting is not defined on both lines with the "pam_faillock.so" module, is commented out, or is missing from a line, this is a finding. # grep pam_faillock.so /etc/pam.d/system-auth auth required pam_faillock.so preauth silent audit deny=3 even_deny_root fail_interval=900 unlock_time=900 auth [default=die] pam_faillock.so authfail audit deny=3 even_deny_root fail_interval=900 unlock_time=900 account required pam_faillock.so If the "even_deny_root" setting is not defined on both lines with the "pam_faillock.so" module, is commented out, or is missing from a line, this is a finding.

Fix: F-104801r1_fix

Configure the operating system to lock automatically the root account until the locked account is released by an administrator when three unsuccessful logon attempts in 15 minutes are made. Modify the first three lines of the auth section and the first line of the account section of the "/etc/pam.d/system-auth" and "/etc/pam.d/password-auth" files to match the following lines: auth required pam_faillock.so preauth silent audit deny=3 even_deny_root fail_interval=900 unlock_time=900 auth sufficient pam_unix.so try_first_pass auth [default=die] pam_faillock.so authfail audit deny=3 even_deny_root fail_interval=900 unlock_time=900 account required pam_faillock.so Note: Manual changes to the listed files may be overwritten by the "authconfig" program. The "authconfig" program should not be used to update the configurations listed in this requirement.

Generate Mitigation Statement:

Checks: C-97967r1_chk

If passwords are not being used for authentication, this is Not Applicable. Verify the operating system requires users to supply a password for privilege escalation. Check the configuration of the "/etc/sudoers" and "/etc/sudoers.d/*" files with the following command: # grep -i nopasswd /etc/sudoers /etc/sudoers.d/* If any uncommented line is found with a "NOPASSWD" tag, this is a finding.

Fix: F-104803r1_fix

Configure the operating system to require users to supply a password for privilege escalation. Check the configuration of the "/etc/sudoers" file with the following command: # visudo Remove any occurrences of "NOPASSWD" tags in the file. Check the configuration of the /etc/sudoers.d/* files with the following command: # grep -i nopasswd /etc/sudoers.d/* Remove any occurrences of "NOPASSWD" tags in the file.

Generate Mitigation Statement:

Checks: C-97969r1_chk

Verify the operating system enforces a delay of at least four seconds between console logon prompts following a failed logon attempt. Check the value of the "fail_delay" parameter in the "/etc/login.defs" file with the following command: # grep -i fail_delay /etc/login.defs FAIL_DELAY 4 If the value of "FAIL_DELAY" is not set to "4" or greater, or the line is commented out, this is a finding.

Fix: F-104805r1_fix

Configure the operating system to enforce a delay of at least four seconds between logon prompts following a failed console logon attempt. Modify the "/etc/login.defs" file to set the "FAIL_DELAY" parameter to "4" or greater: FAIL_DELAY 4

Generate Mitigation Statement:

Checks: C-97975r1_chk

Verify the operating system does not allow users to override environment variables to the SSH daemon. Check for the value of the "PermitUserEnvironment" keyword with the following command: # grep -i permituserenvironment /etc/ssh/sshd_config PermitUserEnvironment no If the "PermitUserEnvironment" keyword is not set to "no", is missing, or is commented out, this is a finding.

Fix: F-104811r1_fix

Configure the operating system not to allow users to override environment variables to the SSH daemon. Edit the "/etc/ssh/sshd_config" file to uncomment or add the line for "PermitUserEnvironment" keyword and set the value to "no": PermitUserEnvironment no The SSH service must be restarted for changes to take effect.

Generate Mitigation Statement:

Checks: C-97977r1_chk

Verify the operating system does not allow a non-certificate trusted host SSH logon to the system. Check for the value of the "HostbasedAuthentication" keyword with the following command: # grep -i hostbasedauthentication /etc/ssh/sshd_config HostbasedAuthentication no If the "HostbasedAuthentication" keyword is not set to "no", is missing, or is commented out, this is a finding.

Fix: F-104813r1_fix

Configure the operating system not to allow a non-certificate trusted host SSH logon to the system. Edit the "/etc/ssh/sshd_config" file to uncomment or add the line for "HostbasedAuthentication" keyword and set the value to "no": HostbasedAuthentication no The SSH service must be restarted for changes to take effect.

Generate Mitigation Statement:

Checks: C-97981r1_chk

Verify the operating system must require authentication upon booting into single-user and maintenance modes. Check that the operating system requires authentication upon booting into single-user mode with the following command: # grep -i execstart /usr/lib/systemd/system/rescue.service | grep -i sulogin ExecStart=-/bin/sh -c "/usr/sbin/sulogin; /usr/bin/systemctl --fail --no-block default" If "ExecStart" does not have "/usr/sbin/sulogin" as an option, this is a finding.

Fix: F-104817r1_fix

Configure the operating system to require authentication upon booting into single-user and maintenance modes. Add or modify the "ExecStart" line in "/usr/lib/systemd/system/rescue.service" to include "/usr/sbin/sulogin": ExecStart=-/bin/sh -c "/usr/sbin/sulogin; /usr/bin/systemctl --fail --no-block default"

Generate Mitigation Statement:

Checks: C-97989r1_chk

Verify the operating system requires multifactor authentication to uniquely identify organizational users using multifactor authentication. Check to see if smartcard authentication is enforced on the system: # authconfig --test | grep "pam_pkcs11 is enabled" If no results are returned, this is a finding. # authconfig --test | grep "smartcard removal action" If "smartcard removal action" is blank, this is a finding. # authconfig --test | grep "smartcard module" If "smartcard module" is blank, this is a finding.

Fix: F-104825r1_fix

Configure the operating system to require individuals to be authenticated with a multifactor authenticator. Enable smartcard logons with the following commands: # authconfig --enablesmartcard --smartcardaction=0 --update # authconfig --enablerequiresmartcard -update Modify the "/etc/pam_pkcs11/pkcs11_eventmgr.conf" file to uncomment the following line: #/usr/X11R6/bin/xscreensaver-command -lock Modify the "/etc/pam_pkcs11/pam_pkcs11.conf" file to use the cackey module if required.

Generate Mitigation Statement:

Checks: C-97995r1_chk

Consult with the SA or ISSO to determine if a host-based intrusion detection application is loaded on the system. Per OPORD 16-0080, the preferred intrusion detection system is McAfee HBSS available through the U.S. Cyber Command (USCYBERCOM). If another host-based intrusion detection application is in use, such as SELinux, this must be documented and approved by the local Authorizing Official. Procedure: Examine the system to determine if the Host Intrusion Prevention System (HIPS) is installed: # rpm -qa | grep MFEhiplsm Verify the McAfee HIPS module is active on the system: # ps -ef | grep -i "hipclient" If the MFEhiplsm package is not installed, check for another intrusion detection system: # find / -name <daemon name> Where <daemon name> is the name of the primary application daemon to determine if the application is loaded on the system. Determine if the application is active on the system: # ps -ef | grep -i <daemon name> If the MFEhiplsm package is not installed and an alternate host-based intrusion detection application has not been documented for use, this is a finding. If no host-based intrusion detection system is installed and running on the system, this is a finding.

Fix: F-104831r1_fix

Install and enable the latest McAfee HIPS package, available from USCYBERCOM. Note: If the system does not support the McAfee HIPS package, install and enable a supported intrusion detection system application and document its use with the Authorizing Official.

Generate Mitigation Statement:

Checks: C-97997r1_chk

If an HBSS or HIPS is active on the system, this is Not Applicable. Verify the operating system prevents non-privileged users from executing privileged functions to include disabling, circumventing, or altering implemented security safeguards/countermeasures. Get a list of authorized users (other than System Administrator and guest accounts) for the system. Check the list against the system by using the following command: # semanage login -l | more Login Name SELinux User MLS/MCS Range Service __default__ user_u s0-s0:c0.c1023 * root unconfined_u s0-s0:c0.c1023 * system_u system_u s0-s0:c0.c1023 * joe staff_u s0-s0:c0.c1023 * All administrators must be mapped to the "sysadm_u" or "staff_u" users role. All authorized non-administrative users must be mapped to the "user_u" role. If they are not mapped in this way, this is a finding.

Fix: F-104833r1_fix

Configure the operating system to prevent non-privileged users from executing privileged functions to include disabling, circumventing, or altering implemented security safeguards/countermeasures. Use the following command to map a new user to the "sysdam_u" role: #semanage login -a -s sysadm_u <username> Use the following command to map an existing user to the "sysdam_u" role: #semanage login -m -s sysadm_u <username> Use the following command to map a new user to the "staff_u" role: #semanage login -a -s staff_u <username> Use the following command to map an existing user to the "staff_u" role: #semanage login -m -s staff_u <username> Use the following command to map a new user to the "user_u" role: # semanage login -a -s user_u <username> Use the following command to map an existing user to the "user_u" role: # semanage login -m -s user_u <username>

Generate Mitigation Statement:

Checks: C-97999r1_chk

Verify the operating system routinely checks the baseline configuration for unauthorized changes. Note: A file integrity tool other than Advanced Intrusion Detection Environment (AIDE) may be used, but the tool must be executed at least once per week. Check to see if AIDE is installed on the system with the following command: # yum list installed aide If AIDE is not installed, ask the SA how file integrity checks are performed on the system. Check for the presence of a cron job running daily or weekly on the system that executes AIDE daily to scan for changes to the system baseline. The command used in the example will use a daily occurrence. Check the cron directories for a script file controlling the execution of the file integrity application. For example, if AIDE is installed on the system, use the following command: # ls -al /etc/cron.* | grep aide -rwxr-xr-x 1 root root 29 Nov 22 2015 aide # grep aide /etc/crontab /var/spool/cron/root /etc/crontab: 30 04 * * * /root/aide /var/spool/cron/root: 30 04 * * * /root/aide If the file integrity application does not exist, or a script file controlling the execution of the file integrity application does not exist, this is a finding.

Fix: F-104835r1_fix

Configure the file integrity tool to run automatically on the system at least weekly. The following example output is generic. It will set cron to run AIDE daily, but other file integrity tools may be used: # more /etc/cron.daily/aide #!/bin/bash /usr/sbin/aide --check | /bin/mail -s "$HOSTNAME - Daily aide integrity check run" root@sysname.mil

Generate Mitigation Statement:

Checks: C-98007r1_chk

If there is an HBSS with a Device Control Module and a Data Loss Prevention mechanism, this requirement is not applicable. Verify the operating system disables the ability to use USB mass storage devices. Check to see if USB mass storage is disabled with the following command: # grep usb-storage /etc/modprobe.d/blacklist.conf blacklist usb-storage If the command does not return any output or the output is not "blacklist usb-storage", and use of USB storage devices is not documented with the Information System Security Officer (ISSO) as an operational requirement, this is a finding.

Fix: F-104843r1_fix

Configure the operating system to disable the ability to use USB mass storage devices. # vi /etc/modprobe.d/blacklist.conf Add or update the line: blacklist usb-storage

Generate Mitigation Statement:

Checks: C-98009r1_chk

Verify the operating system disables the ability to load the DCCP kernel module. # grep -r dccp /etc/modprobe.d/* | grep -i "/bin/true" | grep -v "^#" install dccp /bin/true If the command does not return any output, or the line is commented out, and use of DCCP is not documented with the Information System Security Officer (ISSO) as an operational requirement, this is a finding.

Fix: F-104845r1_fix

Configure the operating system to disable the ability to use the DCCP kernel module. Create a file under "/etc/modprobe.d" with the following command: # touch /etc/modprobe.d/dccp.conf Add the following line to the created file: install dccp /bin/true Ensure that the DCCP module is blacklisted: # vi /etc/modprobe.d/blacklist.conf Add or update the line: blacklist dccp

Generate Mitigation Statement:

Checks: C-98011r1_chk

Verify the operating system disables the ability to automount devices. Check to see if automounter service is active with the following command: # systemctl status autofs autofs.service - Automounts filesystems on demand Loaded: loaded (/usr/lib/systemd/system/autofs.service; disabled) Active: inactive (dead) If the "autofs" status is set to "active" and is not documented with the Information System Security Officer (ISSO) as an operational requirement, this is a finding.

Fix: F-104847r1_fix

Configure the operating system to disable the ability to automount devices. Turn off the automount service with the following commands: # systemctl stop autofs # systemctl disable autofs If "autofs" is required for Network File System (NFS), it must be documented with the ISSO.

Generate Mitigation Statement:

Checks: C-98019r1_chk

Verify the operating system defines default permissions for all authenticated users in such a way that the user can only read and modify their own files. Check for the value of the "UMASK" parameter in "/etc/login.defs" file with the following command: Note: If the value of the "UMASK" parameter is set to "000" in "/etc/login.defs" file, the Severity is raised to a CAT I. # grep -i umask /etc/login.defs UMASK 077 If the value for the "UMASK" parameter is not "077", or the "UMASK" parameter is missing or is commented out, this is a finding.

Fix: F-104855r1_fix

Configure the operating system to define default permissions for all authenticated users in such a way that the user can only read and modify their own files. Add or edit the line for the "UMASK" parameter in "/etc/login.defs" file to "077": UMASK 077

Generate Mitigation Statement:

Checks: C-98023r1_chk

Verify the operating system security patches and updates are installed and up to date. Updates are required to be applied with a frequency determined by the site or Program Management Office (PMO). Obtain the list of available package security updates from Oracle. The URL for updates is https://linux.oracle.com/errata/. It is important to note that updates provided by Oracle may not be present on the system if the underlying packages are not installed. Check that the available package security updates have been installed on the system with the following command: # yum history list | more Loaded plugins: langpacks, product-id, subscription-manager ID | Command line | Date and time | Action(s) | Altered ------------------------------------------------------------------------------- 70 | install aide | 2016-05-05 10:58 | Install | 1 69 | update -y | 2016-05-04 14:34 | Update | 18 EE 68 | install vlc | 2016-04-21 17:12 | Install | 21 67 | update -y | 2016-04-21 17:04 | Update | 7 EE 66 | update -y | 2016-04-15 16:47 | E, I, U | 84 EE If package updates have not been performed on the system within the timeframe required by the site/program documentation, this is a finding. Typical update frequency may be overridden by Information Assurance Vulnerability Alert (IAVA) notifications from CYBERCOM. If the operating system is in non-compliance with the Information Assurance Vulnerability Management (IAVM) process, this is a finding.

Fix: F-104859r2_fix

Install the operating system patches or updated packages available from Oracle within 30 days or sooner as local policy dictates.

Generate Mitigation Statement:

Checks: C-98025r1_chk

Verify all accounts on the system are assigned to an active system, application, or user account. Obtain the list of authorized system accounts from the Information System Security Officer (ISSO). Check the system accounts on the system with the following command: # more /etc/passwd root:x:0:0:root:/root:/bin/bash bin:x:1:1:bin:/bin:/sbin/nologin daemon:x:2:2:daemon:/sbin:/sbin/nologin sync:x:5:0:sync:/sbin:/bin/sync shutdown:x:6:0:shutdown:/sbin:/sbin/shutdown halt:x:7:0:halt:/sbin:/sbin/halt games:x:12:100:games:/usr/games:/sbin/nologin gopher:x:13:30:gopher:/var/gopher:/sbin/nologin Accounts such as "games" and "gopher" are not authorized accounts as they do not support authorized system functions. If the accounts on the system do not match the provided documentation, or accounts that do not support an authorized system function are present, this is a finding.

Fix: F-104861r1_fix

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. Document all authorized accounts on the system.

Generate Mitigation Statement:

Checks: C-98033r1_chk

Verify all files and directories on the system have a valid owner. Check the owner of all files and directories with the following command: Note: The value after -fstype must be replaced with the filesystem type. XFS is used as an example. # find / -fstype xfs -nouser If any files on the system do not have an assigned owner, this is a finding.

Fix: F-104869r1_fix

Either remove all files and directories from the system that do not have a valid user, or assign a valid user to all unowned files and directories on the system with the "chown" command: # chown <user> <file>

Generate Mitigation Statement:

Checks: C-98035r1_chk

Verify all files and directories on the system have a valid group. Check the owner of all files and directories with the following command: Note: The value after -fstype must be replaced with the filesystem type. XFS is used as an example. # find / -fstype xfs -nogroup If any files on the system do not have an assigned group, this is a finding.

Fix: F-104871r1_fix

Either remove all files and directories from the system that do not have a valid group, or assign a valid group to all files and directories on the system with the "chgrp" command: # chgrp <group> <file>

Generate Mitigation Statement:

Checks: C-98037r1_chk

Verify local interactive users on the system have a home directory assigned. Check for missing local interactive user home directories with the following command: # pwck -r user 'lp': directory '/var/spool/lpd' does not exist user 'news': directory '/var/spool/news' does not exist user 'uucp': directory '/var/spool/uucp' does not exist user 'smithj': directory '/home/smithj' does not exist Ask the System Administrator (SA) if any users found without home directories are local interactive users. If the SA is unable to provide a response, check for users with a User Identifier (UID) of 1000 or greater with the following command: # cut -d: -f 1,3 /etc/passwd | egrep ":[1-4][0-9]{2}$|:[0-9]{1,2}$" If any interactive users do not have a home directory assigned, this is a finding.

Fix: F-104873r1_fix

Assign home directories to all local interactive users that currently do not have a home directory assigned.

Generate Mitigation Statement:

Checks: C-98039r1_chk

Verify all local interactive users on the system are assigned a home directory upon creation. Check to see if the system is configured to create home directories for local interactive users with the following command: # grep -i create_home /etc/login.defs CREATE_HOME yes If the value for "CREATE_HOME" parameter is not set to "yes", the line is missing, or the line is commented out, this is a finding.

Fix: F-104875r1_fix

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

Generate Mitigation Statement:

Checks: C-98041r1_chk

Verify the assigned home directory of all local interactive users on the system exists. Check the home directory assignment for all local interactive non-privileged users on the system with the following command: # cut -d: -f 1,3,6 /etc/passwd | egrep ":[1-4][0-9]{3}" smithj:1001:/home/smithj Note: This may miss interactive users that have been assigned a privileged UID. Evidence of interactive use may be obtained from a number of log files containing system logon information. Check that all referenced home directories exist with the following command: # pwck -r user 'smithj': directory '/home/smithj' does not exist If any home directories referenced in "/etc/passwd" are returned as not defined, this is a finding.

Fix: F-104877r1_fix

Create home directories to all local interactive users that currently do not have a home directory assigned. Use the following commands to create the user home directory assigned in "/etc/ passwd": Note: The example will be for the user smithj, who has a home directory of "/home/smithj", a UID of "smithj", and a Group Identifier (GID) of "users" assigned in "/etc/passwd". # mkdir /home/smithj # chown smithj /home/smithj # chgrp users /home/smithj # chmod 0750 /home/smithj

Generate Mitigation Statement:

Checks: C-98043r1_chk

Verify the assigned home directory of all local interactive users has a mode of "0750" or less permissive. Check the home directory assignment for all non-privileged users on the system with the following command: Note: This may miss interactive users that have been assigned a privileged User Identifier (UID). Evidence of interactive use may be obtained from a number of log files containing system logon information. # ls -ld $(egrep ':[0-9]{4}' /etc/passwd | cut -d: -f6) -rwxr-x--- 1 smithj users 18 Mar 5 17:06 /home/smithj If home directories referenced in "/etc/passwd" do not have a mode of "0750" or less permissive, this is a finding.

Fix: F-104879r1_fix

Change the mode of interactive user's home directories to "0750". To change the mode of a local interactive user's home directory, use the following command: Note: The example will be for the user "smithj". # chmod 0750 /home/smithj

Generate Mitigation Statement:

Checks: C-98045r1_chk

Verify the assigned home directory of all local interactive users on the system exists. Check the home directory assignment for all local interactive users on the system with the following command: # ls -ld $(egrep ':[0-9]{4}' /etc/passwd | cut -d: -f6) -rwxr-x--- 1 smithj users 18 Mar 5 17:06 /home/smithj If any home directories referenced in "/etc/passwd" are not owned by the interactive user, this is a finding.

Fix: F-104881r1_fix

Change the owner of a local interactive user's home directories to that owner. To change the owner of a local interactive user's home directory, use the following command: Note: The example will be for the user smithj, who has a home directory of "/home/smithj". # chown smithj /home/smithj

Generate Mitigation Statement:

Checks: C-98047r1_chk

Verify the assigned home directory of all local interactive users is group-owned by that user's primary GID. Check the home directory assignment for all local interactive users on the system with the following command: # ls -ld $(egrep ':[0-9]{4}' /etc/passwd | cut -d: -f6) -rwxr-x--- 1 smithj users 18 Mar 5 17:06 /home/smithj Check the user's primary group with the following command: # grep users /etc/group users:x:250:smithj,jonesj,jacksons If the user home directory referenced in "/etc/passwd" is not group-owned by that user's primary GID, this is a finding.

Fix: F-104883r1_fix

Change the group owner of a local interactive user's home directory to the group found in "/etc/passwd". To change the group owner of a local interactive user's home directory, use the following command: Note: The example will be for the user "smithj", who has a home directory of "/home/smithj", and has a primary group of users. # chgrp users /home/smithj

Generate Mitigation Statement:

Checks: C-98049r1_chk

Verify all files and directories in a local interactive user's home directory are owned by the user. Check the owner of all files and directories in a local interactive user's home directory with the following command: Note: The example will be for the user "smithj", who has a home directory of "/home/smithj". # ls -lLR /home/smithj -rw-r--r-- 1 smithj smithj 18 Mar 5 17:06 file1 -rw-r--r-- 1 smithj smithj 193 Mar 5 17:06 file2 -rw-r--r-- 1 smithj smithj 231 Mar 5 17:06 file3 If any files are found with an owner different than the home directory user, this is a finding.

Fix: F-104885r1_fix

Change the owner of a local interactive user's files and directories to that owner. To change the owner of a local interactive user's files and directories, use the following command: Note: The example will be for the user smithj, who has a home directory of "/home/smithj". # chown smithj /home/smithj/<file or directory>

Generate Mitigation Statement:

Checks: C-98051r1_chk

Verify all files and directories in a local interactive user home directory are group-owned by a group of which the user is a member. Check the group owner of all files and directories in a local interactive user's home directory with the following command: Note: The example will be for the user "smithj", who has a home directory of "/home/smithj". # ls -lLR /&lt;home directory&gt;/&lt;users home directory&gt;/ -rw-r--r-- 1 smithj smithj 18 Mar 5 17:06 file1 -rw-r--r-- 1 smithj smithj 193 Mar 5 17:06 file2 -rw-r--r-- 1 smithj sa 231 Mar 5 17:06 file3 If any files are found with an owner different than the group home directory user, check to see if the user is a member of that group with the following command: # grep smithj /etc/group sa:x:100:juan,shelley,bob,smithj smithj:x:521:smithj If the user is not a member of a group that group-owns file(s) in a local interactive user's home directory, this is a finding.

Fix: F-104887r1_fix

Change the group of a local interactive user's files and directories to a group that the interactive user is a member of. To change the group owner of a local interactive user's files and directories, use the following command: Note: The example will be for the user smithj, who has a home directory of "/home/smithj" and is a member of the users group. # chgrp users /home/smithj/<file>

Generate Mitigation Statement:

Checks: C-98053r1_chk

Verify all files and directories contained in a local interactive user home directory, excluding local initialization files, have a mode of "0750". Check the mode of all non-initialization files in a local interactive user home directory with the following command: Files that begin with a "." are excluded from this requirement. Note: The example will be for the user "smithj", who has a home directory of "/home/smithj". # ls -lLR /home/smithj -rwxr-x--- 1 smithj smithj 18 Mar 5 17:06 file1 -rwxr----- 1 smithj smithj 193 Mar 5 17:06 file2 -rw-r-x--- 1 smithj smithj 231 Mar 5 17:06 file3 If any files are found with a mode more permissive than "0750", this is a finding.

Fix: F-104889r1_fix

Set the mode on files and directories in the local interactive user home directory with the following command: Note: The example will be for the user smithj, who has a home directory of "/home/smithj" and is a member of the users group. # chmod 0750 /home/smithj/<file>

Generate Mitigation Statement:

Checks: C-98055r1_chk

Verify all local initialization files for interactive users are owned by the home directory user or root. Check the owner on all local initialization files with the following command: Note: The example will be for the "smithj" user, who has a home directory of "/home/smithj". # ls -al /home/smithj/.* | more -rwxr-xr-x 1 smithj users 896 Mar 10 2011 .bash_profile -rwxr-xr-x 1 smithj users 497 Jan 6 2007 .login -rwxr-xr-x 1 smithj users 886 Jan 6 2007 .profile If any file that sets a local interactive user's environment variables to override the system is not owned by the home directory owner or root, this is a finding.

Fix: F-104891r1_fix

Set the owner of the local initialization files for interactive users to either the directory owner or root with the following command: Note: The example will be for the smithj user, who has a home directory of "/home/smithj". # chown smithj /home/smithj/.*

Generate Mitigation Statement:

Checks: C-98057r1_chk

Verify the local initialization files of all local interactive users are group-owned by that user's primary Group Identifier (GID). Check the home directory assignment for all non-privileged users on the system with the following command: Note: The example will be for the smithj user, who has a home directory of "/home/smithj" and a primary group of "users". # cut -d: -f 1,4,6 /etc/passwd | egrep ":[1-4][0-9]{3}" smithj:1000:/home/smithj # grep 1000 /etc/group users:x:1000:smithj,jonesj,jacksons Note: This may miss interactive users that have been assigned a privileged User Identifier (UID). Evidence of interactive use may be obtained from a number of log files containing system logon information. Check the group owner of all local interactive user's initialization files with the following command: # ls -al /home/smithj/.* -rwxr-xr-x 1 smithj users 896 Mar 10 2011 .profile -rwxr-xr-x 1 smithj users 497 Jan 6 2007 .login -rwxr-xr-x 1 smithj users 886 Jan 6 2007 .something If all local interactive user's initialization files are not group-owned by that user's primary GID, this is a finding.

Fix: F-104893r1_fix

Change the group owner of a local interactive user's files to the group found in "/etc/passwd" for the user. To change the group owner of a local interactive user's home directory, use the following command: Note: The example will be for the user smithj, who has a home directory of "/home/smithj", and has a primary group of users. # chgrp users /home/smithj/<file>

Generate Mitigation Statement:

Checks: C-98059r1_chk

Verify that all local initialization files have a mode of "0740" or less permissive. Check the mode on all local initialization files with the following command: Note: The example will be for the "smithj" user, who has a home directory of "/home/smithj". # ls -al /home/smithj/.* | more -rwxr----- 1 smithj users 896 Mar 10 2011 .profile -rwxr----- 1 smithj users 497 Jan 6 2007 .login -rwxr----- 1 smithj users 886 Jan 6 2007 .something If any local initialization files have a mode more permissive than "0740", this is a finding.

Fix: F-104895r1_fix

Set the mode of the local initialization files to "0740" with the following command: Note: The example will be for the "smithj" user, who has a home directory of "/home/smithj". # chmod 0740 /home/smithj/.<INIT_FILE>

Generate Mitigation Statement:

Checks: C-98061r1_chk

Verify that all local interactive user initialization files' executable search path statements do not contain statements that will reference a working directory other than the users' home directory. Check the executable search path statement for all local interactive user initialization files in the users' home directory with the following commands: Note: The example will be for the smithj user, which has a home directory of "/home/smithj". # grep -i path /home/smithj/.* /home/smithj/.bash_profile:PATH=$PATH:$HOME/.local/bin:$HOME/bin /home/smithj/.bash_profile:export PATH If any local interactive user initialization files have executable search path statements that include directories outside of their home directory, this is a finding.

Fix: F-104897r1_fix

Edit the local interactive user initialization files to change any PATH variable statements that reference directories other than their home directory. If a local interactive user requires path variables to reference a directory owned by the application, it must be documented with the ISSO.

Generate Mitigation Statement:

Checks: C-98063r1_chk

Verify that local initialization files do not execute world-writable programs. Check the system for world-writable files with the following command: # find / -xdev -perm -002 -type f -exec ls -ld {} \; | more For all files listed, check for their presence in the local initialization files with the following commands: Note: The example will be for a system that is configured to create users' home directories in the "/home" directory. # grep &lt;file&gt; /home/*/.* If any local initialization files are found to reference world-writable files, this is a finding.

Fix: F-104899r1_fix

Set the mode on files being executed by the local initialization files with the following command: # chmod 0755 <file>

Generate Mitigation Statement:

Checks: C-98065r1_chk

Verify that all system device files are correctly labeled to prevent unauthorized modification. List all device files on the system that are incorrectly labeled with the following commands: Note: Device files are normally found under "/dev", but applications may place device files in other directories and may necessitate a search of the entire system. #find /dev -context *:device_t:* \( -type c -o -type b \) -printf "%p %Z\n" #find /dev -context *:unlabeled_t:* \( -type c -o -type b \) -printf "%p %Z\n" Note: There are device files, such as "/dev/vmci", that are used when the operating system is a host virtual machine. They will not be owned by a user on the system and require the "device_t" label to operate. These device files are not a finding. If there is output from either of these commands, other than already noted, this is a finding.

Fix: F-104901r1_fix

Run the following command to determine which package owns the device 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>

Generate Mitigation Statement:

Checks: C-98067r1_chk

Verify file systems that contain user home directories are mounted with the "nosuid" option. Find the file system(s) that contain the user home directories with the following command: Note: If a separate file system has not been created for the user home directories (user home directories are mounted under "/"), this is not a finding as the "nosuid" option cannot be used on the "/" system. # cut -d: -f 1,3,6 /etc/passwd | egrep ":[1-4][0-9]{3}" smithj:1001:/home/smithj thomasr:1002:/home/thomasr Check the file systems mounted at boot time with the following command: # more /etc/fstab UUID=a411dc99-f2a1-4c87-9e05-184977be8539 /home ext4 rw,relatime,discard,data=ordered,nosuid 0 2 If a file system found in "/etc/fstab" refers to the user home directory file system and it does not have the "nosuid" option set, this is a finding.

Fix: F-104903r1_fix

Configure the "/etc/fstab" to use the "nosuid" option on file systems that contain user home directories.

Generate Mitigation Statement:

Checks: C-98069r1_chk

Verify file systems used for removable media are mounted with the "nosuid" option. Check the file systems mounted at boot time with the following command: # more /etc/fstab UUID=2bc871e4-e2a3-4f29-9ece-3be60c835222 /mnt/usbflash vfat noauto,owner,ro,nosuid 0 0 If a file system found in "/etc/fstab" refers to removable media and it does not have the "nosuid" option set, this is a finding.

Fix: F-104905r1_fix

Configure the "/etc/fstab" to use the "nosuid" option on file systems that are associated with removable media.

Generate Mitigation Statement:

Checks: C-98071r1_chk

Verify file systems being NFS imported are configured with the "nosuid" option. Find the file system(s) that contain the directories being exported with the following command: # more /etc/fstab | grep nfs UUID=e06097bb-cfcd-437b-9e4d-a691f5662a7d /store nfs rw,nosuid 0 0 If a file system found in "/etc/fstab" refers to NFS and it does not have the "nosuid" option set, this is a finding. Verify the NFS is mounted with the "nosuid" option: # mount | grep nfs | grep nosuid If no results are returned, this is a finding.

Fix: F-104907r1_fix

Configure the "/etc/fstab" to use the "nosuid" option on file systems that are being imported via NFS.

Generate Mitigation Statement:

Checks: C-98073r1_chk

Verify file systems that are being NFS imported are configured with the "noexec" option. Find the file system(s) that contain the directories being imported with the following command: # more /etc/fstab | grep nfs UUID=e06097bb-cfcd-437b-9e4d-a691f5662a7d /store nfs rw,noexec 0 0 If a file system found in "/etc/fstab" refers to NFS and it does not have the "noexec" option set, and use of NFS imported binaries is not documented with the Information System Security Officer (ISSO) as an operational requirement, this is a finding. Verify the NFS is mounted with the "noexec"option: # mount | grep nfs | grep noexec If no results are returned and use of NFS imported binaries is not documented with the Information System Security Officer (ISSO) as an operational requirement, this is a finding.

Fix: F-104909r1_fix

Configure the "/etc/fstab" to use the "noexec" option on file systems that are being imported via NFS.

Generate Mitigation Statement:

Checks: C-98081r1_chk

Verify all world-writable directories are group-owned by root, sys, bin, or an application group. Check the system for world-writable directories with the following command: Note: The value after -fstype must be replaced with the filesystem type. XFS is used as an example. # find / -xdev -perm -002 -type d -fstype xfs -exec ls -lLd {} \; drwxrwxrwt 2 root root 40 Aug 26 13:07 /dev/mqueue drwxrwxrwt 2 root root 220 Aug 26 13:23 /dev/shm drwxrwxrwt 14 root root 4096 Aug 26 13:29 /tmp If any world-writable directories are not owned by root, sys, bin, or an application group associated with the directory, this is a finding.

Fix: F-104917r1_fix

Change the group of the world-writable directories to root with the following command: # chgrp root <directory>

Generate Mitigation Statement:

Checks: C-98083r1_chk

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. # grep -i umask /home/*/.* If any local interactive user initialization files are found to have a umask statement that has a value less restrictive than "077", this is a finding.

Fix: F-104919r1_fix

Remove the umask statement from all local interactive user's initialization files. If the account is for an application, the requirement for a umask less restrictive than "077" can be documented with the Information System Security Officer, but the user agreement for access to the account must specify that the local interactive user must log on to their account first and then switch the user to the application account with the correct option to gain the account's environment variables.

Generate Mitigation Statement:

Checks: C-98085r1_chk

Verify that "rsyslog" is configured to log cron events. Check the configuration of "/etc/rsyslog.conf" or "/etc/rsyslog.d/*.conf" files for the cron facility with the following command: Note: If another logging package is used, substitute the utility configuration file for "/etc/rsyslog.conf" or "/etc/rsyslog.d/*.conf" files. # grep cron /etc/rsyslog.conf /etc/rsyslog.d/*.conf cron.* /var/log/cron.log If the command does not return a response, check for cron logging all facilities by inspecting the "/etc/rsyslog.conf" or "/etc/rsyslog.d/*.conf" files. Look for the following entry: *.* /var/log/messages If "rsyslog" is not logging messages for the cron facility or all facilities, this is a finding.

Fix: F-104921r1_fix

Configure "rsyslog" to log all cron messages by adding or updating the following line to "/etc/rsyslog.conf" or a configuration file in the /etc/rsyslog.d/ directory: cron.* /var/log/cron.log

Generate Mitigation Statement:

Checks: C-98087r1_chk

Verify that the "cron.allow" file is owned by root. Check the owner of the "cron.allow" file with the following command: # ls -al /etc/cron.allow -rw------- 1 root root 6 Mar 5 2011 /etc/cron.allow If the "cron.allow" file exists and has an owner other than root, this is a finding.

Fix: F-104923r1_fix

Set the owner on the "/etc/cron.allow" file to root with the following command: # chown root /etc/cron.allow

Generate Mitigation Statement:

Checks: C-98089r1_chk

Verify that the "cron.allow" file is group-owned by root. Check the group owner of the "cron.allow" file with the following command: # ls -al /etc/cron.allow -rw------- 1 root root 6 Mar 5 2011 /etc/cron.allow If the "cron.allow" file exists and has a group owner other than root, this is a finding.

Fix: F-104925r1_fix

Set the group owner on the "/etc/cron.allow" file to root with the following command: # chgrp root /etc/cron.allow

Generate Mitigation Statement:

Checks: C-98091r1_chk

Verify that kernel core dumps are disabled unless needed. Check the status of the "kdump" service with the following command: # systemctl status kdump.service kdump.service - Crash recovery kernel arming Loaded: loaded (/usr/lib/systemd/system/kdump.service; enabled) Active: active (exited) since Wed 2015-08-26 13:08:09 EDT; 43min ago Main PID: 1130 (code=exited, status=0/SUCCESS) kernel arming. If the "kdump" service is active, ask the System Administrator if the use of the service is required and documented with the Information System Security Officer (ISSO). If the service is active and is not documented, this is a finding.

Fix: F-104927r1_fix

If kernel core dumps are not required, disable the "kdump" service with the following command: # systemctl disable kdump.service If kernel core dumps are required, document the need with the ISSO.

Generate Mitigation Statement:

Checks: C-98107r1_chk

Verify the file integrity tool is configured to use FIPS 140-2 approved cryptographic hashes for validating file contents and directories. Note: If OL07-00-021350 is a finding, this is automatically a finding as the system cannot implement FIPS 140-2 approved cryptographic algorithms and hashes. Check to see if Advanced Intrusion Detection Environment (AIDE) is installed on the system with the following command: # yum list installed aide If AIDE is not installed, ask the System Administrator how file integrity checks are performed on the system. If there is no application installed to perform file integrity checks, this is a finding. Note: AIDE is highly configurable at install time. These commands assume the "aide.conf" file is under the "/etc" directory. Use the following command to determine if the file is in another location: # find / -name aide.conf Check the "aide.conf" file to determine if the "sha512" rule has been added to the rule list being applied to the files and directories selection lists. An example rule that includes the "sha512" rule follows: All=p+i+n+u+g+s+m+S+sha512+acl+xattrs+selinux /bin All # apply the custom rule to the files in bin /sbin All # apply the same custom rule to the files in sbin If the "sha512" rule is not being used on all uncommented selection lines in the "/etc/aide.conf" file, or another file integrity tool is not using FIPS 140-2 approved cryptographic hashes for validating file contents and directories, this is a finding.

Fix: F-104943r1_fix

Configure the file integrity tool to use FIPS 140-2 cryptographic hashes for validating file and directory contents. If AIDE is installed, ensure the "sha512" rule is present on all uncommented file and directory selection lists.

Generate Mitigation Statement:

Checks: C-98109r1_chk

Verify the system is not configured to use a boot loader on removable media. Note: GRUB 2 reads its configuration from the "/boot/grub2/grub.cfg" file on traditional BIOS-based machines and from the "/boot/efi/EFI/redhat/grub.cfg" file on UEFI machines. Check for the existence of alternate boot loader configuration files with the following command: # find / -name grub.cfg /boot/grub2/grub.cfg If a "grub.cfg" is found in any subdirectories other than "/boot/grub2" and "/boot/efi/EFI/redhat", ask the System Administrator if there is documentation signed by the ISSO to approve the use of removable media as a boot loader. Check that the grub configuration file has the set root command in each menu entry with the following commands: # grep -c menuentry /boot/grub2/grub.cfg 1 # grep 'set root' /boot/grub2/grub.cfg set root=(hd0,1) If the system is using an alternate boot loader on removable media, and documentation does not exist approving the alternate configuration, this is a finding.

Fix: F-104945r1_fix

Remove alternate methods of booting the system from removable media or document the configuration to boot from removable media with the ISSO.

Generate Mitigation Statement:

Checks: C-98115r1_chk

Confirm the audit configuration regarding how auditing processing failures are handled. Check to see what level "auditctl" is set to with following command: # auditctl -s | grep -i "fail" failure 2 If the value of "failure" is set to "2", the system is configured to panic (shut down) in the event of an auditing failure. If the value of "failure" is set to "1", the system is configured only to send information to the kernel log regarding the failure. If the "failure" setting is not set, this is a CAT I finding. If the "failure" setting is set to any value other than "1" or "2", this is a CAT II finding. If the "failure" setting is set to "1" but the availability concern is not documented or there is no monitoring of the kernel log, this is a CAT III finding.

Fix: F-104951r1_fix

Configure the operating system to shut down in the event of an audit processing failure. Add or correct the option to shut down the operating system with the following command: # auditctl -f 2 Edit the "/etc/audit/rules.d/audit.rules" file and add the following line: -f 2 If availability has been determined to be more important, and this decision is documented with the ISSO, configure the operating system to notify system administration staff and ISSO staff in the event of an audit processing failure with the following command: # auditctl -f 1 Edit the "/etc/audit/rules.d/audit.rules" file and add the following line: -f 1 Kernel log monitoring must also be configured to properly alert designated staff. The audit daemon must be restarted for the changes to take effect.

Generate Mitigation Statement:

Checks: C-98117r1_chk

Verify the "au-remote" plugin is active on the system: # grep "active" /etc/audisp/plugins.d/au-remote.conf active = yes If the "active" setting is not set to "yes", or the line is commented out, this is a finding.

Fix: F-104953r1_fix

Edit the /etc/audisp/plugins.d/au-remote.conf file and change the value of "active" to "yes". The audit daemon must be restarted for changes to take effect: # service auditd restart

Generate Mitigation Statement:

Checks: C-98119r1_chk

Verify the "au-remote" plugin is configured to always off-load audit logs using the audisp-remote daemon: # cat /etc/audisp/plugins.d/au-remote.conf | grep -v "^#" active = yes direction = out path = /sbin/audisp-remote type = always format = string If the "direction" setting is not set to "out", or the line is commented out, this is a finding. If the "path" setting is not set to "/sbin/audisp-remote", or the line is commented out, this is a finding. If the "type" setting is not set to "always", or the line is commented out, this is a finding.

Fix: F-104955r1_fix

Edit the /etc/audisp/plugins.d/au-remote.conf file and add or update the following values: direction = out path = /sbin/audisp-remote type = always The audit daemon must be restarted for changes to take effect: # service auditd restart

Generate Mitigation Statement:

Checks: C-98121r1_chk

Verify the audisp daemon is configured to take an appropriate action when the internal queue is full: # grep "overflow_action" /etc/audisp/audispd.conf overflow_action = syslog If the "overflow_action" option is not "syslog", "single", or "halt", or the line is commented out, this is a finding.

Fix: F-104957r1_fix

Edit the /etc/audisp/audispd.conf file and add or update the "overflow_action" option: overflow_action = syslog The audit daemon must be restarted for changes to take effect: # service auditd restart

Generate Mitigation Statement:

Checks: C-98123r1_chk

Verify the audisp daemon is configured to label all off-loaded audit logs: # grep "name_format" /etc/audisp/audispd.conf name_format = hostname If the "name_format" option is not "hostname", "fqd", or "numeric", or the line is commented out, this is a finding.

Fix: F-104959r1_fix

Edit the /etc/audisp/audispd.conf file and add or update the "name_format" option: name_format = hostname The audit daemon must be restarted for changes to take effect: # service auditd restart

Generate Mitigation Statement:

Checks: C-98125r1_chk

Verify the operating system off-loads audit records onto a different system or media from the system being audited. To determine the remote server that the records are being sent to, use the following command: # grep -i remote_server /etc/audisp/audisp-remote.conf remote_server = 10.0.21.1 If a remote server is not configured, 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. If there is no evidence that the audit logs are being off-loaded to another system or media, this is a finding.

Fix: F-104961r1_fix

Configure the operating system to off-load audit records onto a different system or media from the system being audited. Set the remote server option in "/etc/audisp/audisp-remote.conf" with the IP address of the log aggregation server.

Generate Mitigation Statement:

Checks: C-98127r1_chk

Verify the operating system encrypts audit records off-loaded onto a different system or media from the system being audited. To determine if the transfer is encrypted, use the following command: # grep -i enable_krb5 /etc/audisp/audisp-remote.conf enable_krb5 = yes If the value of the "enable_krb5" option is not set to "yes" 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. If there is no evidence that the transfer of the audit logs being off-loaded to another system or media is encrypted, this is a finding.

Fix: F-104963r1_fix

Configure the operating system to encrypt the transfer of off-loaded audit records onto a different system or media from the system being audited. Uncomment the "enable_krb5" option in "/etc/audisp/audisp-remote.conf" and set it with the following line: enable_krb5 = yes

Generate Mitigation Statement:

Checks: C-98129r1_chk

Verify the action the operating system takes if the disk the audit records are written to becomes full. To determine the action that takes place if the disk is full on the remote server, use the following command: # grep -i disk_full_action /etc/audisp/audisp-remote.conf disk_full_action = single If the value of the "disk_full_action" option is not "syslog", "single", or "halt", or the line is commented out, this is a finding.

Fix: F-104965r1_fix

Configure the action the operating system takes if the disk the audit records are written to becomes full. Uncomment or edit the "disk_full_action" option in "/etc/audisp/audisp-remote.conf" and set it to "syslog", "single", or "halt", such as the following line: disk_full_action = single

Generate Mitigation Statement:

Checks: C-98131r1_chk

Verify the action the operating system takes if there is an error sending audit records to a remote system. Check the action that takes place if there is an error sending audit records to a remote system with the following command: # grep -i network_failure_action /etc/audisp/audisp-remote.conf network_failure_action = syslog If the value of the "network_failure_action" option is not "syslog", "single", or "halt", or the line is commented out, this is a finding.

Fix: F-104967r1_fix

Configure the action the operating system takes if there is an error sending audit records to a remote system. Uncomment the "network_failure_action" option in "/etc/audisp/audisp-remote.conf" and set it to "syslog", "single", or "halt". network_failure_action = syslog

Generate Mitigation Statement:

Checks: C-98133r1_chk

Verify the operating system initiates an action to notify the SA and ISSO (at a minimum) when allocated audit record storage volume reaches 75 percent of the repository maximum audit record storage capacity. Check the system configuration to determine the partition the audit records are being written to with the following command: # grep -iw 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 example being "/var/log/audit/"): # df -h /var/log/audit/ 0.9G /var/log/audit If the audit records are not being written to a partition specifically created for audit records (in this example "/var/log/audit" is a separate partition), determine the amount of space other files in the partition are currently occupying with the following command: # du -sh &lt;partition&gt; 1.8G /var Determine what the threshold is for the system to take action when 75 percent of the repository maximum audit record storage capacity is reached: # grep -iw space_left /etc/audit/auditd.conf space_left = 225 If the value of the "space_left" keyword is not set to 75 percent of the total partition size, this is a finding.

Fix: F-104969r1_fix

Configure the operating system to initiate an action to notify the SA and ISSO (at a minimum) when allocated audit record storage volume reaches 75 percent of the repository maximum audit record storage capacity. Check the system configuration to determine the partition the audit records are being written to: # grep -iw log_file /etc/audit/auditd.conf Determine the size of the partition that audit records are written to (with the example being "/var/log/audit/"): # df -h /var/log/audit/ Set the value of the "space_left" keyword in "/etc/audit/auditd.conf" to 75 percent of the partition size.

Generate Mitigation Statement:

Checks: C-98135r1_chk

Verify the operating system immediately notifies the SA and ISSO (at a minimum) via email when the allocated audit record storage volume reaches 75 percent of the repository maximum audit record storage capacity. Check what action the operating system takes when the threshold for the repository maximum audit record storage capacity is reached with the following command: # grep -i space_left_action /etc/audit/auditd.conf space_left_action = email If the value of the "space_left_action" keyword is not set to "email", this is a finding.

Fix: F-104971r1_fix

Configure the operating system to immediately notify the SA and ISSO (at a minimum) when the threshold for the repository maximum audit record storage capacity is reached. Uncomment or edit the "space_left_action" keyword in "/etc/audit/auditd.conf" and set it to "email". space_left_action = email

Generate Mitigation Statement:

Checks: C-98137r1_chk

Verify the operating system immediately notifies the SA and ISSO (at a minimum) via email when the threshold for the repository maximum audit record storage capacity is reached. Check what account the operating system emails when the threshold for the repository maximum audit record storage capacity is reached with the following command: # grep -i action_mail_acct /etc/audit/auditd.conf action_mail_acct = root If the value of the "action_mail_acct" keyword is not set to "root" and other accounts for security personnel, this is a finding.

Fix: F-104973r1_fix

Configure the operating system to immediately notify the SA and ISSO (at a minimum) when the threshold for the repository maximum audit record storage capacity is reached. Uncomment or edit the "action_mail_acct" keyword in "/etc/audit/auditd.conf" and set it to root and any other accounts associated with security personnel. action_mail_acct = root

Generate Mitigation Statement:

Checks: C-98139r1_chk

Verify the operating system audits the execution of privileged functions using the following command: # grep -iw execve /etc/audit/audit.rules -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 Note: The output lines of the command are duplicated to cover both 32-bit and 64-bit architectures. Only the lines appropriate for the system architecture must be present. If the audit rule for "SUID" files is not defined, this is a finding. If the audit rule for "SGID" files is not defined, this is a finding.

Fix: F-104975r1_fix

Configure the operating system to audit the execution of privileged functions. Add or update the following rule in "/etc/audit/rules.d/audit.rules": Note: The rules are duplicated to cover both 32-bit and 64-bit architectures. Only the lines appropriate for the system architecture must be configured. -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 The audit daemon must be restarted for the changes to take effect.

Generate Mitigation Statement:

Checks: C-98141r2_chk

Verify the operating system generates audit records when successful/unsuccessful attempts to use the "chown" syscall occur. Check the file system rules in "/etc/audit/audit.rules" with the following commands: Note: The output lines of the command are duplicated to cover both 32-bit and 64-bit architectures. Only the lines appropriate for the system architecture must be present. # grep -iw chown /etc/audit/audit.rules -a always,exit -F arch=b32 -S chown -F auid&gt;=1000 -F auid!=unset -k perm_mod -a always,exit -F arch=b64 -S chown -F auid&gt;=1000 -F auid!=unset -k perm_mod If there are no audit rules defined for the "chown" syscall, this is a finding.

Fix: F-104977r2_fix

Add or update the following rule in "/etc/audit/rules.d/audit.rules": Note: The rules are duplicated to cover both 32-bit and 64-bit architectures. Only the lines appropriate for the system architecture must be configured. -a always,exit -F arch=b32 -S chown -F auid>=1000 -F auid!=unset -k perm_mod -a always,exit -F arch=b64 -S chown -F auid>=1000 -F auid!=unset -k perm_mod The audit daemon must be restarted for the changes to take effect.

Generate Mitigation Statement:

Checks: C-98143r3_chk

Verify the operating system generates audit records when successful/unsuccessful attempts to use the "fchown" syscall occur. Check the file system rules in "/etc/audit/audit.rules" with the following commands: Note: The output lines of the command are duplicated to cover both 32-bit and 64-bit architectures. Only the lines appropriate for the system architecture must be present. # grep -iw fchown /etc/audit/audit.rules -a always,exit -F arch=b32 -S fchown -F auid&gt;=1000 -F auid!=unset -k perm_mod -a always,exit -F arch=b64 -S fchown -F auid&gt;=1000 -F auid!=unset -k perm_mod If there are no audit rules defined for the "fchown" syscall, this is a finding.

Fix: F-104979r3_fix

Add or update the following rule in "/etc/audit/rules.d/audit.rules": Note: The rules are duplicated to cover both 32-bit and 64-bit architectures. Only the lines appropriate for the system architecture must be configured. -a always,exit -F arch=b32 -S fchown -F auid>=1000 -F auid!=unset -k perm_mod -a always,exit -F arch=b64 -S fchown -F auid>=1000 -F auid!=unset -k perm_mod The audit daemon must be restarted for the changes to take effect.

Generate Mitigation Statement:

Checks: C-98145r2_chk

Verify the operating system generates audit records when successful/unsuccessful attempts to use the "lchown" syscall occur. Check the file system rules in "/etc/audit/audit.rules" with the following commands: Note: The output lines of the command are duplicated to cover both 32-bit and 64-bit architectures. Only the lines appropriate for the system architecture must be present. # grep -iw lchown /etc/audit/audit.rules -a always,exit -F arch=b32 -S lchown -F auid&gt;=1000 -F auid!=unset -k perm_mod -a always,exit -F arch=b64 -S lchown -F auid&gt;=1000 -F auid!=unset -k perm_mod If there are no audit rules defined for the "lchown" syscall, this is a finding.

Fix: F-104981r2_fix

Add or update the following rule in "/etc/audit/rules.d/audit.rules": Note: The rules are duplicated to cover both 32-bit and 64-bit architectures. Only the lines appropriate for the system architecture must be configured. -a always,exit -F arch=b32 -S lchown -F auid>=1000 -F auid!=unset -k perm_mod -a always,exit -F arch=b64 -S lchown -F auid>=1000 -F auid!=unset -k perm_mod The audit daemon must be restarted for the changes to take effect.

Generate Mitigation Statement:

Checks: C-98147r2_chk

Verify the operating system generates audit records when successful/unsuccessful attempts to use the "fchownat" syscall occur. Check the file system rules in "/etc/audit/audit.rules" with the following commands: Note: The output lines of the command are duplicated to cover both 32-bit and 64-bit architectures. Only the lines appropriate for the system architecture must be present. # grep -iw fchownat /etc/audit/audit.rules -a always,exit -F arch=b32 -S fchownat -F auid&gt;=1000 -F auid!=unset -k perm_mod -a always,exit -F arch=b64 -S fchownat -F auid&gt;=1000 -F auid!=unset -k perm_mod If there are no audit rules defined for the "fchownat" syscall, this is a finding.

Fix: F-104983r2_fix

Add or update the following rule in "/etc/audit/rules.d/audit.rules": Note: The rules are duplicated to cover both 32-bit and 64-bit architectures. Only the lines appropriate for the system architecture must be configured. -a always,exit -F arch=b32 -S fchownat -F auid>=1000 -F auid!=unset -k perm_mod -a always,exit -F arch=b64 -S fchownat -F auid>=1000 -F auid!=unset -k perm_mod The audit daemon must be restarted for the changes to take effect.

Generate Mitigation Statement:

Checks: C-98149r2_chk

Verify the operating system generates audit records when successful/unsuccessful attempts to use the "chmod" syscall occur. Check the file system rules in "/etc/audit/audit.rules" with the following command: Note: The output lines of the command are duplicated to cover both 32-bit and 64-bit architectures. Only the lines appropriate for the system architecture must be present. # grep -iw chmod /etc/audit/audit.rules -a always,exit -F arch=b32 -S chmod -F auid&gt;=1000 -F auid!=unset -k perm_mod -a always,exit -F arch=b64 -S chmod -F auid&gt;=1000 -F auid!=unset -k perm_mod If there are no audit rules defined for the "chmod" syscall, this is a finding.

Fix: F-104985r2_fix

Configure the operating system to generate audit records when successful/unsuccessful attempts to use the "chmod" syscall occur. Add or update the following rule in "/etc/audit/rules.d/audit.rules": Note: The rules are duplicated to cover both 32-bit and 64-bit architectures. Only the lines appropriate for the system architecture must be configured. -a always,exit -F arch=b32 -S chmod -F auid>=1000 -F auid!=unset -k perm_mod -a always,exit -F arch=b64 -S chmod -F auid>=1000 -F auid!=unset -k perm_mod The audit daemon must be restarted for the changes to take effect.

Generate Mitigation Statement:

Checks: C-98151r2_chk

Verify the operating system generates audit records when successful/unsuccessful attempts to use the "fchmod" syscall occur. Check the file system rules in "/etc/audit/audit.rules" with the following command: Note: The output lines of the command are duplicated to cover both 32-bit and 64-bit architectures. Only the lines appropriate for the system architecture must be present. # grep -iw fchmod /etc/audit/audit.rules -a always,exit -F arch=b32 -S fchmod -F auid&gt;=1000 -F auid!=unset -k perm_mod -a always,exit -F arch=b64 -S fchmod -F auid&gt;=1000 -F auid!=unset -k perm_mod If there are no audit rules defined for the "fchmod" syscall, this is a finding.

Fix: F-104987r2_fix

Configure the operating system to generate audit records when successful/unsuccessful attempts to use the "fchmod" syscall occur. Add or update the following rule in "/etc/audit/rules.d/audit.rules": Note: The rules are duplicated to cover both 32-bit and 64-bit architectures. Only the lines appropriate for the system architecture must be configured. -a always,exit -F arch=b32 -S fchmod -F auid>=1000 -F auid!=unset -k perm_mod -a always,exit -F arch=b64 -S fchmod -F auid>=1000 -F auid!=unset -k perm_mod The audit daemon must be restarted for the changes to take effect.

Generate Mitigation Statement:

Checks: C-98153r2_chk

Verify the operating system generates audit records when successful/unsuccessful attempts to use the "fchmodat" syscall occur. Check the file system rules in "/etc/audit/audit.rules" with the following command: Note: The output lines of the command are duplicated to cover both 32-bit and 64-bit architectures. Only the lines appropriate for the system architecture must be present. # grep -iw fchmodat /etc/audit/audit.rules -a always,exit -F arch=b32 -S fchmodat -F auid&gt;=1000 -F auid!=unset -k perm_mod -a always,exit -F arch=b64 -S fchmodat -F auid&gt;=1000 -F auid!=unset -k perm_mod If there are no audit rules defined for the "fchmodat" syscall, this is a finding.

Fix: F-104989r2_fix

Configure the operating system to generate audit records when successful/unsuccessful attempts to use the "fchmodat" syscall occur. Add or update the following rule in "/etc/audit/rules.d/audit.rules": Note: The rules are duplicated to cover both 32-bit and 64-bit architectures. Only the lines appropriate for the system architecture must be configured. -a always,exit -F arch=b32 -S fchmodat -F auid>=1000 -F auid!=unset -k perm_mod -a always,exit -F arch=b64 -S fchmodat -F auid>=1000 -F auid!=unset -k perm_mod The audit daemon must be restarted for the changes to take effect.

Generate Mitigation Statement:

Checks: C-98155r2_chk

Verify the operating system generates audit records when successful/unsuccessful attempts to use the "setxattr" syscall occur. Check the file system rules in "/etc/audit/audit.rules" with the following commands: Note: The output lines of the command are duplicated to cover both 32-bit and 64-bit architectures. Only the lines appropriate for the system architecture must be present. # grep -iw setxattr /etc/audit/audit.rules -a always,exit -F arch=b32 -S setxattr -F auid&gt;=1000 -F auid!=unset -k perm_mod -a always,exit -F arch=b64 -S setxattr -F auid&gt;=1000 -F auid!=unset -k perm_mod If there are no audit rules defined for the "setxattr" syscall, this is a finding.

Fix: F-104991r2_fix

Configure the operating system to generate audit records when successful/unsuccessful attempts to use the "setxattr" syscall occur. Add or update the following rule in "/etc/audit/rules.d/audit.rules": Note: The rules are duplicated to cover both 32-bit and 64-bit architectures. Only the lines appropriate for the system architecture must be configured. -a always,exit -F arch=b32 -S setxattr -F auid>=1000 -F auid!=unset -k perm_mod -a always,exit -F arch=b64 -S setxattr -F auid>=1000 -F auid!=unset -k perm_mod The audit daemon must be restarted for the changes to take effect.

Generate Mitigation Statement:

Checks: C-98157r2_chk

Verify the operating system generates audit records when successful/unsuccessful attempts to use the "fsetxattr" syscall occur. Check the file system rules in "/etc/audit/audit.rules" with the following commands: Note: The output lines of the command are duplicated to cover both 32-bit and 64-bit architectures. Only the lines appropriate for the system architecture must be present. # grep -iw fsetxattr /etc/audit/audit.rules -a always,exit -F arch=b32 -S fsetxattr -F auid&gt;=1000 -F auid!=unset -k perm_mod -a always,exit -F arch=b64 -S fsetxattr -F auid&gt;=1000 -F auid!=unset -k perm_mod If there are no audit rules defined for the "fsetxattr" syscall, this is a finding.

Fix: F-104993r2_fix

Configure the operating system to generate audit records when successful/unsuccessful attempts to use the "fsetxattr" syscall occur. Add or update the following rule in "/etc/audit/rules.d/audit.rules": Note: The rules are duplicated to cover both 32-bit and 64-bit architectures. Only the lines appropriate for the system architecture must be configured. -a always,exit -F arch=b32 -S fsetxattr -F auid>=1000 -F auid!=unset -k perm_mod -a always,exit -F arch=b64 -S fsetxattr -F auid>=1000 -F auid!=unset -k perm_mod The audit daemon must be restarted for the changes to take effect.

Generate Mitigation Statement:

Checks: C-98159r2_chk

Verify the operating system generates audit records when successful/unsuccessful attempts to use the "lsetxattr" syscall occur. Check the file system rules in "/etc/audit/audit.rules" with the following commands: Note: The output lines of the command are duplicated to cover both 32-bit and 64-bit architectures. Only the lines appropriate for the system architecture must be present. # grep -iw lsetxattr /etc/audit/audit.rules -a always,exit -F arch=b32 -S lsetxattr -F auid&gt;=1000 -F auid!=unset -k perm_mod -a always,exit -F arch=b64 -S lsetxattr -F auid&gt;=1000 -F auid!=unset -k perm_mod If there are no audit rules defined for the "lsetxattr" syscall, this is a finding.

Fix: F-104995r2_fix

Configure the operating system to generate audit records when successful/unsuccessful attempts to use the "lsetxattr" syscall occur. Add or update the following rule in "/etc/audit/rules.d/audit.rules": Note: The rules are duplicated to cover both 32-bit and 64-bit architectures. Only the lines appropriate for the system architecture must be configured. -a always,exit -F arch=b32 -S lsetxattr -F auid>=1000 -F auid!=unset -k perm_mod -a always,exit -F arch=b64 -S lsetxattr -F auid>=1000 -F auid!=unset -k perm_mod The audit daemon must be restarted for the changes to take effect.

Generate Mitigation Statement:

Checks: C-98161r2_chk

Verify the operating system generates audit records when successful/unsuccessful attempts to use the "removexattr" syscall occur. Check the file system rules in "/etc/audit/audit.rules" with the following commands: Note: The output lines of the command are duplicated to cover both 32-bit and 64-bit architectures. Only the lines appropriate for the system architecture must be present. # grep -iw removexattr /etc/audit/audit.rules -a always,exit -F arch=b32 -S removexattr -F auid&gt;=1000 -F auid!=unset -k perm_mod -a always,exit -F arch=b64 -S removexattr -F auid&gt;=1000 -F auid!=unset -k perm_mod If there are no audit rules defined for the "removexattr" syscall, this is a finding.

Fix: F-104997r2_fix

Configure the operating system to generate audit records when successful/unsuccessful attempts to use the "removexattr" syscall occur. Add or update the following rule in "/etc/audit/rules.d/audit.rules": Note: The rules are duplicated to cover both 32-bit and 64-bit architectures. Only the lines appropriate for the system architecture must be configured. -a always,exit -F arch=b32 -S removexattr -F auid>=1000 -F auid!=unset -k perm_mod -a always,exit -F arch=b64 -S removexattr -F auid>=1000 -F auid!=unset -k perm_mod The audit daemon must be restarted for the changes to take effect.

Generate Mitigation Statement:

Checks: C-98163r2_chk

Verify the operating system generates audit records when successful/unsuccessful attempts to use the "fremovexattr" syscall occur. Check the file system rules in "/etc/audit/audit.rules" with the following commands: Note: The output lines of the command are duplicated to cover both 32-bit and 64-bit architectures. Only the lines appropriate for the system architecture must be present. # grep -iw fremovexattr /etc/audit/audit.rules -a always,exit -F arch=b32 -S fremovexattr -F auid&gt;=1000 -F auid!=unset -k perm_mod -a always,exit -F arch=b64 -S fremovexattr -F auid&gt;=1000 -F auid!=unset -k perm_mod If there are no audit rules defined for the "fremovexattr" syscall, this is a finding.

Fix: F-104999r2_fix

Configure the operating system to generate audit records when successful/unsuccessful attempts to use the "fremovexattr" syscall occur. Add or update the following rule in "/etc/audit/rules.d/audit.rules": Note: The rules are duplicated to cover both 32-bit and 64-bit architectures. Only the lines appropriate for the system architecture must be configured. -a always,exit -F arch=b32 -S fremovexattr -F auid>=1000 -F auid!=unset -k perm_mod -a always,exit -F arch=b64 -S fremovexattr -F auid>=1000 -F auid!=unset -k perm_mod The audit daemon must be restarted for the changes to take effect.

Generate Mitigation Statement:

Checks: C-98165r2_chk

Verify the operating system generates audit records when successful/unsuccessful attempts to use the "lremovexattr" syscall occur. Check the file system rules in "/etc/audit/audit.rules" with the following commands: Note: The output lines of the command are duplicated to cover both 32-bit and 64-bit architectures. Only the lines appropriate for the system architecture must be present. # grep -iw lremovexattr /etc/audit/audit.rules -a always,exit -F arch=b32 -S lremovexattr -F auid&gt;=1000 -F auid!=unset -k perm_mod -a always,exit -F arch=b64 -S lremovexattr -F auid&gt;=1000 -F auid!=unset -k perm_mod If there are no audit rules defined for the "lremovexattr" syscall, this is a finding.

Fix: F-105001r2_fix

Configure the operating system to generate audit records when successful/unsuccessful attempts to use the "lremovexattr" syscall occur. Add or update the following rule in "/etc/audit/rules.d/audit.rules": Note: The rules are duplicated to cover both 32-bit and 64-bit architectures. Only the lines appropriate for the system architecture must be configured. -a always,exit -F arch=b32 -S lremovexattr -F auid>=1000 -F auid!=unset -k perm_mod -a always,exit -F arch=b64 -S lremovexattr -F auid>=1000 -F auid!=unset -k perm_mod The audit daemon must be restarted for the changes to take effect.

Generate Mitigation Statement:

Checks: C-98167r2_chk

Verify the operating system generates audit records when successful/unsuccessful attempts to use the "creat" syscall occur. Check the file system rules in "/etc/audit/audit.rules" with the following commands: Note: The output lines of the command are duplicated to cover both 32-bit and 64-bit architectures. Only the lines appropriate for the system architecture must be present. # grep -iw creat /etc/audit/audit.rules -a always,exit -F arch=b32 -S creat F exit=-EPERM -F auid&gt;=1000 -F auid!=unset -k access -a always,exit -F arch=b32 -S creat -F exit=-EACCES -F auid&gt;=1000 -F auid!=unset -k access -a always,exit -F arch=b64 -S creat -F exit=-EPERM -F auid&gt;=1000 -F auid!=unset -k access -a always,exit -F arch=b64 -S creat -F exit=-EACCES -F auid&gt;=1000 -F auid!=unset -k access If there are no audit rules defined for the "creat" syscall, this is a finding. If the output does not produce a rule containing "-F exit=-EPERM", this is a finding. If the output does not produce a rule containing "-F exit=-EACCES", this is a finding.

Fix: F-105003r2_fix

Configure the operating system to generate audit records when successful/unsuccessful attempts to use the "creat" syscall occur. Add or update the following rule in "/etc/audit/rules.d/audit.rules: Note: The rules are duplicated to cover both 32-bit and 64-bit architectures. Only the lines appropriate for the system architecture must be configured. -a always,exit -F arch=b32 -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=-EPERM -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 The audit daemon must be restarted for the changes to take effect.

Generate Mitigation Statement:

Checks: C-98169r2_chk

Verify the operating system generates audit records when successful/unsuccessful attempts to use the "open" syscall occur. Check the file system rules in "/etc/audit/audit.rules" with the following commands: Note: The output lines of the command are duplicated to cover both 32-bit and 64-bit architectures. Only the lines appropriate for the system architecture must be present. # grep -iw open /etc/audit/audit.rules -a always,exit -F arch=b32 -S open -F exit=-EPERM -F auid&gt;=1000 -F auid!=unset -k access -a always,exit -F arch=b32 -S open -F exit=-EACCES -F auid&gt;=1000 -F auid!=unset -k access -a always,exit -F arch=b64 -S open -F exit=-EPERM -F auid&gt;=1000 -F auid!=unset -k access -a always,exit -F arch=b64 -S open -F exit=-EACCES -F auid&gt;=1000 -F auid!=unset -k access If there are no audit rules defined for the "open" syscall, this is a finding. If the output does not produce a rule containing "-F exit=-EPERM", this is a finding. If the output does not produce a rule containing "-F exit=-EACCES", this is a finding.

Fix: F-105005r2_fix

Configure the operating system to generate audit records when successful/unsuccessful attempts to use the "open" syscall occur. Add or update the following rule in "/etc/audit/rules.d/audit.rules": Note: The rules are duplicated to cover both 32-bit and 64-bit architectures. Only the lines appropriate for the system architecture must be configured. -a always,exit -F arch=b32 -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=-EPERM -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 The audit daemon must be restarted for the changes to take effect.

Generate Mitigation Statement:

Checks: C-98171r2_chk

Verify the operating system generates audit records when successful/unsuccessful attempts to use the "openat" syscall occur. Check the file system rules in "/etc/audit/audit.rules" with the following commands: Note: The output lines of the command are duplicated to cover both 32-bit and 64-bit architectures. Only the lines appropriate for the system architecture must be present. # grep -iw openat /etc/audit/audit.rules -a always,exit -F arch=b32 -S openat -F exit=-EPERM -F auid&gt;=1000 -F auid!=unset -k access -a always,exit -F arch=b32 -S openat -F exit=-EACCES -F auid&gt;=1000 -F auid!=unset -k access -a always,exit -F arch=b64 -S openat -F exit=-EPERM -F auid&gt;=1000 -F auid!=unset -k access -a always,exit -F arch=b64 -S openat -F exit=-EACCES -F auid&gt;=1000 -F auid!=unset -k access If there are no audit rules defined for the "openat" syscall, this is a finding. If the output does not produce a rule containing "-F exit=-EPERM", this is a finding. If the output does not produce a rule containing "-F exit=-EACCES", this is a finding.

Fix: F-105007r2_fix

Configure the operating system to generate audit records when successful/unsuccessful attempts to use the "openat" syscall occur. Add or update the following rule in "/etc/audit/rules.d/audit.rules": Note: The rules are duplicated to cover both 32-bit and 64-bit architectures. Only the lines appropriate for the system architecture must be configured. -a always,exit -F arch=b32 -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=-EPERM -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 The audit daemon must be restarted for the changes to take effect.

Generate Mitigation Statement:

Checks: C-98173r2_chk

Verify the operating system generates audit records when successful/unsuccessful attempts to use the "open_by_handle_at" syscall occur. Check the file system rules in "/etc/audit/audit.rules" with the following commands: Note: The output lines of the command are duplicated to cover both 32-bit and 64-bit architectures. Only the lines appropriate for the system architecture must be present. # grep -iw open_by_handle_at /etc/audit/audit.rules -a always,exit -F arch=b32 -S open_by_handle_at -F exit=-EPERM -F auid&gt;=1000 -F auid!=unset -k access -a always,exit -F arch=b32 -S open_by_handle_at -F exit=-EACCES -F auid&gt;=1000 -F auid!=unset -k access -a always,exit -F arch=b64 -S open_by_handle_at -F exit=-EPERM -F auid&gt;=1000 -F auid!=unset -k access -a always,exit -F arch=b64 -S open_by_handle_at -F exit=-EACCES -F auid&gt;=1000 -F auid!=unset -k access If there are no audit rules defined for the "open_by_handle_at" syscall, this is a finding. If the output does not produce a rule containing "-F exit=-EPERM", this is a finding. If the output does not produce a rule containing "-F exit=-EACCES", this is a finding.