View SCAP - Tri-Lab Operating System Stack (TOSS) 4 STIG SCAP Benchmark V2R1

b

TOSS must require authentication upon booting into emergency or rescue modes.

RMF Control: AC-3
Severity: Medium
CCI: CCI-000213
Version: TOSS-04-010030
Vuln IDs: V-252914
Rule IDs: SV-252914r958472_rule

To mitigate the risk of unauthorized access to sensitive information by entities that have been issued certificates by DoD-approved PKIs, all DoD systems (e.g., web servers and web portals) must be properly configured to incorporate access control methods that do not rely solely on the possession of a certificate for access. Successful authentication must not automatically give an entity access to an asset or security boundary. Authorization procedures and controls must be implemented to ensure each authenticated entity also has a validated and current authorization. Authorization is the process of determining whether an entity, once authenticated, is permitted to access a specific asset. Information systems use access control policies and enforcement mechanisms to implement this requirement. Access control policies include: identity-based policies, role-based policies, and attribute-based policies. Access enforcement mechanisms include: access control lists, access control matrices, and cryptography. These policies and mechanisms must be employed by the application to control access between users (or processes acting on behalf of users) and objects (e.g., devices, files, records, processes, programs, and domains) in the information system.

Fix: F-56317r824065_fix

Configure the system to require authentication upon booting into emergency or rescue mode by adding the following line to the "/usr/lib/systemd/system/rescue.service" file. ExecStart=-/usr/lib/systemd/systemd-sulogin-shell rescue

b

TOSS must not permit direct logons to the root account using remote access from outside of the system via SSH.

RMF Control
Severity: Medium
CCI: CCI-004045
Version: TOSS-04-010040
Vuln IDs: V-252915
Rule IDs: SV-252915r986573_rule

Even though the communications channel may be encrypted, an additional layer of security is gained by extending the policy of not logging on directly as root. In addition, logging on with a user-specific account provides individual accountability of actions performed on the system.

Fix: F-56318r824068_fix

Configure TOSS to stop users from logging on remotely from outside of the cluster as the "root" user via SSH. Edit the appropriate "/etc/ssh/sshd_config" file to uncomment or add the line for the "PermitRootLogin" keyword and set its value to "no": PermitRootLogin no The SSH daemon must be restarted for the changes to take effect. To restart the SSH daemon, run the following command: $ sudo systemctl restart sshd.service

b

The TOSS file system automounter must be disabled unless required.

RMF Control: IA-3
Severity: Medium
CCI: CCI-000778
Version: TOSS-04-010050
Vuln IDs: V-252916
Rule IDs: SV-252916r958498_rule

Automatically mounting file systems permits easy introduction of unknown devices, thereby facilitating malicious activity.

Fix: F-56319r824071_fix

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

b

The TOSS pam_unix.so module must be configured in the password-auth file to use a FIPS 140-2-approved cryptographic hashing algorithm for system authentication.

RMF Control: IA-7
Severity: Medium
CCI: CCI-000803
Version: TOSS-04-010060
Vuln IDs: V-252917
Rule IDs: SV-252917r971535_rule

Unapproved mechanisms that are used for authentication to the cryptographic module are not verified and therefore cannot be relied upon to provide confidentiality or integrity, and DoD data may be compromised. TOSS systems utilizing encryption are required to use FIPS-compliant mechanisms for authenticating to cryptographic modules. FIPS 140-2 is the current standard for validating that mechanisms used to access cryptographic modules utilize authentication that meets DoD requirements. This allows for Security Levels 1, 2, 3, or 4 for use on a general-purpose computing system.

Fix: F-56320r824074_fix

Configure TOSS to use a FIPS 140-2-approved cryptographic hashing algorithm for system authentication. Edit and/or modify the following line in the "/etc/pam.d/password-auth" file to include the sha512 option for pam_unix.so: password sufficient pam_unix.so sha512

b

The TOSS pam_unix.so module must be configured in the system-auth file to use a FIPS 140-2-approved cryptographic hashing algorithm for system authentication.

RMF Control: IA-7
Severity: Medium
CCI: CCI-000803
Version: TOSS-04-010070
Vuln IDs: V-252918
Rule IDs: SV-252918r971535_rule

Unapproved mechanisms that are used for authentication to the cryptographic module are not verified and therefore cannot be relied upon to provide confidentiality or integrity, and DoD data may be compromised. TOSS systems utilizing encryption are required to use FIPS-compliant mechanisms for authenticating to cryptographic modules. FIPS 140-2 is the current standard for validating that mechanisms used to access cryptographic modules utilize authentication that meets DoD requirements. This allows for Security Levels 1, 2, 3, or 4 for use on a general-purpose computing system.

Fix: F-56321r824077_fix

Configure TOSS to use a FIPS 140-2-approved cryptographic hashing algorithm for system authentication. Edit and/or modify the following line in the "/etc/pam.d/system-auth" file to include the sha512 option for pam_unix.so: password sufficient pam_unix.so sha512

b

The TOSS operating system must implement DoD-approved encryption in the OpenSSL package.

RMF Control: MA-4
Severity: Medium
CCI: CCI-000877
Version: TOSS-04-010080
Vuln IDs: V-252919
Rule IDs: SV-252919r958510_rule

Without cryptographic integrity protections, information can be altered by unauthorized users without detection. Remote access (e.g., RDP) is access to DoD nonpublic information systems by an authorized user (or an information system) communicating through an external, non-organization-controlled network. Remote access methods include, for example, dial-up, broadband, and wireless. Cryptographic mechanisms used for protecting the integrity of information include, for example, signed hash functions using asymmetric cryptography enabling distribution of the public key to verify the hash information while maintaining the confidentiality of the secret key used to generate the hash. TOSS incorporates system-wide crypto policies by default. The employed algorithms can be viewed in the /etc/crypto-policies/back-ends/openssl.config file. Satisfies: SRG-OS-000125-GPOS-00065, SRG-OS-000250-GPOS-00093

Fix: F-56322r824080_fix

Configure the TOSS OpenSSL library to use only DoD-approved TLS encryption by editing the following lines in the "/etc/crypto-policies/back-ends/opensslcnf.config" file: MinProtocol = TLSv1.2 DTLS.MinProtocol = DTLSv1.2 A reboot is required for the changes to take effect.

b

The TOSS operating system must be configured to use TCP syncookies.

RMF Control: SC-5
Severity: Medium
CCI: CCI-001095
Version: TOSS-04-010110
Vuln IDs: V-252922
Rule IDs: SV-252922r958528_rule

Denial of Service (DoS) is a condition when a resource is not available for legitimate users. When this occurs, the organization either cannot accomplish its mission or must operate at degraded capacity. Managing excess capacity ensures that sufficient capacity is available to counter flooding attacks. Employing increased capacity and service redundancy may reduce the susceptibility to some DoS attacks. Managing excess capacity may include, for example, establishing selected usage priorities, quotas, or partitioning.

Fix: F-56325r824089_fix

Configure The TOSS operating system to use TCP syncookies by running the following command: $ sudo sysctl -w net.ipv4.tcp_syncookies=1 If "1" is not the system's default value, add or update the following line in "/etc/sysctl.conf": net.ipv4.tcp_syncookies = 1

b

The TOSS SSH daemon must be configured to use only Message Authentication Codes (MACs) employing FIPS 140-2 validated cryptographic hash algorithms.

RMF Control: AC-17
Severity: Medium
CCI: CCI-001453
Version: TOSS-04-010160
Vuln IDs: V-252926
Rule IDs: SV-252926r991554_rule

Without cryptographic integrity protections, information can be altered by unauthorized users without detection. Remote access (e.g., RDP) is access to DoD nonpublic information systems by an authorized user (or an information system) communicating through an external, non-organization-controlled network. Remote access methods include, for example, dial-up, broadband, and wireless. Cryptographic mechanisms used for protecting the integrity of information include, for example, signed hash functions using asymmetric cryptography enabling distribution of the public key to verify the hash information while maintaining the confidentiality of the secret key used to generate the hash. TOSS incorporates system-wide crypto policies by default. The SSH configuration file has no effect on the ciphers, MACs, or algorithms unless specifically defined in the /etc/sysconfig/sshd file. The employed algorithms can be viewed in the /etc/crypto-policies/back-ends/openssh.config file. By specifying a hash algorithm list with the order of hashes being in a "strongest to weakest" orientation, the system will automatically attempt to use the strongest hash for securing SSH connections.

Fix: F-56329r824101_fix

Configure the TOSS SSH daemon to use only MACs employing FIPS 140-2-approved algorithms. Update the "/etc/crypto-policies/back-ends/openssh.config" and "/etc/crypto-policies/back-ends/opensshserver.config" files to include these MACs employing FIPS 140-2-approved algorithms: /etc/crypto-policies/back-ends/openssh.config:MACs hmac-sha2-512,hmac-sha2-256 /etc/crypto-policies/back-ends/opensshserver.config:-oMACs=hmac-sha2-512,hmac-sha2-256' /etc/crypto-policies/back-ends/opensshserver.config:-oMACs=hmac-sha2-512,hmac-sha2-256' A reboot is required for the changes to take effect.

b

The TOSS operating system must be configured to preserve log records from failure events.

RMF Control: SC-24
Severity: Medium
CCI: CCI-001665
Version: TOSS-04-010170
Vuln IDs: V-252927
Rule IDs: SV-252927r991562_rule

Failure to a known state can address safety or security in accordance with the mission/business needs of the organization. Failure to a known secure state helps prevent a loss of confidentiality, integrity, or availability in the event of a failure of the information system or a component of the system. Preserving operating system state information helps to facilitate operating system restart and return to the operational mode of the organization with least disruption to mission/business processes.

Fix: F-56330r824104_fix

Start and enable the rsyslog service with the following commands: $ sudo systemctl start rsyslog.service $ sudo systemctl enable rsyslog.service

c

TOSS must prevent the installation of patches, service packs, device drivers, or operating system components without verification they have been digitally signed using a certificate that is recognized and approved by the organization.

RMF Control
Severity: High
CCI: CCI-003992
Version: TOSS-04-010220
Vuln IDs: V-252930
Rule IDs: SV-252930r986577_rule

Changes to any software components can have significant effects on the overall security of the operating system. This requirement ensures the software has not been tampered with and that it has been provided by a trusted vendor. Accordingly, patches, service packs, device drivers, or operating system components must be signed with a certificate recognized and approved by the organization. Verifying the authenticity of the software prior to installation validates the integrity of the patch or upgrade received from a vendor. This ensures the software has not been tampered with and that it has been provided by a trusted vendor. Self-signed certificates are disallowed by this requirement. The operating system should not have to verify the software again. This requirement does not mandate DOD certificates for this purpose; however, the certificate used to verify the software must be from an approved Certification Authority (CA).

Fix: F-56333r824113_fix

Configure TOSS to prevent the installation of patches, service packs, device drivers, or operating system components without verification they have been digitally signed using a certificate that is recognized and approved by the organization by setting the following option in the "/etc/yum.repos.d/[your_repo_name].repo" file(s): gpgcheck=1

b

TOSS must require reauthentication when using the "sudo" command.

RMF Control
Severity: Medium
CCI: CCI-004895
Version: TOSS-04-010230
Vuln IDs: V-252931
Rule IDs: SV-252931r987879_rule

Without reauthentication, users may access resources or perform tasks for which they do not have authorization. When operating systems provide the capability to escalate a functional capability, it is critical the organization requires the user to reauthenticate when using the "sudo" command. If the value is set to an integer less than 0, the user's time stamp will not expire and the user will not have to reauthenticate for privileged actions until the user's session is terminated.

Fix: F-56334r986579_fix

Configure the "sudo" command to require reauthentication. Edit the /etc/sudoers file: $ sudo visudo Add or modify the following line: Defaults timestamp_timeout=0

b

TOSS must have the packages required for multifactor authentication installed.

RMF Control
Severity: Medium
CCI: CCI-004046
Version: TOSS-04-010240
Vuln IDs: V-252932
Rule IDs: SV-252932r986581_rule

Using an authentication device, such as a DOD Common Access Card (CAC) or token that is separate from the information system, ensures that even if the information system is compromised, credentials stored on the authentication device will not be affected. Multifactor solutions that require devices separate from information systems gaining access include, for example, hardware tokens providing time-based or challenge-response authenticators and smart cards such as the U.S. Government Personal Identity Verification (PIV) card and the DOD CAC. A privileged account is defined as an information system account with authorizations of a privileged user. Remote access is access to DOD nonpublic information systems by an authorized user (or an information system) communicating through an external, non-organization-controlled network. Remote access methods include, for example, dial-up, broadband, and wireless. This requirement only applies to components where this is specific to the function of the device or has the concept of an organizational user (e.g., VPN, proxy capability). This does not apply to authentication for the purpose of configuring the device itself (management).

Fix: F-56335r824119_fix

Configure TOSS to implement multifactor authentication by installing the required package with the following command: $ sudo yum install openssl-pkcs11

b

TOSS must prohibit the use of cached authentications after one day.

RMF Control: IA-5
Severity: Medium
CCI: CCI-002007
Version: TOSS-04-010250
Vuln IDs: V-252933
Rule IDs: SV-252933r958828_rule

If cached authentication information is out of date, the validity of the authentication information may be questionable. TOSS includes multiple options for configuring authentication, but this requirement will be focus on the System Security Services Daemon (SSSD). By default, sssd does not cache credentials.

Fix: F-56336r824122_fix

Configure the SSSD to prohibit the use of cached authentications after one day. Add or change the following line in "/etc/sssd/sssd.conf" just below the line "[pam]." offline_credentials_expiration = 1

b

All TOSS networked systems must have and implement SSH to protect the confidentiality and integrity of transmitted and received information, as well as information during preparation for transmission.

RMF Control: SC-8
Severity: Medium
CCI: CCI-002418
Version: TOSS-04-010280
Vuln IDs: V-252934
Rule IDs: SV-252934r958908_rule

Without protection of the transmitted information, confidentiality and integrity may be compromised because unprotected communications can be intercepted and either read or altered. This requirement applies to both internal and external networks and all types of information system components from which information can be transmitted (e.g., servers, mobile devices, notebook computers, printers, copiers, scanners, and facsimile machines). Communication paths outside the physical protection of a controlled boundary are exposed to the possibility of interception and modification. Protecting the confidentiality and integrity of organizational information can be accomplished by physical means (e.g., employing physical distribution systems) or by logical means (e.g., employing cryptographic techniques). If physical means of protection are employed, then logical means (cryptography) do not have to be employed, and vice versa. Satisfies: SRG-OS-000423-GPOS-00187, SRG-OS-000424-GPOS-00188, SRG-OS-000425-GPOS-00189, SRG-OS-000426-GPOS-00190

Fix: F-56337r824125_fix

Install the SSH server package onto the host with the following command: $ sudo yum install openssh-server Configure the SSH service to automatically start now and after each reboot with the following command: $ sudo systemctl enable --now sshd.service

c

The root account must be the only account having unrestricted access to the TOSS system.

RMF Control: CM-6
Severity: High
CCI: CCI-000366
Version: TOSS-04-010350
Vuln IDs: V-252937
Rule IDs: SV-252937r991589_rule

If an account other than root also has a User Identifier (UID) of "0", it has root authority, giving that account unrestricted access to the entire operating system. Multiple accounts with a UID of "0" afford an opportunity for potential intruders to guess a password for a privileged account.

Fix: F-56340r824134_fix

Change the UID of any account on the system, other than root, that has a UID of "0." If the account is associated with system commands or applications, the UID should be changed to one greater than "0" but less than "1000." Otherwise, assign a UID of greater than "1000" that has not already been assigned.

c

The systemd Ctrl-Alt-Delete burst key sequence in TOSS must be disabled.

RMF Control: CM-6
Severity: High
CCI: CCI-000366
Version: TOSS-04-010360
Vuln IDs: V-252938
Rule IDs: SV-252938r991589_rule

A locally logged-on user who presses Ctrl-Alt-Delete when at the console can reboot the system. If accidentally pressed, as could happen in the case of a mixed OS environment, this can create the risk of short-term loss of availability of systems due to unintentional reboot. In a graphical user environment, risk of unintentional reboot from the Ctrl-Alt-Delete sequence is reduced because the user will be prompted before any action is taken.

Fix: F-56341r824137_fix

Configure the system to disable the CtrlAltDelBurstAction by added or modifying the following line in the "/etc/systemd/system.conf" configuration file: CtrlAltDelBurstAction=none Reload the daemon for this change to take effect. $ sudo systemctl daemon-reload

b

There must be no ".shosts" files on The TOSS operating system.

RMF Control: CM-6
Severity: Medium
CCI: CCI-000366
Version: TOSS-04-010370
Vuln IDs: V-252939
Rule IDs: SV-252939r991589_rule

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

Fix: F-56342r824140_fix

Remove any found ."shosts" files from the system. $ sudo rm /[path]/[to]/[file]/.shosts

c

TOSS must not allow blank or null passwords in the system-auth file.

RMF Control: CM-6
Severity: High
CCI: CCI-000366
Version: TOSS-04-010380
Vuln IDs: V-252940
Rule IDs: SV-252940r991589_rule

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

Fix: F-56343r824143_fix

Remove any instances of the "nullok" option in the "/etc/pam.d/system-auth" file to prevent logons with empty passwords. Note: Manual changes to the listed file may be overwritten by the "authselect" program.

b

The TOSS SSH daemon must not allow authentication using known host's authentication.

RMF Control: CM-6
Severity: Medium
CCI: CCI-000366
Version: TOSS-04-010400
Vuln IDs: V-252942
Rule IDs: SV-252942r991589_rule

Configuring this setting for the SSH daemon provides additional assurance that remote logon via SSH will require a password, even in the event of misconfiguration elsewhere.

Fix: F-56345r824149_fix

Configure the SSH daemon to not allow authentication using known host's authentication. Add the following line in "/etc/ssh/sshd_config" or uncomment the line and set the value to "yes": IgnoreUserKnownHosts yes The SSH daemon must be restarted for the changes to take effect. To restart the SSH daemon, run the following command: $ sudo systemctl restart sshd.service

b

The TOSS SSH daemon must not allow compression or must only allow compression after successful authentication.

RMF Control: CM-6
Severity: Medium
CCI: CCI-000366
Version: TOSS-04-010410
Vuln IDs: V-252943
Rule IDs: SV-252943r991589_rule

If compression is allowed in an SSH connection prior to authentication, vulnerabilities in the compression software could result in compromise of the system from an unauthenticated connection, potentially with root privileges.

Fix: F-56346r824152_fix

Uncomment the "Compression" keyword in "/etc/ssh/sshd_config" (this file may be named differently or be in a different location if using a version of SSH that is provided by a third-party vendor) on the system and set the value to "delayed" or "no": Compression no The SSH service must be restarted for changes to take effect.

b

The TOSS SSH daemon must not allow Kerberos authentication, except to fulfill documented and validated mission requirements.

RMF Control: CM-6
Severity: Medium
CCI: CCI-000366
Version: TOSS-04-010420
Vuln IDs: V-252944
Rule IDs: SV-252944r991589_rule

Configuring these settings for the SSH daemon provides additional assurance that remote logon via SSH will not use unused methods of authentication, even in the event of misconfiguration elsewhere.

Fix: F-56347r824155_fix

Configure the SSH daemon to not allow Kerberos authentication. Add the following line in "/etc/ssh/sshd_config" or uncomment the line and set the value to "no": KerberosAuthentication no The SSH daemon must be restarted for the changes to take effect. To restart the SSH daemon, run the following command: $ sudo systemctl restart sshd.service

c

TOSS must not allow an unattended or automatic logon to the system.

RMF Control: CM-6
Severity: High
CCI: CCI-000366
Version: TOSS-04-010430
Vuln IDs: V-252945
Rule IDs: SV-252945r991591_rule

Failure to restrict system access to authenticated users negatively impacts operating system security.

Fix: F-56348r824158_fix

Configure TOSS to not allow an unattended or automatic logon to the system via a graphical user interface. Add or edit the line for the "AutomaticLoginEnable" parameter in the [daemon] section of the "/etc/gdm/custom.conf" file to "false": [daemon] AutomaticLoginEnable=false

b

TOSS must enforce the limit of five consecutive invalid logon attempts by a user during a 15-minute time period.

RMF Control: AC-7
Severity: Medium
CCI: CCI-000044
Version: TOSS-04-020000
Vuln IDs: V-252946
Rule IDs: SV-252946r958388_rule

By limiting the number of failed logon attempts, the risk of unauthorized system access via user password guessing, otherwise known as brute-force attacks, is reduced. Limits are imposed by locking the account.

Fix: F-56349r824161_fix

Configure the operating system to lock an account when three unsuccessful logon attempts occur in 15 minutes. Add/Modify the "/etc/security/faillock.conf" file to match the following lines: deny = 3 fail_interval = 900

a

TOSS must limit the number of concurrent sessions to 256 for all accounts and/or account types.

RMF Control: AC-10
Severity: Low
CCI: CCI-000054
Version: TOSS-04-020010
Vuln IDs: V-252947
Rule IDs: SV-252947r958398_rule

Operating system management includes the ability to control the number of users and user sessions that utilize an operating system. Limiting the number of allowed users and sessions per user is helpful in reducing the risks related to Denial of Service (DoS) attacks. TOSS as an HPC operating system, is capable of supporting a large number of sessions, as well as tools which presume a larger number of concurrent sessions will be allowed. This requirement addresses concurrent sessions for information system accounts and does not address concurrent sessions by single users via multiple system accounts. The maximum number of concurrent sessions should be defined based upon mission needs and the operational environment for each system.

Fix: F-56350r824164_fix

Configure TOSS to limit the number of concurrent sessions to at most 256 for all accounts and/or account types. Add the following line to the top of the /etc/security/limits.conf or in a ."conf" file defined in /etc/security/limits.d/: * hard maxlogins 256

b

TOSS must disable account identifiers (individuals, groups, roles, and devices) after 35 days of inactivity.

RMF Control
Severity: Medium
CCI: CCI-003627
Version: TOSS-04-020120
Vuln IDs: V-252953
Rule IDs: SV-252953r986584_rule

Inactive identifiers pose a risk to systems and applications because attackers may exploit an inactive identifier and potentially obtain undetected access to the system. Owners of inactive accounts will not notice if unauthorized access to their user account has been obtained. Operating systems need to track periods of inactivity and disable application identifiers after 35 days of inactivity.

Fix: F-56356r986583_fix

Configure TOSS to disable account identifiers after 35 days of inactivity after the password expiration. Run the following command to change the configuration for useradd: $ sudo useradd -D -f 35 DOD recommendation is 35 days, but a lower value is acceptable. The value "-1" will disable this feature, and "0" will disable the account immediately after the password expires.

b

TOSS must reveal error messages only to authorized users.

RMF Control: SI-11
Severity: Medium
CCI: CCI-001314
Version: TOSS-04-020150
Vuln IDs: V-252955
Rule IDs: SV-252955r958566_rule

Only authorized personnel should be aware of errors and the details of the errors. Error messages are an indicator of an organization's operational state or can identify the operating system or platform. Additionally, Personally Identifiable Information (PII) and operational information must not be revealed through error messages to unauthorized personnel or their designated representatives. The structure and content of error messages must be carefully considered by the organization and development team. The extent to which the information system is able to identify and handle error conditions is guided by organizational policy and operational requirements.

Fix: F-56358r824188_fix

Change the permissions of the file "/var/log/messages" to "0640" and the ownership of the file to "root" by running the following commands: $ sudo chmod 0640 /var/log/messages $ sudo chown root /var/log/messages Change the permissions of the directory "/var/log/" to "0755" and the ownership of the directory to "root" by running the following commands: $ sudo chmod 0755 /var/log/ $ sudo chown root /var/log/

b

TOSS must automatically lock an account until the locked account is released by an administrator when three unsuccessful logon attempts in 15 minutes occur.

RMF Control: AC-7
Severity: Medium
CCI: CCI-002238
Version: TOSS-04-020170
Vuln IDs: V-252957
Rule IDs: SV-252957r958736_rule

By limiting the number of failed logon attempts, the risk of unauthorized system access via user password guessing, otherwise known as brute-forcing, is reduced. Limits are imposed by locking the account. Due to the scale of HPC systems and the number of users in question, it is impractical to require an administrator to unlock the user's account manually. Strong controls around automatic lock out, and typical (though not universal) use of strong MFA to enter an HPC system mitigate the concerns of a brute force attack being successful.

Fix: F-56360r824194_fix

Configure the operating system to lock an account until released by an administrator when three unsuccessful logon attempts occur in 15 minutes. Add and/or modify the appropriate sections of the "/etc/pam.d/system-auth" and "/etc/pam.d/password-auth" files to match the following lines: auth required pam_faillock.so preauth auth required pam_faillock.so authfail account required pam_faillock.so Add and/or modify the "/etc/security/faillock.conf" file to match the following line: unlock_time = 0

b

TOSS must require users to reauthenticate for privilege escalation.

RMF Control
Severity: Medium
CCI: CCI-004895
Version: TOSS-04-020180
Vuln IDs: V-252958
Rule IDs: SV-252958r987879_rule

Without reauthentication, users may access resources or perform tasks for which they do not have authorization. When operating systems provide the capability to escalate a functional capability, it is critical the user reauthenticate.

Fix: F-56361r824197_fix

Remove any occurrence of "!authenticate" found in "/etc/sudoers" file or files in the "/etc/sudoers.d" directory.

b

TOSS must require users to provide a password for privilege escalation.

RMF Control
Severity: Medium
CCI: CCI-004895
Version: TOSS-04-020190
Vuln IDs: V-252959
Rule IDs: SV-252959r987879_rule

Without re-authentication, users may access resources or perform tasks for which they do not have authorization. When operating systems provide the capability to escalate a functional capability, it is critical the user reauthenticate.

Fix: F-56362r824200_fix

Remove any occurrence of "NOPASSWD" found in "/etc/sudoers" file or files in the "/etc/sudoers.d" directory.

b

All TOSS local interactive user accounts must be assigned a home directory upon creation.

RMF Control: CM-6
Severity: Medium
CCI: CCI-000366
Version: TOSS-04-020200
Vuln IDs: V-252960
Rule IDs: SV-252960r991589_rule

If local interactive users are not assigned a valid home directory, there is no place for the storage and control of files they should own.

Fix: F-56363r824203_fix

Configure TOSS 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

c

The x86 Ctrl-Alt-Delete key sequence in TOSS must be disabled if a graphical user interface is installed.

RMF Control: CM-6
Severity: High
CCI: CCI-000366
Version: TOSS-04-020240
Vuln IDs: V-252963
Rule IDs: SV-252963r991589_rule

A locally logged-on user, who presses Ctrl-Alt-Delete when at the console, can reboot the system. If accidentally pressed, as could happen in the case of a mixed OS environment, this can create the risk of short-term loss of availability of systems due to unintentional reboot. In a graphical user environment, risk of unintentional reboot from the Ctrl-Alt-Delete sequence is reduced because the user will be prompted before any action is taken.

Fix: F-56366r824212_fix

Configure the system to disable the Ctrl-Alt-Delete sequence when using a graphical user interface by creating or editing the /etc/dconf/db/local.d/00-disable-CAD file. Add the setting to disable the Ctrl-Alt-Delete sequence for a graphical user interface: [org/gnome/settings-daemon/plugins/media-keys] logout='' Note: The value above is set to two single quotations. Then update the dconf settings: $ sudo dconf update

b

TOSS must display the date and time of the last successful account logon upon an SSH logon.

RMF Control: CM-6
Severity: Medium
CCI: CCI-000366
Version: TOSS-04-020260
Vuln IDs: V-252965
Rule IDs: SV-252965r991589_rule

Providing users with feedback on when account accesses via SSH last occurred facilitates user recognition and reporting of unauthorized account use.

Fix: F-56368r824218_fix

Configure SSH to provide users with feedback on when account accesses last occurred by setting the required configuration options in "/etc/pam.d/sshd" or in the "sshd_config" file used by the system ("/etc/ssh/sshd_config" will be used in the example) (this file may be named differently or be in a different location if using a version of SSH that is provided by a third-party vendor). Modify the "PrintLastLog" line in "/etc/ssh/sshd_config" to match the following: PrintLastLog yes The SSH service must be restarted for changes to "sshd_config" to take effect.

c

TOSS must not allow accounts configured with blank or null passwords.

RMF Control: CM-6
Severity: High
CCI: CCI-000366
Version: TOSS-04-020270
Vuln IDs: V-252966
Rule IDs: SV-252966r991589_rule

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

Fix: F-56369r824221_fix

Edit the following line in "etc/ssh/sshd_config" to prevent logons with empty passwords. PermitEmptyPasswords no The SSH daemon must be restarted for the changes to take effect. To restart the SSH daemon, run the following command: $ sudo systemctl restart sshd.service

b

TOSS must define default permissions for all authenticated users in such a way that the user can only read and modify their own files.

RMF Control: CM-6
Severity: Medium
CCI: CCI-000366
Version: TOSS-04-020290
Vuln IDs: V-252968
Rule IDs: SV-252968r991590_rule

Setting the most restrictive default permissions ensures that when new accounts are created, they do not have unnecessary access.

Fix: F-56371r824227_fix

Configure TOSS 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

b

TOSS must generate audit records for all account creations, modifications, disabling, and termination events that affect /etc/shadow.

RMF Control: AC-2
Severity: Medium
CCI: CCI-000018
Version: TOSS-04-030000
Vuln IDs: V-252972
Rule IDs: SV-252972r958368_rule

Once an attacker establishes access to a system, the attacker often attempts to create a persistent method of reestablishing access. One way to accomplish this is for the attacker to modify an existing account. Auditing account modification actions provides logging that can be used for forensic purposes. To address access requirements, many operating systems can be integrated with enterprise-level authentication/access/auditing mechanisms that meet or exceed access control policy requirements. Satisfies: SRG-OS-000004-GPOS-00004, SRG-OS-000239-GPOS-00089, SRG-OS-000240-GPOS-00090, SRG-OS-000241-GPOS-00091, SRG-OS-000303-GPOS-00120, SRG-OS-000466-GPOS-00210, SRG-OS-000476-GPOS-00221

Fix: F-56375r824239_fix

Configure TOSS to generate audit records for all account creations, modifications, disabling, and termination events that affect "/etc/shadow." Add or update the following file system rule to "/etc/audit/rules.d/audit.rules": -w /etc/shadow -p wa -k identity The audit daemon must be restarted for the changes to take effect. Note: The "-k" allows for specifying an arbitrary identifier. The string following "-k" does not need to match the example output above.

b

TOSS audit records must contain information to establish what type of events occurred, when the events occurred, the source of events, where events occurred, and the outcome of events.

RMF Control: AU-3
Severity: Medium
CCI: CCI-000130
Version: TOSS-04-030010
Vuln IDs: V-252973
Rule IDs: SV-252973r986588_rule

Without establishing what type of events occurred, when events occurred, the source of events, where events occurred, and the outcome of events, it would be difficult to establish, correlate, and investigate the events leading up to an outage or attack. Audit record content that may be necessary to satisfy this requirement includes, for example, time stamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, filenames involved, and access control or flow control rules invoked. Associating event types with detected events in TOSS audit logs provides a means of investigating an attack, recognizing resource utilization or capacity thresholds, or identifying an improperly configured TOSS system. Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000038-GPOS-00016, SRG-OS-000039-GPOS-00017, SRG-OS-000040-GPOS-00018, SRG-OS-000041-GPOS-00019, SRG-OS-000042-GPOS-00021, SRG-OS-000047-GPOS-00023, SRG-OS-000051-GPOS-00024, SRG-OS-000064-GPOS-00033, SRG-OS-000241-GPOS-00091, SRG-OS-000254-GPOS-00095, SRG-OS-000327-GPOS-00127, SRG-OS-000342-GPOS-00133, SRG-OS-000348-GPOS-00136, SRG-OS-000349-GPOS-00137, SRG-OS-000350-GPOS-00138, SRG-OS-000351-GPOS-00139, SRG-OS-000353-GPOS-00141, SRG-OS-000354-GPOS-00142, SRG-OS-000365-GPOS-00152, SRG-OS-000474-GPOS-00219, SRG-OS-000479-GPOS-00224

Fix: F-56376r824242_fix

Configure the audit service to produce audit records containing the information needed to establish when (date and time) an event occurred. Install the audit service (if the audit service is not already installed) with the following command: $ sudo yum install audit Enable the audit service with the following command: $ sudo systemctl enable auditd.service Start the audit service with the following command: $ sudo systemctl start auditd.service

b

TOSS must generate audit records containing the full-text recording of privileged commands.

RMF Control: AU-3
Severity: Medium
CCI: CCI-000135
Version: TOSS-04-030060
Vuln IDs: V-252974
Rule IDs: SV-252974r958422_rule

Reconstruction of harmful events or forensic analysis is not possible if audit records do not contain enough information. At a minimum, the organization must audit the full-text recording of privileged commands. The organization must maintain audit trails in sufficient detail to reconstruct events to determine the cause and impact of compromise.

Fix: F-56377r824245_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "sudo" command by adding or updating the following rule in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F path=/usr/bin/sudo -F perm=x -F auid>=1000 -F auid!=unset -k priv_cmd The audit daemon must be restarted for the changes to take effect.

b

TOSS must alert the ISSO and SA (at a minimum) in the event of an audit processing failure.

RMF Control: AU-5
Severity: Medium
CCI: CCI-000139
Version: TOSS-04-030080
Vuln IDs: V-252975
Rule IDs: SV-252975r958424_rule

It is critical for the appropriate personnel to be aware if a system is at risk of failing to process audit logs as required. Without this notification, the security personnel may be unaware of an impending failure of the audit capability, and system operation may be adversely affected. Audit processing failures include software/hardware errors, failures in the audit capturing mechanisms, and audit storage capacity being reached or exceeded. This requirement applies to each audit data storage repository (i.e., distinct information system component where audit records are stored), the centralized audit storage capacity of organizations (i.e., all audit data storage repositories combined), or both.

Fix: F-56378r824248_fix

Configure "auditd" service to notify the SA and ISSO in the event of an audit processing failure. Edit the following line in "/etc/audit/auditd.conf" to ensure that administrators are notified via email for those situations: action_mail_acct = root

b

TOSS must take appropriate action when an audit processing failure occurs.

RMF Control: AU-5
Severity: Medium
CCI: CCI-000140
Version: TOSS-04-030090
Vuln IDs: V-252976
Rule IDs: SV-252976r958426_rule

It is critical that when the operating system is at risk of failing to process audit logs as required, it takes action to mitigate the failure. Audit processing failures include: software/hardware errors; failures in the audit capturing mechanisms; and audit storage capacity being reached or exceeded. Responses to audit failure depend upon the nature of the failure mode. When availability is an overriding concern, other approved actions in response to an audit failure are as follows: 1) If the failure was caused by the lack of audit record storage capacity, the operating system must continue generating audit records if possible (automatically restarting the audit service if necessary), overwriting the oldest audit records in a first-in-first-out manner. 2) If audit records are sent to a centralized collection server and communication with this server is lost or the server fails, the operating system must queue audit records locally until communication is restored or until the audit records are retrieved manually. Upon restoration of the connection to the centralized collection server, action should be taken to synchronize the local audit data with the collection server.

Fix: F-56379r824251_fix

Configure TOSS to shut down by default upon audit failure (unless availability is an overriding concern). Add or update the following line (depending on configuration "disk_error_action" can be set to "SYSLOG" or "SINGLE" depending on configuration) in "/etc/audit/auditd.conf" file: disk_error_action = HALT 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 by setting the "disk_error_action" to "SYSLOG."

b

TOSS audit logs must have a mode of 0600 or less permissive to prevent unauthorized read access.

RMF Control: AU-9
Severity: Medium
CCI: CCI-000162
Version: TOSS-04-030120
Vuln IDs: V-252977
Rule IDs: SV-252977r958434_rule

Unauthorized disclosure of audit records can reveal system and configuration data to attackers, thus compromising its confidentiality. Audit information includes all information (e.g., audit records, audit settings, audit reports) needed to successfully audit operating system activity. Satisfies: SRG-OS-000057-GPOS-00027, SRG-OS-000058-GPOS-00028, SRG-OS-000059-GPOS-00029

Fix: F-56380r824254_fix

Configure the audit log to be protected from unauthorized read access by setting the correct permissive mode with the following command: $ sudo chmod 0600 [audit_log_file] Replace "[audit_log_file]" to the correct audit log path, by default this location is "/var/log/audit/audit.log."

b

TOSS audit log directory must have a mode of 0700 or less permissive to prevent unauthorized read access.

RMF Control: AU-9
Severity: Medium
CCI: CCI-000162
Version: TOSS-04-030130
Vuln IDs: V-252978
Rule IDs: SV-252978r958434_rule

Unauthorized disclosure of audit records can reveal system and configuration data to attackers, thus compromising its confidentiality. Audit information includes all information (e.g., audit records, audit settings, audit reports) needed to successfully audit operating system activity. Satisfies: SRG-OS-000057-GPOS-00027, SRG-OS-000058-GPOS-00028, SRG-OS-000059-GPOS-00029

Fix: F-56381r824257_fix

Configure the audit log directory to be protected from unauthorized read access by setting the correct permissive mode with the following command: $ sudo chmod 0700 [audit_log_directory] Replace "[audit_log_directory]" to the correct audit log directory path, by default this location is "/var/log/audit."

b

TOSS audit logs must be owned by user root to prevent unauthorized read access.

RMF Control: AU-9
Severity: Medium
CCI: CCI-000162
Version: TOSS-04-030140
Vuln IDs: V-252979
Rule IDs: SV-252979r958434_rule

Unauthorized disclosure of audit records can reveal system and configuration data to attackers, thus compromising its confidentiality. Audit information includes all information (e.g., audit records, audit settings, audit reports) needed to successfully audit operating system activity. Satisfies: SRG-OS-000057-GPOS-00027, SRG-OS-000058-GPOS-00028, SRG-OS-000059-GPOS-00029

Fix: F-56382r824260_fix

Configure the audit log and audit log directory to be protected from unauthorized read access, by setting the correct owner as "root" with the following command: $ sudo chown root [audit_log_file] Replace "[audit_log_file]" to the correct audit log path, by default this location is "/var/log/audit/audit.log." Configure the audit log to be owned by root by configuring the log group in the /etc/audit/auditd.conf file: log_group = root

b

TOSS audit logs must be owned by group root to prevent unauthorized read access.

RMF Control: AU-9
Severity: Medium
CCI: CCI-000162
Version: TOSS-04-030150
Vuln IDs: V-252980
Rule IDs: SV-252980r958434_rule

Unauthorized disclosure of audit records can reveal system and configuration data to attackers, thus compromising its confidentiality. Audit information includes all information (e.g., audit records, audit settings, audit reports) needed to successfully audit operating system activity. Satisfies: SRG-OS-000057-GPOS-00027, SRG-OS-000058-GPOS-00028, SRG-OS-000059-GPOS-00029

Fix: F-56383r824263_fix

Configure the audit log and audit log directory to be protected from unauthorized read access, by setting the correct owner as "root" with the following command: $ sudo chgrp root [audit_log_file] Replace "[audit_log_file]" to the correct audit log path, by default this location is "/var/log/audit/audit.log." Configure the audit log to be owned by root by configuring the log group in the /etc/audit/auditd.conf file: log_group = root

b

TOSS audit log directory must be owned by user root to prevent unauthorized read access.

RMF Control: AU-9
Severity: Medium
CCI: CCI-000162
Version: TOSS-04-030160
Vuln IDs: V-252981
Rule IDs: SV-252981r958434_rule

Unauthorized disclosure of audit records can reveal system and configuration data to attackers, thus compromising its confidentiality. Audit information includes all information (e.g., audit records, audit settings, audit reports) needed to successfully audit operating system activity. Satisfies: SRG-OS-000057-GPOS-00027, SRG-OS-000058-GPOS-00028, SRG-OS-000059-GPOS-00029

Fix: F-56384r824266_fix

Configure the audit log directory to be protected from unauthorized read access, by setting the correct owner as "root" with the following command: $ sudo chown root [audit_log_directory] Replace "[audit_log_directory]" to the correct audit log directory path, by default this location is "/var/log/audit/."

b

TOSS audit log directory must be owned by group root to prevent unauthorized read access.

RMF Control: AU-9
Severity: Medium
CCI: CCI-000162
Version: TOSS-04-030170
Vuln IDs: V-252982
Rule IDs: SV-252982r958434_rule

Unauthorized disclosure of audit records can reveal system and configuration data to attackers, thus compromising its confidentiality. Audit information includes all information (e.g., audit records, audit settings, audit reports) needed to successfully audit operating system activity. Satisfies: SRG-OS-000057-GPOS-00027, SRG-OS-000058-GPOS-00028, SRG-OS-000059-GPOS-00029

Fix: F-56385r824269_fix

Configure the audit log directory to be protected from unauthorized read access, by setting the correct group as "root" with the following command: $ sudo chgrp root [audit_log_directory] Replace "[audit_log_directory]" to the correct audit log directory path, by default this location is "/var/log/audit/."

b

The TOSS audit system must protect auditing rules from unauthorized change.

RMF Control: AU-9
Severity: Medium
CCI: CCI-000162
Version: TOSS-04-030180
Vuln IDs: V-252983
Rule IDs: SV-252983r958434_rule

Unauthorized disclosure of audit records can reveal system and configuration data to attackers, thus compromising its confidentiality. Audit information includes all information (e.g., audit records, audit settings, audit reports) needed to successfully audit TOSS system activity. In immutable mode, unauthorized users cannot execute changes to the audit system to potentially hide malicious activity and then put the audit rules back. A system reboot would be noticeable and a system administrator could then investigate the unauthorized changes. Satisfies: SRG-OS-000057-GPOS-00027, SRG-OS-000058-GPOS-00028, SRG-OS-000059-GPOS-00029

Fix: F-56386r824272_fix

Configure the audit system to set the audit rules to be immutable by adding the following line to the end of "/etc/audit/rules.d/audit.rules": -e 2 Note: Once set, the system must be rebooted for auditing to be changed. It is recommended to add this option as the last step in securing the system.

b

The TOSS audit system must protect logon UIDs from unauthorized change.

RMF Control: AU-9
Severity: Medium
CCI: CCI-000162
Version: TOSS-04-030190
Vuln IDs: V-252984
Rule IDs: SV-252984r958434_rule

Unauthorized disclosure of audit records can reveal system and configuration data to attackers, thus compromising its confidentiality. Audit information includes all information (e.g., audit records, audit settings, audit reports) needed to successfully audit TOSS system activity. In immutable mode, unauthorized users cannot execute changes to the audit system to potentially hide malicious activity and then put the audit rules back. A system reboot would be noticeable and a system administrator could then investigate the unauthorized changes. Satisfies: SRG-OS-000057-GPOS-00027, SRG-OS-000058-GPOS-00028, SRG-OS-000059-GPOS-00029

Fix: F-56387r824275_fix

Configure the audit system to set the logon UIDs to be immutable by adding the following line to "/etc/audit/rules.d/audit.rules": --loginuid-immutable

b

Successful/unsuccessful uses of the "chage" command in TOSS must generate an audit record.

RMF Control: AU-3
Severity: Medium
CCI: CCI-000130
Version: TOSS-04-030310
Vuln IDs: V-252985
Rule IDs: SV-252985r958412_rule

Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). The "chage" command is used to change or view user password expiry information. When a user logs on, the AUID is set to the UID of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to "-1." The AUID representation is an unsigned 32-bit integer, which equals "4294967295." The audit system interprets "-1", "4294967295", and "unset" in the same way. Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000468-GPOS-00212, SRG-OS-000471-GPOS-00215

Fix: F-56388r824278_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "chage" command by adding or updating the following rule in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F path=/usr/bin/chage -F perm=x -F auid>=1000 -F auid!=unset -k privileged-chage The audit daemon must be restarted for the changes to take effect.

b

Successful/unsuccessful uses of the "chcon" command in TOSS must generate an audit record.

RMF Control: AU-3
Severity: Medium
CCI: CCI-000130
Version: TOSS-04-030320
Vuln IDs: V-252986
Rule IDs: SV-252986r958412_rule

Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). The "chcon" command is used to change file SELinux security context. When a user logs on, the AUID is set to the UID of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to "-1." The AUID representation is an unsigned 32-bit integer, which equals "4294967295." The audit system interprets "-1", "4294967295", and "unset" in the same way. Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000468-GPOS-00212, SRG-OS-000471-GPOS-00215

Fix: F-56389r824281_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "chcon" command by adding or updating the following rule in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F path=/usr/bin/chcon -F perm=x -F auid>=1000 -F auid!=unset -k perm_mod The audit daemon must be restarted for the changes to take effect.

b

Successful/unsuccessful uses of the ssh-agent in TOSS must generate an audit record.

RMF Control: AU-3
Severity: Medium
CCI: CCI-000130
Version: TOSS-04-030330
Vuln IDs: V-252987
Rule IDs: SV-252987r958412_rule

Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). The "ssh-agent" is a program to hold private keys used for public key authentication. When a user logs on, the AUID is set to the UID of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to "-1." The AUID representation is an unsigned 32-bit integer, which equals "4294967295." The audit system interprets "-1", "4294967295", and "unset" in the same way. Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000468-GPOS-00212, SRG-OS-000471-GPOS-00215

Fix: F-56390r824284_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "ssh-agent" command by adding or updating the following rule in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F path=/usr/bin/ssh-agent -F perm=x -F auid>=1000 -F auid!=unset -k privileged-ssh The audit daemon must be restarted for the changes to take effect.

b

Successful/unsuccessful uses of the "passwd" command in TOSS must generate an audit record.

RMF Control: AU-3
Severity: Medium
CCI: CCI-000130
Version: TOSS-04-030340
Vuln IDs: V-252988
Rule IDs: SV-252988r958412_rule

Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). The "passwd" command is used to change passwords for user accounts. When a user logs on, the AUID is set to the UID of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to "-1." The AUID representation is an unsigned 32-bit integer, which equals "4294967295." The audit system interprets "-1", "4294967295", and "unset" in the same way. Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000468-GPOS-00212, SRG-OS-000471-GPOS-00215

Fix: F-56391r824287_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "passwd" command by adding or updating the following rule in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F path=/usr/bin/passwd -F perm=x -F auid>=1000 -F auid!=unset -k privileged-passwd The audit daemon must be restarted for the changes to take effect.

b

Successful/unsuccessful uses of postdrop in TOSS must generate an audit record.

RMF Control: AU-3
Severity: Medium
CCI: CCI-000130
Version: TOSS-04-030350
Vuln IDs: V-252989
Rule IDs: SV-252989r958412_rule

Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). The "postdrop" command creates a file in the maildrop directory and copies its standard input to the file. When a user logs on, the AUID is set to the UID of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to "-1." The AUID representation is an unsigned 32-bit integer, which equals "4294967295." The audit system interprets "-1", "4294967295", and "unset" in the same way. Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000468-GPOS-00212, SRG-OS-000471-GPOS-00215

Fix: F-56392r824290_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "postdrop" command by adding or updating the following rule in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F path=/usr/sbin/postdrop -F perm=x -F auid>=1000 -F auid!=unset -k privileged-unix-update The audit daemon must be restarted for the changes to take effect.

b

Successful/unsuccessful uses of postqueue in TOSS must generate an audit record.

RMF Control: AU-3
Severity: Medium
CCI: CCI-000130
Version: TOSS-04-030360
Vuln IDs: V-252990
Rule IDs: SV-252990r958412_rule

Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). The "postqueue" command implements the Postfix user interface for queue management. When a user logs on, the AUID is set to the UID of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to "-1." The AUID representation is an unsigned 32-bit integer, which equals "4294967295." The audit system interprets "-1", "4294967295", and "unset" in the same way. Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000468-GPOS-00212, SRG-OS-000471-GPOS-00215

Fix: F-56393r824293_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "postqueue" command by adding or updating the following rule in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F path=/usr/sbin/postqueue -F perm=x -F auid>=1000 -F auid!=unset -k privileged-unix-update The audit daemon must be restarted for the changes to take effect.

b

Successful/unsuccessful uses of setsebool in TOSS must generate an audit record.

RMF Control: AU-3
Severity: Medium
CCI: CCI-000130
Version: TOSS-04-030370
Vuln IDs: V-252991
Rule IDs: SV-252991r958412_rule

Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). The "setsebool" command sets the current state of a particular SELinux boolean or a list of booleans to a given value. When a user logs on, the AUID is set to the UID of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to "-1." The AUID representation is an unsigned 32-bit integer, which equals "4294967295." The audit system interprets "-1", "4294967295", and "unset" in the same way. Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000468-GPOS-00212, SRG-OS-000471-GPOS-00215

Fix: F-56394r824296_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "setsebool" command by adding or updating the following rule in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F path=/usr/sbin/setsebool -F perm=x -F auid>=1000 -F auid!=unset -k privileged-unix-update The audit daemon must be restarted for the changes to take effect.

b

Successful/unsuccessful uses of the ssh-keysign in TOSS must generate an audit record.

RMF Control: AU-3
Severity: Medium
CCI: CCI-000130
Version: TOSS-04-030380
Vuln IDs: V-252992
Rule IDs: SV-252992r958412_rule

Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). The "ssh-keysign" program is an SSH helper program for host-based authentication. When a user logs on, the AUID is set to the UID of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to "-1." The AUID representation is an unsigned 32-bit integer, which equals "4294967295." The audit system interprets "-1", "4294967295", and "unset" in the same way. Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000468-GPOS-00212, SRG-OS-000471-GPOS-00215

Fix: F-56395r824299_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "ssh-keysign" command by adding or updating the following rule in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F path=/usr/libexec/openssh/ssh-keysign -F perm=x -F auid>=1000 -F auid!=unset -k privileged-ssh The audit daemon must be restarted for the changes to take effect.

b

Successful/unsuccessful uses of the "setfacl" command in RTOSS must generate an audit record.

RMF Control: AU-3
Severity: Medium
CCI: CCI-000130
Version: TOSS-04-030390
Vuln IDs: V-252993
Rule IDs: SV-252993r958412_rule

Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). The "setfacl" command is used to set file access control lists. When a user logs on, the AUID is set to the UID of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to "-1." The AUID representation is an unsigned 32-bit integer, which equals "4294967295." The audit system interprets "-1", "4294967295", and "unset" in the same way. Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000468-GPOS-00212, SRG-OS-000471-GPOS-00215

Fix: F-56396r824302_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "setfacl" command by adding or updating the following rule in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F path=/usr/bin/setfacl -F perm=x -F auid>=1000 -F auid!=unset -k perm_mod The audit daemon must be restarted for the changes to take effect.

b

Successful/unsuccessful uses of the "pam_timestamp_check" command in TOSS must generate an audit record.

RMF Control: AU-3
Severity: Medium
CCI: CCI-000130
Version: TOSS-04-030400
Vuln IDs: V-252994
Rule IDs: SV-252994r958412_rule

Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). The "pam_timestamp_check" command is used to check if the default timestamp is valid. When a user logs on, the AUID is set to the UID of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to "-1." The AUID representation is an unsigned 32-bit integer, which equals "4294967295." The audit system interprets "-1", "4294967295", and "unset" in the same way. Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000468-GPOS-00212, SRG-OS-000471-GPOS-00215

Fix: F-56397r824305_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "pam_timestamp_check" command by adding or updating the following rule in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F path=/usr/sbin/pam_timestamp_check -F perm=x -F auid>=1000 -F auid!=unset -k privileged-pam_timestamp_check The audit daemon must be restarted for the changes to take effect.

b

Successful/unsuccessful uses of the "newgrp" command in TOSS must generate an audit record.

RMF Control: AU-3
Severity: Medium
CCI: CCI-000130
Version: TOSS-04-030410
Vuln IDs: V-252995
Rule IDs: SV-252995r958412_rule

Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). The "newgrp" command is used to change the current group ID during a login session. When a user logs on, the AUID is set to the UID of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to "-1." The AUID representation is an unsigned 32-bit integer, which equals "4294967295." The audit system interprets "-1", "4294967295", and "unset" in the same way. Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000468-GPOS-00212, SRG-OS-000471-GPOS-00215

Fix: F-56398r824308_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "newgrp" command by adding or updating the following rule in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F path=/usr/bin/newgrp -F perm=x -F auid>=1000 -F auid!=unset -k priv_cmd The audit daemon must be restarted for the changes to take effect.

b

Successful/unsuccessful uses of the "init_module" command in TOSS must generate an audit record.

RMF Control: AU-3
Severity: Medium
CCI: CCI-000130
Version: TOSS-04-030420
Vuln IDs: V-252996
Rule IDs: SV-252996r958412_rule

Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). The "init_module" command is used to load a kernel module. When a user logs on, the AUID is set to the UID of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to "-1." The AUID representation is an unsigned 32-bit integer, which equals "4294967295." The audit system interprets "-1", "4294967295", and "unset" in the same way. Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000468-GPOS-00212, SRG-OS-000471-GPOS-00215

Fix: F-56399r824311_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "init_module" syscall by adding or updating the following rules in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F arch=b32 -S init_module -F auid>=1000 -F auid!=unset -k module_chng -a always,exit -F arch=b64 -S init_module -F auid>=1000 -F auid!=unset -k module_chng The audit daemon must be restarted for the changes to take effect.

b

Successful/unsuccessful uses of the "rename" command in TOSS must generate an audit record.

RMF Control: AU-3
Severity: Medium
CCI: CCI-000130
Version: TOSS-04-030430
Vuln IDs: V-252997
Rule IDs: SV-252997r958412_rule

Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). The "rename" command will rename the specified files by replacing the first occurrence of expression in their name by replacement. When a user logs on, the AUID is set to the UID of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to "-1." The AUID representation is an unsigned 32-bit integer, which equals "4294967295." The audit system interprets "-1", "4294967295", and "unset" in the same way. Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000468-GPOS-00212, SRG-OS-000471-GPOS-00215

Fix: F-56400r824314_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "rename" syscall by adding or updating the following rules in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F arch=b32 -S rename -F auid>=1000 -F auid!=unset -k delete -a always,exit -F arch=b64 -S rename -F auid>=1000 -F auid!=unset -k delete The audit daemon must be restarted for the changes to take effect.

b

Successful/unsuccessful uses of the "renameat" command in TOSS must generate an audit record.

RMF Control: AU-3
Severity: Medium
CCI: CCI-000130
Version: TOSS-04-030440
Vuln IDs: V-252998
Rule IDs: SV-252998r958412_rule

Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). The "renameat" command renames a file, moving it between directories if required. When a user logs on, the AUID is set to the UID of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to "-1." The AUID representation is an unsigned 32-bit integer, which equals "4294967295." The audit system interprets "-1", "4294967295", and "unset" in the same way. Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000468-GPOS-00212, SRG-OS-000471-GPOS-00215

Fix: F-56401r824317_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "renameat" syscall by adding or updating the following rules in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F arch=b32 -S renameat -F auid>=1000 -F auid!=unset -k delete -a always,exit -F arch=b64 -S renameat -F auid>=1000 -F auid!=unset -k delete The audit daemon must be restarted for the changes to take effect.

b

Successful/unsuccessful uses of the "rmdir" command in TOSS must generate an audit record.

RMF Control: AU-3
Severity: Medium
CCI: CCI-000130
Version: TOSS-04-030450
Vuln IDs: V-252999
Rule IDs: SV-252999r958412_rule

Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). The "rmdir" command removes empty directories. When a user logs on, the AUID is set to the UID of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to "-1." The AUID representation is an unsigned 32-bit integer, which equals "4294967295." The audit system interprets "-1", "4294967295", and "unset" in the same way. Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000468-GPOS-00212, SRG-OS-000471-GPOS-00215

Fix: F-56402r824320_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "rmdir" syscall by adding or updating the following rules in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F arch=b32 -S rmdir -F auid>=1000 -F auid!=unset -k delete -a always,exit -F arch=b64 -S rmdir -F auid>=1000 -F auid!=unset -k delete The audit daemon must be restarted for the changes to take effect.

b

Successful/unsuccessful uses of the "unlink" command in TOSS must generate an audit record.

RMF Control: AU-3
Severity: Medium
CCI: CCI-000130
Version: TOSS-04-030460
Vuln IDs: V-253000
Rule IDs: SV-253000r958412_rule

Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). The "unlink" command deletes a name from the filesystem. If that name was the last link to a file and no processes have the file open, the file is deleted and the space it was using is made available for reuse. When a user logs on, the AUID is set to the UID of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to "-1." The AUID representation is an unsigned 32-bit integer, which equals "4294967295." The audit system interprets "-1", "4294967295", and "unset" in the same way. Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000468-GPOS-00212, SRG-OS-000471-GPOS-00215

Fix: F-56403r824323_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "unlink" syscall by adding or updating the following rules in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F arch=b32 -S unlink -F auid>=1000 -F auid!=unset -k delete -a always,exit -F arch=b64 -S unlink -F auid>=1000 -F auid!=unset -k delete The audit daemon must be restarted for the changes to take effect.

b

Successful/unsuccessful uses of the "unlinkat" command in TOSS must generate an audit record.

RMF Control: AU-3
Severity: Medium
CCI: CCI-000130
Version: TOSS-04-030470
Vuln IDs: V-253001
Rule IDs: SV-253001r958412_rule

Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). The "unlinkat" system call operates in exactly the same way as either "unlink" or "rmdir" except for the differences described in the manual page. When a user logs on, the AUID is set to the UID of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to "-1." The AUID representation is an unsigned 32-bit integer, which equals "4294967295." The audit system interprets "-1", "4294967295", and "unset" in the same way. Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000468-GPOS-00212, SRG-OS-000471-GPOS-00215

Fix: F-56404r824326_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "unlinkat" syscall by adding or updating the following rules in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F arch=b32 -S unlinkat -F auid>=1000 -F auid!=unset -k delete -a always,exit -F arch=b64 -S unlinkat -F auid>=1000 -F auid!=unset -k delete The audit daemon must be restarted for the changes to take effect.

b

Successful/unsuccessful uses of the "finit_module" command in TOSS must generate an audit record.

RMF Control: AU-3
Severity: Medium
CCI: CCI-000130
Version: TOSS-04-030480
Vuln IDs: V-253002
Rule IDs: SV-253002r958412_rule

Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). The "finit_module" command is used to load a kernel module. When a user logs on, the AUID is set to the UID of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to "-1." The AUID representation is an unsigned 32-bit integer, which equals "4294967295." The audit system interprets "-1", "4294967295", and "unset" in the same way. Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000468-GPOS-00212, SRG-OS-000471-GPOS-00215

Fix: F-56405r824329_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "finit_module" syscall by adding or updating the following rules in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F arch=b32 -S finit_module -F auid>=1000 -F auid!=unset -k module_chng -a always,exit -F arch=b64 -S finit_module -F auid>=1000 -F auid!=unset -k module_chng The audit daemon must be restarted for the changes to take effect.

b

Successful/unsuccessful uses of the "delete_module" command in TOSS must generate an audit record.

RMF Control: AU-3
Severity: Medium
CCI: CCI-000130
Version: TOSS-04-030490
Vuln IDs: V-253003
Rule IDs: SV-253003r958412_rule

Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). The "delete_module" command is used to unload a kernel module. When a user logs on, the AUID is set to the UID of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to "-1." The AUID representation is an unsigned 32-bit integer, which equals "4294967295." The audit system interprets "-1", "4294967295", and "unset" in the same way. Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000468-GPOS-00212, SRG-OS-000471-GPOS-00215

Fix: F-56406r824332_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "delete_module" syscall by adding or updating the following rules in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F arch=b32 -S delete_module -F auid>=1000 -F auid!=unset -k module_chng -a always,exit -F arch=b64 -S delete_module -F auid>=1000 -F auid!=unset -k module_chng The audit daemon must be restarted for the changes to take effect.

b

Successful/unsuccessful uses of the "crontab" command in TOSS must generate an audit record.

RMF Control: AU-3
Severity: Medium
CCI: CCI-000130
Version: TOSS-04-030500
Vuln IDs: V-253004
Rule IDs: SV-253004r958412_rule

Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). The "crontab" command is used to maintain crontab files for individual users. Crontab is the program used to install, remove, or list the tables used to drive the cron daemon. This is similar to the task scheduler used in other operating systems. When a user logs on, the AUID is set to the UID of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to "-1." The AUID representation is an unsigned 32-bit integer, which equals "4294967295." The audit system interprets "-1", "4294967295", and "unset" in the same way. Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000468-GPOS-00212, SRG-OS-000471-GPOS-00215

Fix: F-56407r824335_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "crontab" command by adding or updating the following rule in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F path=/usr/bin/crontab -F perm=x -F auid>=1000 -F auid!=unset -k privileged-crontab The audit daemon must be restarted for the changes to take effect.

b

Successful/unsuccessful uses of the "chsh" command in TOSS must generate an audit record.

RMF Control: AU-3
Severity: Medium
CCI: CCI-000130
Version: TOSS-04-030510
Vuln IDs: V-253005
Rule IDs: SV-253005r958412_rule

Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). The "chsh" command is used to change the login shell. When a user logs on, the AUID is set to the UID of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to "-1." The AUID representation is an unsigned 32-bit integer, which equals "4294967295." The audit system interprets "-1", "4294967295", and "unset" in the same way. Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000468-GPOS-00212, SRG-OS-000471-GPOS-00215

Fix: F-56408r824338_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "chsh" command by adding or updating the following rule in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F path=/usr/bin/chsh -F perm=x -F auid>=1000 -F auid!=unset -k priv_cmd The audit daemon must be restarted for the changes to take effect.

b

Successful/unsuccessful uses of setfiles in TOSS must generate an audit record.

RMF Control: AU-3
Severity: Medium
CCI: CCI-000130
Version: TOSS-04-030520
Vuln IDs: V-253006
Rule IDs: SV-253006r958412_rule

Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). The "setfiles" command is primarily used to initialize the security context fields (extended attributes) on one or more filesystems (or parts of them). Usually, it is initially run as part of the SELinux installation process (a step commonly known as labeling). When a user logs on, the AUID is set to the UID of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to "-1." The AUID representation is an unsigned 32-bit integer, which equals "4294967295." The audit system interprets "-1", "4294967295", and "unset" in the same way. Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000468-GPOS-00212, SRG-OS-000471-GPOS-00215

Fix: F-56409r824341_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "setfiles" command by adding or updating the following rule in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F path=/usr/sbin/setfiles -F perm=x -F auid>=1000 -F auid!=unset -k privileged-unix-update The audit daemon must be restarted for the changes to take effect.

b

Successful/unsuccessful uses of the "chacl" command in TOSS must generate an audit record.

RMF Control: AU-3
Severity: Medium
CCI: CCI-000130
Version: TOSS-04-030540
Vuln IDs: V-253007
Rule IDs: SV-253007r958412_rule

Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). The "chacl" command is used to change the access control list of a file or directory. When a user logs on, the AUID is set to the UID of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to "-1." The AUID representation is an unsigned 32-bit integer, which equals "4294967295." The audit system interprets "-1", "4294967295", and "unset" in the same way. Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000468-GPOS-00212, SRG-OS-000471-GPOS-00215

Fix: F-56410r824344_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "chacl" command by adding or updating the following rule in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F path=/usr/bin/chacl -F perm=x -F auid>=1000 -F auid!=unset -k perm_mod The audit daemon must be restarted for the changes to take effect.

b

TOSS must allow only the Information System Security Manager (ISSM) (or individuals or roles appointed by the ISSM) to select which auditable events are to be audited.

RMF Control: AU-12
Severity: Medium
CCI: CCI-000171
Version: TOSS-04-030550
Vuln IDs: V-253008
Rule IDs: SV-253008r958444_rule

Without the capability to restrict which roles and individuals can select which events are audited, unauthorized personnel may be able to prevent the auditing of critical events. Misconfigured audits may degrade the system's performance by overwhelming the audit log. Misconfigured audits may also make it more difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.

Fix: F-56411r824347_fix

Configure the files in directory "/etc/audit/rules.d/" and the "/etc/audit/auditd.conf" file to have a mode of "0640" with the following commands: $ sudo chmod 0640 /etc/audit/rules.d/audit.rules $ sudo chmod 0640 /etc/audit/rules.d/[customrulesfile].rules $ sudo chmod 0640 /etc/audit/auditd.conf

b

Successful/unsuccessful uses of the chmod system call in TOSS must generate an audit record.

RMF Control: AU-12
Severity: Medium
CCI: CCI-000172
Version: TOSS-04-030560
Vuln IDs: V-253009
Rule IDs: SV-253009r958446_rule

Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). The "chmod" system calls are used to change file permissions. When a user logs on, the AUID is set to the UID of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to "-1." The AUID representation is an unsigned 32-bit integer, which equals "4294967295." The audit system interprets "-1", "4294967295", and "unset" in the same way. Satisfies: SRG-OS-000064-GPOS-00033, SRG-OS-000462-GPOS-00206

Fix: F-56412r824350_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "chmod" command by adding or updating the following line to "/etc/audit/rules.d/audit.rules": -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.

b

Successful/unsuccessful uses of the chown system call in TOSS must generate an audit record.

RMF Control: AU-12
Severity: Medium
CCI: CCI-000172
Version: TOSS-04-030570
Vuln IDs: V-253010
Rule IDs: SV-253010r958446_rule

Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). The "chown" system call is used to change file owner and group. When a user logs on, the AUID is set to the UID of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to "-1." The AUID representation is an unsigned 32-bit integer, which equals "4294967295." The audit system interprets "-1", "4294967295", and "unset" in the same way. Satisfies: SRG-OS-000064-GPOS-00033, SRG-OS-000462-GPOS-00206

Fix: F-56413r824353_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "chown" command by adding or updating the following line to "/etc/audit/rules.d/audit.rules": -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.

b

Successful/unsuccessful uses of the creat system call in TOSS must generate an audit record.

RMF Control: AU-12
Severity: Medium
CCI: CCI-000172
Version: TOSS-04-030580
Vuln IDs: V-253011
Rule IDs: SV-253011r958446_rule

Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). The "creat" system call is used to open and possibly create a file or device. When a user logs on, the AUID is set to the UID of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to "-1." The AUID representation is an unsigned 32-bit integer, which equals "4294967295." The audit system interprets "-1", "4294967295", and "unset" in the same way. Satisfies: SRG-OS-000064-GPOS-00033, SRG-OS-000474-GPOS-00219

Fix: F-56414r824356_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "creat" system call by adding or updating the following rules in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F arch=b32 -S creat -F exit=-EPERM -F auid>=1000 -F auid!=unset -k perm_access -a always,exit -F arch=b64 -S creat -F exit=-EPERM -F auid>=1000 -F auid!=unset -k perm_access -a always,exit -F arch=b32 -S creat -F exit=-EACCES -F auid>=1000 -F auid!=unset -k perm_access -a always,exit -F arch=b64 -S creat -F exit=-EACCES -F auid>=1000 -F auid!=unset -k perm_access The audit daemon must be restarted for the changes to take effect.

b

Successful/unsuccessful uses of the fchmod system call in TOSS must generate an audit record.

RMF Control: AU-12
Severity: Medium
CCI: CCI-000172
Version: TOSS-04-030590
Vuln IDs: V-253012
Rule IDs: SV-253012r958446_rule

Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). The "fchmod" system call is used to change permissions of a file. When a user logs on, the AUID is set to the UID of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to "-1." The AUID representation is an unsigned 32-bit integer, which equals "4294967295." The audit system interprets "-1", "4294967295", and "unset" in the same way. Satisfies: SRG-OS-000064-GPOS-00033, SRG-OS-000462-GPOS-00206

Fix: F-56415r824359_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "fchmod" system call by adding or updating the following line to "/etc/audit/rules.d/audit.rules": -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.

b

Successful/unsuccessful uses of the fchmodat system call in TOSS must generate an audit record.

RMF Control: AU-12
Severity: Medium
CCI: CCI-000172
Version: TOSS-04-030600
Vuln IDs: V-253013
Rule IDs: SV-253013r958446_rule

Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). The "fchmodat" system call is used to change permissions of a file relative to a directory file descriptor. When a user logs on, the AUID is set to the UID of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to "-1." The AUID representation is an unsigned 32-bit integer, which equals "4294967295." The audit system interprets "-1", "4294967295", and "unset" in the same way. Satisfies: SRG-OS-000064-GPOS-00033, SRG-OS-000462-GPOS-00206

Fix: F-56416r824362_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "fchmodat" system call by adding or updating the following lines to "/etc/audit/rules.d/audit.rules": -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.

b

Successful/unsuccessful uses of the fchown system call in TOSS must generate an audit record.

RMF Control: AU-12
Severity: Medium
CCI: CCI-000172
Version: TOSS-04-030610
Vuln IDs: V-253014
Rule IDs: SV-253014r958446_rule

Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). The "fchown" system call is used to change the ownership of a file referred to by the open file descriptor. When a user logs on, the AUID is set to the UID of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to "-1." The AUID representation is an unsigned 32-bit integer, which equals "4294967295." The audit system interprets "-1", "4294967295", and "unset" in the same way. Satisfies: SRG-OS-000064-GPOS-00033, SRG-OS-000462-GPOS-00206

Fix: F-56417r824365_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "fchown" system call by adding or updating the following line to "/etc/audit/rules.d/audit.rules": -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.

b

Successful/unsuccessful uses of the fchownat system call in TOSS must generate an audit record.

RMF Control: AU-12
Severity: Medium
CCI: CCI-000172
Version: TOSS-04-030620
Vuln IDs: V-253015
Rule IDs: SV-253015r958446_rule

Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). The "fchownat" system call is used to change ownership of a file relative to a directory file descriptor. When a user logs on, the AUID is set to the UID of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to "-1." The AUID representation is an unsigned 32-bit integer, which equals "4294967295." The audit system interprets "-1", "4294967295", and "unset" in the same way. Satisfies: SRG-OS-000064-GPOS-00033, SRG-OS-000462-GPOS-00206

Fix: F-56418r824368_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "fchownat" system call by adding or updating the following lines to "/etc/audit/rules.d/audit.rules": -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.

b

Successful/unsuccessful uses of the ftruncate system call system call in TOSS must generate an audit record.

RMF Control: AU-12
Severity: Medium
CCI: CCI-000172
Version: TOSS-04-030630
Vuln IDs: V-253016
Rule IDs: SV-253016r958446_rule

Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). The "truncate" and "ftruncate" system calls are used to truncate a file to a specified length. When a user logs on, the AUID is set to the UID of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to "-1." The AUID representation is an unsigned 32-bit integer, which equals "4294967295." The audit system interprets "-1", "4294967295", and "unset" in the same way. Satisfies: SRG-OS-000064-GPOS-00033, SRG-OS-000474-GPOS-00219

Fix: F-56419r824371_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "ftruncate" system call by adding or updating the following rules in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F arch=b32 -S ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -k perm_access -a always,exit -F arch=b64 -S ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -k perm_access -a always,exit -F arch=b32 -S ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -k perm_access -a always,exit -F arch=b64 -S ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -k perm_access The audit daemon must be restarted for the changes to take effect.

b

Successful/unsuccessful uses of the lchown system call in TOSS must generate an audit record.

RMF Control: AU-12
Severity: Medium
CCI: CCI-000172
Version: TOSS-04-030640
Vuln IDs: V-253017
Rule IDs: SV-253017r958446_rule

Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). The "lchown" system call is used to change the ownership of the file specified by a path, which does not dereference symbolic links. When a user logs on, the AUID is set to the UID of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to "-1." The AUID representation is an unsigned 32-bit integer, which equals "4294967295." The audit system interprets "-1", "4294967295", and "unset" in the same way. Satisfies: SRG-OS-000064-GPOS-00033, SRG-OS-000462-GPOS-00206

Fix: F-56420r824374_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "lchown" system call by adding or updating the following lines to "/etc/audit/rules.d/audit.rules": -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.

b

Successful/unsuccessful uses of the open system call in TOSS must generate an audit record.

RMF Control: AU-12
Severity: Medium
CCI: CCI-000172
Version: TOSS-04-030650
Vuln IDs: V-253018
Rule IDs: SV-253018r958446_rule

Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). The "open system" call opens a file specified by a pathname. If the specified file does not exist, it may optionally be created by "open." When a user logs on, the AUID is set to the UID of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to "-1." The AUID representation is an unsigned 32-bit integer, which equals "4294967295." The audit system interprets "-1", "4294967295", and "unset" in the same way. Satisfies: SRG-OS-000064-GPOS-00033, SRG-OS-000474-GPOS-00219

Fix: F-56421r824377_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "open" system call by adding or updating the following rules in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F arch=b32 -S open -F exit=-EPERM -F auid>=1000 -F auid!=unset -k perm_access -a always,exit -F arch=b64 -S open -F exit=-EPERM -F auid>=1000 -F auid!=unset -k perm_access -a always,exit -F arch=b32 -S open -F exit=-EACCES -F auid>=1000 -F auid!=unset -k perm_access -a always,exit -F arch=b64 -S open -F exit=-EACCES -F auid>=1000 -F auid!=unset -k perm_access The audit daemon must be restarted for the changes to take effect.

b

Successful/unsuccessful uses of the open_by_handle_at system call system call in TOSS must generate an audit record.

RMF Control: AU-12
Severity: Medium
CCI: CCI-000172
Version: TOSS-04-030660
Vuln IDs: V-253019
Rule IDs: SV-253019r958446_rule

Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). The "name_to_handle_at" and "open_by_handle_at" system calls split the functionality of openat into two parts: "name_to_handle_at" returns an opaque handle that corresponds to a specified file; "open_by_handle_at" opens the file corresponding to a handle returned by a previous call to "name_to_handle_at" and returns an open file descriptor. When a user logs on, the AUID is set to the UID of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to "-1." The AUID representation is an unsigned 32-bit integer, which equals "4294967295." The audit system interprets "-1", "4294967295", and "unset" in the same way. Satisfies: SRG-OS-000064-GPOS-00033, SRG-OS-000474-GPOS-00219

Fix: F-56422r824380_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "open_by_handle_at" system call by adding or updating the following rules in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F arch=b32 -S open_by_handle_at -F exit=-EPERM -F auid>=1000 -F auid!=unset -k perm_access -a always,exit -F arch=b64 -S open_by_handle_at -F exit=-EPERM -F auid>=1000 -F auid!=unset -k perm_access -a always,exit -F arch=b32 -S open_by_handle_at -F exit=-EACCES -F auid>=1000 -F auid!=unset -k perm_access -a always,exit -F arch=b64 -S open_by_handle_at -F exit=-EACCES -F auid>=1000 -F auid!=unset -k perm_access The audit daemon must be restarted for the changes to take effect.

b

Successful/unsuccessful uses of the openat system call in TOSS must generate an audit record.

RMF Control: AU-12
Severity: Medium
CCI: CCI-000172
Version: TOSS-04-030670
Vuln IDs: V-253020
Rule IDs: SV-253020r958446_rule

Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). The "openat" system call opens a file specified by a relative pathname. When a user logs on, the AUID is set to the UID of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to "-1." The AUID representation is an unsigned 32-bit integer, which equals "4294967295." The audit system interprets "-1", "4294967295", and "unset" in the same way. Satisfies: SRG-OS-000064-GPOS-00033, SRG-OS-000474-GPOS-00219

Fix: F-56423r824383_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "openat" command by adding or updating the following rules in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F arch=b32 -S openat -F exit=-EPERM -F auid>=1000 -F auid!=unset -k perm_access -a always,exit -F arch=b64 -S openat -F exit=-EPERM -F auid>=1000 -F auid!=unset -k perm_access -a always,exit -F arch=b32 -S openat -F exit=-EACCES -F auid>=1000 -F auid!=unset -k perm_access -a always,exit -F arch=b64 -S openat -F exit=-EACCES -F auid>=1000 -F auid!=unset -k perm_access The audit daemon must be restarted for the changes to take effect.

b

Successful/unsuccessful uses of the truncate system call in TOSS must generate an audit record.

RMF Control: AU-12
Severity: Medium
CCI: CCI-000172
Version: TOSS-04-030680
Vuln IDs: V-253021
Rule IDs: SV-253021r958446_rule

Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). The "truncate" system calls are used to truncate a file to a specified length. When a user logs on, the AUID is set to the UID of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to "-1." The AUID representation is an unsigned 32-bit integer, which equals "4294967295." The audit system interprets "-1", "4294967295", and "unset" in the same way. Satisfies: SRG-OS-000064-GPOS-00033, SRG-OS-000474-GPOS-00219

Fix: F-56424r824386_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "truncate" system calls by adding or updating the following rules in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F arch=b32 -S truncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -k perm_access -a always,exit -F arch=b64 -S truncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -k perm_access -a always,exit -F arch=b32 -S truncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -k perm_access -a always,exit -F arch=b64 -S truncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -k perm_access The audit daemon must be restarted for the changes to take effect.

b

TOSS audit tools must be owned by "root".

RMF Control: AU-9
Severity: Medium
CCI: CCI-001493
Version: TOSS-04-030750
Vuln IDs: V-253022
Rule IDs: SV-253022r991557_rule

Protecting audit information also includes identifying and protecting the tools used to view and manipulate log data. Therefore, protecting audit tools is necessary to prevent unauthorized operation on audit information. Operating systems providing tools to interface with audit information will leverage user permissions and roles identifying the user accessing the tools and the corresponding rights the user enjoys in order to make access decisions regarding the access to audit tools. Audit tools include, but are not limited to, vendor-provided and open source audit tools needed to successfully view and manipulate audit information system activity and records. Audit tools include custom queries and report generators. Satisfies: SRG-OS-000256-GPOS-00097, SRG-OS-000257-GPOS-00098, SRG-OS-000258-GPOS-00099

Fix: F-56425r825979_fix

Configure the audit tools to be owned by "root", by running the following command: $ sudo chown root [audit_tool] Replace "[audit_tool]" with each audit tool not owned by "root".

b

TOSS must generate audit records for all account creations, modifications, disabling, and termination events that affect "/etc/group".

RMF Control: AC-2
Severity: Medium
CCI: CCI-002130
Version: TOSS-04-030790
Vuln IDs: V-253024
Rule IDs: SV-253024r958684_rule

Once an attacker establishes access to a system, the attacker often attempts to create a persistent method of reestablishing access. One way to accomplish this is for the attacker to enable a new or disabled account. Auditing account modification actions provides logging that can be used for forensic purposes.

Fix: F-56427r825982_fix

Configure TOSS to generate audit records for all account creations, modifications, disabling, and termination events that affect "/etc/group". Add or update the following file system rule to "/etc/audit/rules.d/audit.rules": -w /etc/group -p wa -k identity The audit daemon must be restarted for the changes to take effect.

b

TOSS must generate audit records for all account creations, modifications, disabling, and termination events that affect "/etc/gshadow".

RMF Control: AC-2
Severity: Medium
CCI: CCI-002130
Version: TOSS-04-030800
Vuln IDs: V-253025
Rule IDs: SV-253025r958684_rule

Once an attacker establishes access to a system, the attacker often attempts to create a persistent method of reestablishing access. One way to accomplish this is for the attacker to enable a new or disabled account. Auditing account modification actions provides logging that can be used for forensic purposes.

Fix: F-56428r825985_fix

Configure TOSS to generate audit records for all account creations, modifications, disabling, and termination events that affect "/etc/gshadow". Add or update the following file system rule to "/etc/audit/rules.d/audit.rules": -w /etc/gshadow -p wa -k identity The audit daemon must be restarted for the changes to take effect.

b

TOSS must generate audit records for all account creations, modifications, disabling, and termination events that affect "/etc/passwd".

RMF Control: AC-2
Severity: Medium
CCI: CCI-002130
Version: TOSS-04-030810
Vuln IDs: V-253026
Rule IDs: SV-253026r958684_rule

Once an attacker establishes access to a system, the attacker often attempts to create a persistent method of reestablishing access. One way to accomplish this is for the attacker to enable a new or disabled account. Auditing account modification actions provides logging that can be used for forensic purposes.

Fix: F-56429r825988_fix

Configure TOSS to generate audit records for all account creations, modifications, disabling, and termination events that affect "/etc/passwd". Add or update the following file system rule to "/etc/audit/rules.d/audit.rules": -w /etc/passwd -p wa -k identity The audit daemon must be restarted for the changes to take effect.

b

TOSS must generate audit records for all account creations, modifications, disabling, and termination events that affect "/etc/security/opasswd".

RMF Control: AC-2
Severity: Medium
CCI: CCI-002130
Version: TOSS-04-030820
Vuln IDs: V-253027
Rule IDs: SV-253027r958684_rule

Once an attacker establishes access to a system, the attacker often attempts to create a persistent method of reestablishing access. One way to accomplish this is for the attacker to enable a new or disabled account. Auditing account modification actions provides logging that can be used for forensic purposes.

Fix: F-56430r825991_fix

Configure TOSS to generate audit records for all account creations, modifications, disabling, and termination events that affect "/etc/security/opasswd". Add or update the following file system rule to "/etc/audit/rules.d/audit.rules": -w /etc/security/opasswd -p wa -k identity The audit daemon must be restarted for the changes to take effect.

b

TOSS must generate audit records for all account creations, modifications, disabling, and termination events that affect "/etc/sudoers".

RMF Control: AC-2
Severity: Medium
CCI: CCI-002130
Version: TOSS-04-030840
Vuln IDs: V-253028
Rule IDs: SV-253028r958684_rule

Once an attacker establishes access to a system, the attacker often attempts to create a persistent method of reestablishing access. One way to accomplish this is for the attacker to enable a new or disabled account. Auditing account modification actions provides logging that can be used for forensic purposes.

Fix: F-56431r825994_fix

Configure TOSS to generate audit records for all account creations, modifications, disabling, and termination events that affect "/etc/sudoers". Add or update the following file system rule to "/etc/audit/rules.d/audit.rules": -w /etc/sudoers -p wa -k identity The audit daemon must be restarted for the changes to take effect.

b

TOSS must generate audit records for all account creations, modifications, disabling, and termination events that affect "/etc/sudoers.d/".

RMF Control: AC-2
Severity: Medium
CCI: CCI-002130
Version: TOSS-04-030850
Vuln IDs: V-253029
Rule IDs: SV-253029r958684_rule

Once an attacker establishes access to a system, the attacker often attempts to create a persistent method of reestablishing access. One way to accomplish this is for the attacker to enable a new or disabled account. Auditing account modification actions provides logging that can be used for forensic purposes.

Fix: F-56432r825997_fix

Configure TOSS to generate audit records for all account creations, modifications, disabling, and termination events that affect "/etc/sudoers.d/". Add or update the following file system rule to "/etc/audit/rules.d/audit.rules": -w /etc/sudoers.d/ -p wa -k identity The audit daemon must be restarted for the changes to take effect.

b

The TOSS audit system must prevent all software from executing at higher privilege levels than users executing the software and the audit system must be configured to audit the execution of privileged functions.

RMF Control: AC-6
Severity: Medium
CCI: CCI-002233
Version: TOSS-04-030860
Vuln IDs: V-253030
Rule IDs: SV-253030r958730_rule

In certain situations, software applications/programs need to execute with elevated privileges to perform required functions. However, if the privileges required for execution are at a higher level than the privileges assigned to organizational users invoking such applications/programs, those users are indirectly provided with greater privileges than assigned by the organizations. Some programs and processes are required to operate at a higher privilege level and therefore should be excluded from the organization-defined software list after review. Satisfies: SRG-OS-000326-GPOS-00126, SRG-OS-000327-GPOS-00127

Fix: F-56433r824761_fix

Configure TOSS to audit the execution of the "execve" system call. Add or update the following file system rules to "/etc/audit/rules.d/audit.rules": -a always,exit -F arch=b32 -S execve -C uid!=euid -F euid=0 -k execpriv -a always,exit -F arch=b64 -S execve -C uid!=euid -F euid=0 -k execpriv -a always,exit -F arch=b32 -S execve -C gid!=egid -F egid=0 -k execpriv -a always,exit -F arch=b64 -S execve -C gid!=egid -F egid=0 -k execpriv The audit daemon must be restarted for the changes to take effect.

b

TOSS must label all off-loaded audit logs before sending them to the central log server.

RMF Control: AU-4
Severity: Medium
CCI: CCI-001851
Version: TOSS-04-030910
Vuln IDs: V-253033
Rule IDs: SV-253033r958754_rule

Without establishing what type of events occurred, the source of events, where events occurred, and the outcome of events, it would be difficult to establish, correlate, and investigate the events leading up to an outage or attack. Audit record content that may be necessary to satisfy this requirement includes, for example, time stamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, filenames involved, and access control or flow control rules invoked. Enriched logging is needed to determine who, what, and when events occur on a system. Without this, determining root cause of an event will be much more difficult. When audit logs are not labeled before they are sent to a central log server, the audit data will not be able to be analyzed and tied back to the correct system. Satisfies: SRG-OS-000342-GPOS-00133, SRG-OS-000479-GPOS-00224

Fix: F-56436r824770_fix

Edit the /etc/audit/auditd.conf file and add or update the "name_format" option to one of "hostname", "fqd", or "numeric": name_format = hostname The audit daemon must be restarted for changes to take effect.

b

The TOSS audit system must be configured to audit any usage of the "fsetxattr" system call.

RMF Control: AU-12
Severity: Medium
CCI: CCI-000172
Version: TOSS-04-030990
Vuln IDs: V-253034
Rule IDs: SV-253034r991570_rule

Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). "Fsetxattr" is a system call used to set an extended attribute value. This is used to set extended attributes on a file. When a user logs on, the AUID is set to the UID of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to "-1." The auid representation is an unsigned 32-bit integer, which equals "4294967295." The audit system interprets "-1", "4294967295", and "unset" in the same way. Satisfies: SRG-OS-000458-GPOS-00203, SRG-OS-000463-GPOS-00207

Fix: F-56437r824773_fix

Configure TOSS to audit the execution of the "fsetxattr" system call, by adding or updating the following lines to "/etc/audit/rules.d/audit.rules": -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 -a always,exit -F arch=b32 -S fsetxattr -F auid=0 -k perm_mod -a always,exit -F arch=b64 -S fsetxattr -F auid=0 -k perm_mod The audit daemon must be restarted for the changes to take effect.

b

The TOSS audit system must be configured to audit any usage of the "lsetxattr" system call.

RMF Control: AU-12
Severity: Medium
CCI: CCI-000172
Version: TOSS-04-031000
Vuln IDs: V-253035
Rule IDs: SV-253035r991570_rule

Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). "Lsetxattr" is a system call used to set an extended attribute value. This is used to set extended attributes on a symbolic link. When a user logs on, the AUID is set to the UID of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to "-1." The AUID representation is an unsigned 32-bit integer, which equals "4294967295." The audit system interprets "-1", "4294967295", and "unset" in the same way. Satisfies: SRG-OS-000458-GPOS-00203, SRG-OS-000463-GPOS-00207

Fix: F-56438r824776_fix

Configure TOSS to audit the execution of the "lsetxattr" system call, by adding or updating the following lines to "/etc/audit/rules.d/audit.rules": -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 -a always,exit -F arch=b32 -S lsetxattr -F auid=0 -k perm_mod -a always,exit -F arch=b64 -S lsetxattr -F auid=0 -k perm_mod The audit daemon must be restarted for the changes to take effect.

b

Successful/unsuccessful uses of the fremovexattr system call in TOSS must generate an audit record.

RMF Control: AU-12
Severity: Medium
CCI: CCI-000172
Version: TOSS-04-031100
Vuln IDs: V-253036
Rule IDs: SV-253036r991577_rule

Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). "Fremovexattr" is a system call that removes extended attributes. This is used for removal of extended attributes from a file. When a user logs on, the AUID is set to the UID of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to "-1." The AUID representation is an unsigned 32-bit integer, which equals "4294967295." The audit system interprets "-1", "4294967295", and "unset" in the same way.

Fix: F-56439r824779_fix

Configure TOSS to audit the execution of the "fremovexattr" system call by adding or updating the following lines to "/etc/audit/rules.d/audit.rules": -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 -a always,exit -F arch=b32 -S fremovexattr -F auid=0 -k perm_mod -a always,exit -F arch=b64 -S fremovexattr -F auid=0 -k perm_mod The audit daemon must be restarted for the changes to take effect.

b

Successful/unsuccessful uses of the "lremovexattr" system call in TOSS must generate an audit record.

RMF Control: AU-12
Severity: Medium
CCI: CCI-000172
Version: TOSS-04-031110
Vuln IDs: V-253037
Rule IDs: SV-253037r991577_rule

Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). "Lremovexattr" is a system call that removes extended attributes. This is used for removal of extended attributes from symbolic links. When a user logs on, the AUID is set to the UID of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to "-1." The AUID representation is an unsigned 32-bit integer, which equals "4294967295." The audit system interprets "-1", "4294967295", and "unset" in the same way.

Fix: F-56440r824782_fix

Configure TOSS to audit the execution of the "lremovexattr" system call, by adding or updating the following lines to "/etc/audit/rules.d/audit.rules": -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 -a always,exit -F arch=b32 -S lremovexattr -F auid=0 -k perm_mod -a always,exit -F arch=b64 -S lremovexattr -F auid=0 -k perm_mod The audit daemon must be restarted for the changes to take effect.

b

Successful/unsuccessful uses of the "removexattr" system call in TOSS must generate an audit record.

RMF Control: AU-12
Severity: Medium
CCI: CCI-000172
Version: TOSS-04-031120
Vuln IDs: V-253038
Rule IDs: SV-253038r991577_rule

Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). "Removexattr" is a system call that removes extended attributes. When a user logs on, the AUID is set to the UID of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to "-1." The AUID representation is an unsigned 32-bit integer, which equals "4294967295." The audit system interprets "-1", "4294967295", and "unset" in the same way.

Fix: F-56441r824785_fix

Configure TOSS to audit the execution of the "removexattr" system call, by adding or updating the following lines to "/etc/audit/rules.d/audit.rules": -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 -a always,exit -F arch=b32 -S removexattr -F auid=0 -k perm_mod -a always,exit -F arch=b64 -S removexattr -F auid=0 -k perm_mod The audit daemon must be restarted for the changes to take effect.

b

Successful/unsuccessful modifications to the "lastlog" file in TOSS must generate an audit record.

RMF Control: AU-12
Severity: Medium
CCI: CCI-000172
Version: TOSS-04-031130
Vuln IDs: V-253039
Rule IDs: SV-253039r991578_rule

Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). Satisfies: SRG-OS-000470-GPOS-00214, SRG-OS-000473-GPOS-00218

Fix: F-56442r824788_fix

Configure the audit system to generate an audit event for any successful/unsuccessful modifications to the "lastlog" file by adding or updating the following rules in the "/etc/audit/rules.d/audit.rules" file: -w /var/log/lastlog -p wa -k logins The audit daemon must be restarted for the changes to take effect.

b

Successful/unsuccessful uses of "semanage" in TOSS must generate an audit record.

RMF Control: AU-12
Severity: Medium
CCI: CCI-000172
Version: TOSS-04-031140
Vuln IDs: V-253040
Rule IDs: SV-253040r991579_rule

Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). The "semanage" command is used to configure certain elements of SELinux policy without requiring modification to or recompilation from policy sources.

Fix: F-56443r824791_fix

Configure the audit system to generate an audit event for any successful/unsuccessful uses of the "semanage" by adding or updating the following rule in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F path=/usr/sbin/semanage -F perm=x -F auid>=1000 -F auid!=unset -k privileged The audit daemon must be restarted for the changes to take effect.

b

Successful/unsuccessful uses of the "gpasswd" command in TOSS must generate an audit record.

RMF Control: AU-12
Severity: Medium
CCI: CCI-000172
Version: TOSS-04-031150
Vuln IDs: V-253041
Rule IDs: SV-253041r991579_rule

Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). The "gpasswd" command is used to administer /etc/group and /etc/gshadow. Every group can have administrators, members and a password.

Fix: F-56444r824794_fix

Configure the audit system to generate an audit event for any successful/unsuccessful uses of the "gpasswd" command by adding or updating the following rule in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F path=/usr/bin/gpasswd -F perm=x -F auid>=1000 -F auid!=unset -k privileged The audit daemon must be restarted for the changes to take effect.

b

Successful/unsuccessful uses of the "mount" command in TOSS must generate an audit record.

RMF Control: AU-12
Severity: Medium
CCI: CCI-000172
Version: TOSS-04-031160
Vuln IDs: V-253042
Rule IDs: SV-253042r991579_rule

Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). The "mount" command is used to mount a filesystem.

Fix: F-56445r824797_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "mount" command by adding or updating the following rules in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F path=/usr/bin/mount -F perm=x -F auid>=1000 -F auid!=unset -k privileged The audit daemon must be restarted for the changes to take effect.

b

Successful/unsuccessful uses of the "mount" syscall in TOSS must generate an audit record.

RMF Control: AU-12
Severity: Medium
CCI: CCI-000172
Version: TOSS-04-031170
Vuln IDs: V-253043
Rule IDs: SV-253043r991579_rule

Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). The "mount" syscall is used to mount a filesystem.

Fix: F-56446r824800_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "mount" syscall by adding or updating the following rules in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F arch=b32 -S mount -F auid>=1000 -F auid!=unset -k privileged -a always,exit -F arch=b64 -S mount -F auid>=1000 -F auid!=unset -k privileged The audit daemon must be restarted for the changes to take effect.

b

Successful/unsuccessful uses of the "su" command in TOSS must generate an audit record.

RMF Control: AU-12
Severity: Medium
CCI: CCI-000172
Version: TOSS-04-031180
Vuln IDs: V-253044
Rule IDs: SV-253044r991579_rule

Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). The "su" command allows a user to run commands with a substitute user and group ID.

Fix: F-56447r824803_fix

Configure TOSS to generate audit records when successful/unsuccessful attempts to use the "su" command occur by adding or updating the following rule in "/etc/audit/rules.d/audit.rules": -a always,exit -F path=/usr/bin/su -F perm=x -F auid>=1000 -F auid!=unset -k privileged The audit daemon must be restarted for the changes to take effect.

b

Successful/unsuccessful uses of the "umount" command in TOSS must generate an audit record.

RMF Control: AU-12
Severity: Medium
CCI: CCI-000172
Version: TOSS-04-031190
Vuln IDs: V-253045
Rule IDs: SV-253045r991579_rule

Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). The "umount" command is used to unmount a filesystem.

Fix: F-56448r824806_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "umount" command by adding or updating the following rules in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F path=/usr/bin/umount -F perm=x -F auid>=1000 -F auid!=unset -k privileged The audit daemon must be restarted for the changes to take effect.

b

Successful/unsuccessful uses of the "unix_update" in TOSS must generate an audit record.

RMF Control: AU-12
Severity: Medium
CCI: CCI-000172
Version: TOSS-04-031200
Vuln IDs: V-253046
Rule IDs: SV-253046r991579_rule

Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). "unix_update" is a helper program for the "pam_unix" module that updates the password for a given user. It is not intended to be run directly from the command line and logs a security violation if done so.

Fix: F-56449r824809_fix

Configure the audit system to generate an audit event for any successful/unsuccessful uses of the "unix_update" by adding or updating the following rule in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F path=/usr/sbin/unix_update -F perm=x -F auid>=1000 -F auid!=unset -k privileged The audit daemon must be restarted for the changes to take effect.

b

Successful/unsuccessful uses of the "usermod" command in TOSS must generate an audit record.

RMF Control: AU-12
Severity: Medium
CCI: CCI-000172
Version: TOSS-04-031210
Vuln IDs: V-253047
Rule IDs: SV-253047r991579_rule

Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). The "usermod" command modifies the system account files to reflect the changes that are specified on the command line.

Fix: F-56450r824812_fix

Configure the audit system to generate an audit event for any successful/unsuccessful uses of the "usermod" command by adding or updating the following rule in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F path=/usr/sbin/usermod -F perm=x -F auid>=1000 -F auid!=unset -k privileged The audit daemon must be restarted for the changes to take effect.

b

Successful/unsuccessful uses of "unix_chkpwd" in TOSS must generate an audit record.

RMF Control: AU-12
Severity: Medium
CCI: CCI-000172
Version: TOSS-04-031220
Vuln IDs: V-253048
Rule IDs: SV-253048r991579_rule

Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). The "unix_chkpwd" command is a helper program for the pam_unix module that verifies the password of the current user. It also checks password and account expiration dates in shadow. It is not intended to be run directly from the command line and logs a security violation if done so.

Fix: F-56451r824815_fix

Configure the audit system to generate an audit event for any successful/unsuccessful uses of the "unix_chkpwd" by adding or updating the following rule in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F path=/usr/sbin/unix_chkpwd -F perm=x -F auid>=1000 -F auid!=unset -k privileged The audit daemon must be restarted for the changes to take effect.

b

Successful/unsuccessful uses of "userhelper" in TOSS must generate an audit record.

RMF Control: AU-12
Severity: Medium
CCI: CCI-000172
Version: TOSS-04-031230
Vuln IDs: V-253049
Rule IDs: SV-253049r991579_rule

Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). The "userhelper" command is not intended to be run interactively. "Userhelper" provides a basic interface to change a user's password, gecos information, and shell. The main difference between this program and its traditional equivalents (passwd, chfn, chsh) is that prompts are written to standard out to make it easy for a graphical user interface wrapper to interface to it as a child process.

Fix: F-56452r824818_fix

Configure the audit system to generate an audit event for any successful/unsuccessful uses of the "userhelper" by adding or updating the following rule in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F path=/usr/sbin/userhelper -F perm=x -F auid>=1000 -F auid!=unset -k privileged The audit daemon must be restarted for the changes to take effect.

b

Successful/unsuccessful uses of the "kmod" command in TOSS must generate an audit record.

RMF Control: AU-12
Severity: Medium
CCI: CCI-000172
Version: TOSS-04-031240
Vuln IDs: V-253050
Rule IDs: SV-253050r991580_rule

"Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). The "kmod" command is used to control Linux Kernel modules. Satisfies: SRG-OS-000471-GPOS-00216, SRG-OS-000477-GPOS-00222

Fix: F-56453r824821_fix

Configure TOSS to audit the execution of the module management program "kmod" by adding or updating the following line to "/etc/audit/rules.d/audit.rules": -a always,exit -F path=/usr/bin/kmod -F perm=x -F auid>=1000 -F auid!=unset -k modules The audit daemon must be restarted for the changes to take effect.

b

The auditd service must be running in TOSS.

RMF Control: CM-6
Severity: Medium
CCI: CCI-000366
Version: TOSS-04-031340
Vuln IDs: V-253051
Rule IDs: SV-253051r991589_rule

Configuring TOSS to implement organization-wide security implementation guides and security checklists ensures compliance with federal standards and establishes a common security baseline across the DoD that reflects the most restrictive security posture consistent with operational requirements. Configuration settings are the set of parameters that can be changed in hardware, software, or firmware components of the system that affect the security posture and/or functionality of the system. Security-related parameters are those parameters impacting the security state of the system, including the parameters required to satisfy other security control requirements. Security-related parameters include, for example: registry settings; account, file, directory permission settings; and settings for functions, ports, protocols, services, and remote connections.

Fix: F-56454r824824_fix

Start the auditd service and enable the auditd service with the following commands: $ sudo systemctl start auditd.service $ sudo systemctl enable auditd.service

b

The TOSS audit system must audit local events.

RMF Control
Severity: Medium
CCI: CCI-004188
Version: TOSS-04-031350
Vuln IDs: V-253052
Rule IDs: SV-253052r991589_rule

Without establishing what type of events occurred, the source of events, where events occurred, and the outcome of events, it would be difficult to establish, correlate, and investigate the events leading up to an outage or attack. Audit record content that may be necessary to satisfy this requirement includes, for example, time stamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, filenames involved, and access control or flow control rules invoked.

Fix: F-56455r824827_fix

Configure TOSS to audit local events on the system. Add or update the following line in "/etc/audit/auditd.conf" file: local_events = yes

a

TOSS must resolve audit information before writing to disk.

RMF Control: CM-6
Severity: Low
CCI: CCI-000366
Version: TOSS-04-031360
Vuln IDs: V-253053
Rule IDs: SV-253053r991589_rule

Without establishing what type of events occurred, the source of events, where events occurred, and the outcome of events, it would be difficult to establish, correlate, and investigate the events leading up to an outage or attack. Audit record content that may be necessary to satisfy this requirement includes, for example, time stamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, filenames involved, and access control or flow control rules invoked. Enriched logging aids in making sense of who, what, and when events occur on a system. Without this, determining root cause of an event will be much more difficult.

Fix: F-56456r824830_fix

Edit the /etc/audit/auditd.conf file and add or update the "log_format" option: log_format = ENRICHED The audit daemon must be restarted for changes to take effect.

b

TOSS must have the packages required for offloading audit logs installed.

RMF Control: CM-6
Severity: Medium
CCI: CCI-000366
Version: TOSS-04-031370
Vuln IDs: V-253054
Rule IDs: SV-253054r991589_rule

Information stored in one location is vulnerable to accidental or incidental deletion or alteration. Offloading is a common process in information systems with limited audit storage capacity. TOSS installation media provides "rsyslogd." "rsyslogd" is a system utility providing support for message logging. Support for both internet and UNIX domain sockets enables this utility to support both local and remote logging. Couple this utility with "gnutls" (which is a secure communications library implementing the SSL, TLS, and DTLS protocols), and now there is a method to securely encrypt and offload auditing. Rsyslog provides three ways to forward message: the traditional UDP transport, which is extremely lossy but standard; the plain TCP based transport, which loses messages only during certain situations but is widely available; and the RELP transport, which does not lose messages but is currently available only as part of the rsyslogd 3.15.0 and above. Examples of each configuration: UDP *.* @remotesystemname TCP *.* @@remotesystemname RELP *.* :omrelp:remotesystemname:2514 Note that a port number was given as there is no standard port for RELP.

Fix: F-56457r824833_fix

Configure the operating system to offload audit logs by installing the required packages with the following command: $ sudo yum install rsyslog

b

TOSS must have the packages required for encrypting offloaded audit logs installed.

RMF Control: CM-6
Severity: Medium
CCI: CCI-000366
Version: TOSS-04-031380
Vuln IDs: V-253055
Rule IDs: SV-253055r991589_rule

Information stored in one location is vulnerable to accidental or incidental deletion or alteration. Offloading is a common process in information systems with limited audit storage capacity. TOSS installation media provides "rsyslogd." "rsyslogd" is a system utility providing support for message logging. Support for both internet and UNIX domain sockets enables this utility to support both local and remote logging. Couple this utility with "rsyslog-gnutls" (which is a secure communications library implementing the SSL, TLS, and DTLS protocols), and now there is a method to securely encrypt and offload auditing. Rsyslog provides three ways to forward message: the traditional UDP transport, which is extremely lossy but standard; the plain TCP based transport, which loses messages only during certain situations but is widely available; and the RELP transport, which does not lose messages but is currently available only as part of the rsyslogd 3.15.0 and above. Examples of each configuration: UDP *.* @remotesystemname TCP *.* @@remotesystemname RELP *.* :omrelp:remotesystemname:2514 Note that a port number was given as there is no standard port for RELP.

Fix: F-56458r824836_fix

Configure the operating system to encrypt offloaded audit logs by installing the required packages with the following command: $ sudo yum install rsyslog-gnutls

b

TOSS must monitor remote access methods.

RMF Control: AC-17
Severity: Medium
CCI: CCI-000067
Version: TOSS-04-040010
Vuln IDs: V-253056
Rule IDs: SV-253056r958406_rule

Remote access services, such as those providing remote access to network devices and information systems, which lack automated monitoring capabilities, increase risk and make remote user access management difficult at best. Remote access is access to DoD nonpublic information systems by an authorized user (or an information system) communicating through an external, non-organization-controlled network. Remote access methods include, for example, dial-up, broadband, and wireless. Automated monitoring of remote access sessions allows organizations to detect cyber attacks and also ensure ongoing compliance with remote access policies by auditing connection activities of remote access capabilities, such as Remote Desktop Protocol (RDP), on a variety of information system components (e.g., servers, workstations, notebook computers, smartphones, and tablets).

Fix: F-56459r824839_fix

Configure TOSS to monitor all remote access methods by adding or updating the following lines to the "/etc/rsyslog.conf" file: auth.*;authpriv.*;daemon.* /var/log/secure The "rsyslog" service must be restarted for the changes to take effect. To restart the "rsyslog" service, run the following command: $ sudo systemctl restart rsyslog.service

b

TOSS must force a frequent session key renegotiation for SSH connections by the client.

RMF Control: AC-17
Severity: Medium
CCI: CCI-000068
Version: TOSS-04-040020
Vuln IDs: V-253057
Rule IDs: SV-253057r958408_rule

Without protection of the transmitted information, confidentiality and integrity may be compromised because unprotected communications can be intercepted and either read or altered. This requirement applies to both internal and external networks and all types of information system components from which information can be transmitted (e.g., servers, mobile devices, notebook computers, printers, copiers, scanners, and facsimile machines). Communication paths outside the physical protection of a controlled boundary are exposed to the possibility of interception and modification. Protecting the confidentiality and integrity of organizational information can be accomplished by physical means (e.g., employing physical distribution systems) or by logical means (e.g., employing cryptographic techniques). If physical means of protection are employed, then logical means (cryptography) do not have to be employed, and vice versa. Session key regeneration limits the chances of a session key becoming compromised.

Fix: F-56460r824842_fix

Configure the system to force a frequent session key renegotiation for SSH connections by the client by add or modifying the following line in the "/etc/ssh/ssh_config" file: RekeyLimit 1G 1h Restart the SSH daemon for the settings to take effect. $ sudo systemctl restart sshd.service

b

TOSS must force a frequent session key renegotiation for SSH connections to the server.

RMF Control: AC-17
Severity: Medium
CCI: CCI-000068
Version: TOSS-04-040030
Vuln IDs: V-253058
Rule IDs: SV-253058r958408_rule

Without protection of the transmitted information, confidentiality and integrity may be compromised because unprotected communications can be intercepted and either read or altered. This requirement applies to both internal and external networks and all types of information system components from which information can be transmitted (e.g., servers, mobile devices, notebook computers, printers, copiers, scanners, and facsimile machines). Communication paths outside the physical protection of a controlled boundary are exposed to the possibility of interception and modification. Protecting the confidentiality and integrity of organizational information can be accomplished by physical means (e.g., employing physical distribution systems) or by logical means (e.g., employing cryptographic techniques). If physical means of protection are employed, then logical means (cryptography) do not have to be employed, and vice versa. Session key regeneration limits the chances of a session key becoming compromised.

Fix: F-56461r824845_fix

Configure the system to force a frequent session key renegotiation for SSH connections to the server by add or modifying the following line in the "/etc/ssh/sshd_config" file: RekeyLimit 1G 1h Restart the SSH daemon for the settings to take effect. $ sudo systemctl restart sshd.service

c

TOSS must implement NIST FIPS-validated cryptography for the following: to provision digital signatures; to generate cryptographic hashes; and to protect unclassified information requiring confidentiality and cryptographic protection in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, and standards.

RMF Control: AC-17
Severity: High
CCI: CCI-000068
Version: TOSS-04-040040
Vuln IDs: V-253059
Rule IDs: SV-253059r958408_rule

Use of weak or untested encryption algorithms undermines the purposes of utilizing encryption to protect data. The operating system must implement cryptographic modules adhering to the higher standards approved by the federal government since this provides assurance they have been tested and validated. TOSS utilizes GRUB 2 as the default bootloader. Note that GRUB 2 command-line parameters are defined in the "kernelopts" variable of the /boot/grub2/grubenv file for all kernel boot entries. The command "fips-mode-setup" modifies the "kernelopts" variable, which in turn updates all kernel boot entries. The fips=1 kernel option needs to be added to the kernel command line during system installation so that key generation is done with FIPS-approved algorithms and continuous monitoring tests in place. Users must also ensure the system has plenty of entropy during the installation process by moving the mouse around, or if no mouse is available, ensuring that many keystrokes are typed. The recommended amount of keystrokes is 256 and more. Less than 256 keystrokes may generate a non-unique key. Satisfies: SRG-OS-000033-GPOS-00014, SRG-OS-000396-GPOS-00176, SRG-OS-000478-GPOS-00223

Fix: F-56462r824848_fix

Configure the operating system to implement DoD-approved encryption by following the steps below: To enable strict FIPS compliance, the fips=1 kernel option needs to be added to the kernel boot parameters during system installation so key generation is done with FIPS-approved algorithms and continuous monitoring tests in place. Enable FIPS mode after installation (not strict FIPS compliant) with the following command: $ sudo fips-mode-setup --enable Reboot the system for the changes to take effect.

b

TOSS must enforce password complexity by requiring that at least one uppercase character be used.

RMF Control
Severity: Medium
CCI: CCI-004066
Version: TOSS-04-040050
Vuln IDs: V-253060
Rule IDs: SV-253060r986589_rule

Use of a complex password helps to increase the time and resources required to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. Password complexity is one factor of several that determines how long it takes to crack a password. The more complex the password, the greater the number of possible combinations that need to be tested before the password is compromised. TOSS utilizes "pwquality" as a mechanism to enforce password complexity. Note that in order to require uppercase characters, without degrading the "minlen" value, the credit value must be expressed as a negative number in "/etc/security/pwquality.conf."

Fix: F-56463r824851_fix

Configure the operating system to enforce password complexity by requiring that at least one uppercase 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

b

TOSS must enforce password complexity by requiring that at least one lowercase character be used.

RMF Control
Severity: Medium
CCI: CCI-004066
Version: TOSS-04-040060
Vuln IDs: V-253061
Rule IDs: SV-253061r986591_rule

Use of a complex password helps to increase the time and resources required to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. Password complexity is one factor of several that determines how long it takes to crack a password. The more complex the password, the greater the number of possible combinations that need to be tested before the password is compromised. TOSS utilizes "pwquality" as a mechanism to enforce password complexity. Note that in order to require lowercase characters, without degrading the "minlen" value, the credit value must be expressed as a negative number in "/etc/security/pwquality.conf."

Fix: F-56464r986590_fix

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

b

TOSS must enforce password complexity by requiring that at least one numeric character be used.

RMF Control
Severity: Medium
CCI: CCI-004066
Version: TOSS-04-040070
Vuln IDs: V-253062
Rule IDs: SV-253062r986592_rule

Use of a complex password helps to increase the time and resources required to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. Password complexity is one factor of several that determines how long it takes to crack a password. The more complex the password, the greater the number of possible combinations that need to be tested before the password is compromised. TOSS utilizes "pwquality" as a mechanism to enforce password complexity. Note that in order to require numeric characters, without degrading the minlen value, the credit value must be expressed as a negative number in "/etc/security/pwquality.conf."

Fix: F-56465r824857_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

b

TOSS must require the change of at least eight characters when passwords are changed.

RMF Control
Severity: Medium
CCI: CCI-004066
Version: TOSS-04-040080
Vuln IDs: V-253063
Rule IDs: SV-253063r986593_rule

If the operating system allows the user to consecutively reuse extensive portions of passwords, this increases the chances of password compromise by increasing the window of opportunity for attempts at guessing and brute-force attacks. The number of changed characters refers to the number of changes required with respect to the total number of positions in the current password. In other words, characters may be the same within the two passwords; however, the positions of the like characters must be different. If the password length is an odd number then number of changed characters must be rounded up. For example, a password length of 15 characters must require the change of at least 8 characters. TOSS utilizes "pwquality" as a mechanism to enforce password complexity. The "difok" option sets the number of characters in a password that must not be present in the old password.

Fix: F-56466r824860_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

b

TOSS must store only encrypted representations of passwords.

RMF Control
Severity: Medium
CCI: CCI-004062
Version: TOSS-04-040090
Vuln IDs: V-253064
Rule IDs: SV-253064r986594_rule

Passwords need to be protected at all times, and encryption is the standard method for protecting passwords. If passwords are not encrypted, they can be plainly read (i.e., clear text) and easily compromised. Unapproved mechanisms that are used for authentication to the cryptographic module are not verified and therefore cannot be relied upon to provide confidentiality or integrity, and DOD data may be compromised. FIPS 140-2 is the current standard for validating that mechanisms used to access cryptographic modules utilize authentication that meets DOD requirements.

Fix: F-56467r824863_fix

Configure TOSS to encrypt all stored passwords. Edit/Modify the following line in the "/etc/login.defs" file and set "ENCRYPT_METHOD" to SHA512. ENCRYPT_METHOD SHA512

b

TOSS must not have the rsh-server package installed.

RMF Control: IA-5
Severity: Medium
CCI: CCI-000197
Version: TOSS-04-040100
Vuln IDs: V-253065
Rule IDs: SV-253065r987796_rule

Passwords need to be protected at all times, and encryption is the standard method for protecting passwords. If passwords are not encrypted, they can be plainly read (i.e., clear text) and easily compromised. The rsh-server service provides an unencrypted remote access service that does not provide for the confidentiality and integrity of user passwords or the remote session and has very weak authentication. Satisfies: SRG-OS-000074-GPOS-00042, SRG-OS-000095-GPOS-00049

Fix: F-56468r824866_fix

Configure the operating system to disable nonessential capabilities by removing the rsh-server package from the system with the following command: $ sudo yum remove rsh-server

b

TOSS must enforce 24 hours/one day as the minimum password lifetime.

RMF Control
Severity: Medium
CCI: CCI-004066
Version: TOSS-04-040110
Vuln IDs: V-253066
Rule IDs: SV-253066r986597_rule

Enforcing a minimum password lifetime helps to prevent repeated password changes to defeat the password reuse or history enforcement requirement. If users are allowed to immediately and continually change their password, then the password could be repeatedly changed in a short period of time to defeat the organization's policy regarding password reuse.

Fix: F-56469r986596_fix

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

b

TOSS must enforce a 60-day maximum password lifetime restriction.

RMF Control
Severity: Medium
CCI: CCI-004066
Version: TOSS-04-040120
Vuln IDs: V-253067
Rule IDs: SV-253067r986598_rule

Any password, no matter how complex, can eventually be cracked. Therefore, passwords need to be changed periodically. If the operating system does not limit the lifetime of passwords and force users to change their passwords, there is the risk that the operating system passwords could be compromised.

Fix: F-56470r824872_fix

Configure TOSS to enforce a 60-day maximum password lifetime. Add, or modify the following line in the "/etc/login.defs" file: PASS_MAX_DAYS 60

b

TOSS must enforce a minimum 15-character password length.

RMF Control
Severity: Medium
CCI: CCI-004066
Version: TOSS-04-040140
Vuln IDs: V-253069
Rule IDs: SV-253069r986599_rule

The shorter the password, the lower the number of possible combinations that need to be tested before the password is compromised. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. Password length is one factor of several that helps to determine strength and how long it takes to crack a password. Use of more characters in a password helps to exponentially increase the time and/or resources required to compromise the password.

Fix: F-56472r824878_fix

Configure TOSS 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

b

TOSS must disable IEEE 1394 (FireWire) Support.

RMF Control: CM-7
Severity: Medium
CCI: CCI-000381
Version: TOSS-04-040160
Vuln IDs: V-253071
Rule IDs: SV-253071r958478_rule

It is detrimental for operating systems to provide, or install by default, functionality exceeding requirements or mission objectives. These unnecessary capabilities or services are often overlooked and therefore may remain unsecured. They increase the risk to the platform by providing additional attack vectors. The IEEE 1394 (FireWire) is a serial bus standard for high-speed real-time communication. Disabling FireWire protects the system against exploitation of any flaws in its implementation.

Fix: F-56474r824884_fix

Configure the operating system to disable the ability to use the firewire-core kernel module. Add or update the following lines in the file "/etc/modprobe.d/blacklist.conf": install firewire-core /bin/false blacklist firewire-core Reboot the system for the settings to take effect.

b

TOSS must disable mounting of cramfs.

RMF Control: CM-7
Severity: Medium
CCI: CCI-000381
Version: TOSS-04-040170
Vuln IDs: V-253072
Rule IDs: SV-253072r958478_rule

It is detrimental for operating systems to provide, or install by default, functionality exceeding requirements or mission objectives. These unnecessary capabilities or services are often overlooked and therefore may remain unsecured. They increase the risk to the platform by providing additional attack vectors. Removing support for unneeded filesystem types reduces the local attack surface of the server. Compressed ROM/RAM file system (or cramfs) is a read-only file system designed for simplicity and space efficiency. It is mainly used in embedded and small footprint systems.

Fix: F-56475r824887_fix

Configure the operating system to disable the ability to use the cramfs kernel module. Add or update the following lines in the file "/etc/modprobe.d/blacklist.conf": install cramfs /bin/false blacklist cramfs Reboot the system for the settings to take effect.

b

TOSS must disable network management of the chrony daemon.

RMF Control: CM-7
Severity: Medium
CCI: CCI-000381
Version: TOSS-04-040180
Vuln IDs: V-253073
Rule IDs: SV-253073r958478_rule

Inaccurate time stamps make it more difficult to correlate events and can lead to an inaccurate analysis. Determining the correct time when a particular event occurred on a system is critical when conducting forensic analysis and investigating system events. Sources outside the configured acceptable allowance (drift) may be inaccurate. Not exposing the management interface of the chrony daemon on the network diminishes the attack space. TOSS utilizes the "timedatectl" command to view the status of the "systemd-timesyncd.service." The "timedatectl" status will display the local time, UTC, and the offset from UTC. Note that USNO offers authenticated NTP service to DoD and U.S. Government agencies operating on the NIPR and SIPR networks. Visit https://www.usno.navy.mil/USNO/time/ntp/dod-customers for more information.

Fix: F-56476r824890_fix

Configure the operating system disable network management of the chrony daemon by adding/modifying the following line in the /etc/chrony.conf file. cmdport 0

b

TOSS must disable the asynchronous transfer mode (ATM) protocol.

RMF Control: CM-7
Severity: Medium
CCI: CCI-000381
Version: TOSS-04-040190
Vuln IDs: V-253074
Rule IDs: SV-253074r958478_rule

It is detrimental for operating systems to provide, or install by default, functionality exceeding requirements or mission objectives. These unnecessary capabilities or services are often overlooked and therefore may remain unsecured. They increase the risk to the platform by providing additional attack vectors. Failing to disconnect unused protocols can result in a system compromise. The Asynchronous Transfer Mode (ATM) is a protocol operating on network, data link, and physical layers, based on virtual circuits and virtual paths. Disabling ATM protects the system against exploitation of any flaws in its implementation.

Fix: F-56477r824893_fix

Configure the operating system to disable the ability to use the ATM protocol kernel module. Add or update the following lines in the file "/etc/modprobe.d/blacklist.conf": install atm /bin/false blacklist atm Reboot the system for the settings to take effect.

b

TOSS must disable the controller area network (CAN) protocol.

RMF Control: CM-7
Severity: Medium
CCI: CCI-000381
Version: TOSS-04-040200
Vuln IDs: V-253075
Rule IDs: SV-253075r958478_rule

It is detrimental for operating systems to provide, or install by default, functionality exceeding requirements or mission objectives. These unnecessary capabilities or services are often overlooked and therefore may remain unsecured. They increase the risk to the platform by providing additional attack vectors. Failing to disconnect unused protocols can result in a system compromise. The Controller Area Network (CAN) is a serial communications protocol, which was initially developed for automotive and is now also used in marine, industrial, and medical applications. Disabling CAN protects the system against exploitation of any flaws in its implementation.

Fix: F-56478r824896_fix

Configure the operating system to disable the ability to use the CAN protocol kernel module. Add or update the following lines in the file "/etc/modprobe.d/blacklist.conf": install can /bin/false blacklist can Reboot the system for the settings to take effect.

b

TOSS must disable the stream control transmission (SCTP) protocol.

RMF Control: CM-7
Severity: Medium
CCI: CCI-000381
Version: TOSS-04-040210
Vuln IDs: V-253076
Rule IDs: SV-253076r958478_rule

It is detrimental for operating systems to provide, or install by default, functionality exceeding requirements or mission objectives. These unnecessary capabilities or services are often overlooked and therefore may remain unsecured. They increase the risk to the platform by providing additional attack vectors. Failing to disconnect unused protocols can result in a system compromise. The Stream Control Transmission Protocol (SCTP) is a transport layer protocol, designed to support the idea of message-oriented communication, with several streams of messages within one connection. Disabling SCTP protects the system against exploitation of any flaws in its implementation.

Fix: F-56479r824899_fix

Configure the operating system to disable the ability to use the SCTP protocol kernel module. Add or update the following lines in the file "/etc/modprobe.d/blacklist.conf": install sctp /bin/false blacklist sctp Reboot the system for the settings to take effect.

b

TOSS must disable the transparent inter-process communication (TIPC) protocol.

RMF Control: CM-7
Severity: Medium
CCI: CCI-000381
Version: TOSS-04-040220
Vuln IDs: V-253077
Rule IDs: SV-253077r958478_rule

It is detrimental for operating systems to provide, or install by default, functionality exceeding requirements or mission objectives. These unnecessary capabilities or services are often overlooked and therefore may remain unsecured. They increase the risk to the platform by providing additional attack vectors. Failing to disconnect unused protocols can result in a system compromise. The Transparent Inter-Process Communication (TIPC) protocol is designed to provide communications between nodes in a cluster. Disabling TIPC protects the system against exploitation of any flaws in its implementation.

Fix: F-56480r824902_fix

Configure the operating system to disable the ability to use the TIPC protocol kernel module. Add or update the following lines in the file "/etc/modprobe.d/blacklist.conf": install tipc /bin/false blacklist tipc Reboot the system for the settings to take effect.

b

TOSS must not have any automated bug reporting tools installed.

RMF Control: CM-7
Severity: Medium
CCI: CCI-000381
Version: TOSS-04-040230
Vuln IDs: V-253078
Rule IDs: SV-253078r958478_rule

It is detrimental for operating systems to provide, or install by default, functionality exceeding requirements or mission objectives. These unnecessary capabilities or services are often overlooked and therefore may remain unsecured. They increase the risk to the platform by providing additional attack vectors. Operating systems are capable of providing a wide variety of functions and services. Some of the functions and services, provided by default, may not be necessary to support essential organizational operations (e.g., key missions, functions). Examples of non-essential capabilities include, but are not limited to, games, software packages, tools, and demonstration software not related to requirements or providing a wide array of functionality not required for every mission, but which cannot be disabled. Verify the operating system is configured to disable non-essential capabilities. The most secure way of ensuring a non-essential capability is disabled is to not have the capability installed.

Fix: F-56481r824905_fix

Configure the operating system to disable nonessential capabilities by removing automated bug reporting packages from the system with the following command: $ sudo yum remove abrt*

b

TOSS must not have the sendmail package installed.

RMF Control: CM-7
Severity: Medium
CCI: CCI-000381
Version: TOSS-04-040250
Vuln IDs: V-253079
Rule IDs: SV-253079r958478_rule

It is detrimental for operating systems to provide, or install by default, functionality exceeding requirements or mission objectives. These unnecessary capabilities or services are often overlooked and therefore may remain unsecured. They increase the risk to the platform by providing additional attack vectors. Operating systems are capable of providing a wide variety of functions and services. Some of the functions and services, provided by default, may not be necessary to support essential organizational operations (e.g., key missions, functions). Examples of non-essential capabilities include, but are not limited to, games, software packages, tools, and demonstration software not related to requirements or providing a wide array of functionality not required for every mission, but which cannot be disabled. Verify the operating system is configured to disable non-essential capabilities. The most secure way of ensuring a non-essential capability is disabled is to not have the capability installed.

Fix: F-56482r824908_fix

Configure the operating system to disable non-essential capabilities by removing the sendmail package from the system with the following command: $ sudo yum remove sendmail

b

TOSS must not have the telnet-server package installed.

RMF Control: CM-7
Severity: Medium
CCI: CCI-000381
Version: TOSS-04-040260
Vuln IDs: V-253080
Rule IDs: SV-253080r958478_rule

It is detrimental for operating systems to provide, or install by default, functionality exceeding requirements or mission objectives. These unnecessary capabilities or services are often overlooked and therefore may remain unsecured. They increase the risk to the platform by providing additional attack vectors. Operating systems are capable of providing a wide variety of functions and services. Some of the functions and services, provided by default, may not be necessary to support essential organizational operations (e.g., key missions, functions). Examples of non-essential capabilities include, but are not limited to, games, software packages, tools, and demonstration software not related to requirements or providing a wide array of functionality not required for every mission, but which cannot be disabled. Verify the operating system is configured to disable non-essential capabilities. The most secure way of ensuring a non-essential capability is disabled is to not have the capability installed. The telnet service provides an unencrypted remote access service that does not provide for the confidentiality and integrity of user passwords or the remote session. If a privileged user were to log on using this service, the privileged user password could be compromised.

Fix: F-56483r824911_fix

Configure the operating system to disable non-essential capabilities by removing the telnet-server package from the system with the following command: $ sudo yum remove telnet-server

b

TOSS must be configured to disable USB mass storage.

RMF Control: IA-3
Severity: Medium
CCI: CCI-000778
Version: TOSS-04-040280
Vuln IDs: V-253082
Rule IDs: SV-253082r986606_rule

USB mass storage permits easy introduction of unknown devices, thereby facilitating malicious activity. Satisfies: SRG-OS-000114-GPOS-00059, SRG-OS-000378-GPOS-00163

Fix: F-56485r942858_fix

Configure the operating system to disable the ability to use the USB Storage kernel module. Create a file under "/etc/modprobe.d" with the following command: $ sudo touch /etc/modprobe.d/usb-storage.conf Add the following line to the created file: install usb-storage /bin/false Configure the operating system to disable the ability to use USB mass storage devices. $ sudo vi /etc/modprobe.d/blacklist.conf Add or update the line: blacklist usb-storage

b

TOSS must be configured so that all network connections associated with SSH traffic are terminated at the end of the session or after 10 minutes of inactivity, except to fulfill documented and validated mission requirements.

RMF Control: SC-10
Severity: Medium
CCI: CCI-001133
Version: TOSS-04-040290
Vuln IDs: V-253083
Rule IDs: SV-253083r986603_rule

Terminating an idle SSH session within a short time period reduces the window of opportunity for unauthorized personnel to take control of a management session enabled on the console or console port that has been left unattended. In addition, quickly terminating an idle SSH session will also free up resources committed by the managed network element. Terminating network connections associated with communications sessions includes, for example, de-allocating associated TCP/IP address/port pairs at the operating system level and deallocating networking assignments at the application level if multiple application sessions are using a single operating system-level network connection. This does not mean that the operating system terminates all sessions or network access; it only ends the inactive session and releases the resources associated with that session. TOSS utilizes /etc/ssh/sshd_config for configurations of OpenSSH. Within the sshd_config the product of the values of "ClientAliveInterval" and "ClientAliveCountMax" are used to establish the inactivity threshold. The "ClientAliveInterval" is a timeout interval in seconds after which if no data has been received from the client, sshd will send a message through the encrypted channel to request a response from the client. The "ClientAliveCountMax" is the number of client alive messages that may be sent without sshd receiving any messages back from the client. If this threshold is met, sshd will disconnect the client. The default setting for "ClientAliveCountMax" is "3." If "ClientAliveInterval is set to "15" and "ClientAliveCountMax" is left at the default, unresponsive SSH clients will be disconnected after approximately 45 seconds. Satisfies: SRG-OS-000126-GPOS-00066, SRG-OS-000163-GPOS-00072, SRG-OS-000279-GPOS-00109

Fix: F-56486r986602_fix

Configure TOSS to automatically terminate all network connections associated with SSH traffic at the end of a session or after 10 minutes of inactivity, or as long as documented with the information system security officer (ISSO) as an operational requirement. Modify or append the following lines in the "/etc/ssh/sshd_config" file to have a product value of "600" or less: ClientAliveInterval 600 ClientAliveCountMax 1 In order for the changes to take effect, the SSH daemon must be restarted. $ sudo systemctl restart sshd.service

a

TOSS must have policycoreutils package installed.

RMF Control: SC-3
Severity: Low
CCI: CCI-001084
Version: TOSS-04-040310
Vuln IDs: V-253084
Rule IDs: SV-253084r958518_rule

Without verification of the security functions, security functions may not operate correctly and the failure may go unnoticed. Security function is defined as the hardware, software, and/or firmware of the information system responsible for enforcing the system security policy and supporting the isolation of code and data on which the protection is based. Security functionality includes, but is not limited to, establishing system accounts, configuring access authorizations (i.e., permissions, privileges), setting events to be audited, and setting intrusion detection parameters. Policycoreutils contains the policy core utilities that are required for basic operation of an SELinux-enabled system. These utilities include load_policy to load SELinux policies, setfile to label filesystems, newrole to switch roles, and run_init to run /etc/init.d scripts in the proper context.

Fix: F-56487r824923_fix

Configure the operating system to have the policycoreutils package installed with the following command: $ sudo yum install policycoreutils

b

TOSS must enforce password complexity by requiring that at least one special character be used.

RMF Control
Severity: Medium
CCI: CCI-004066
Version: TOSS-04-040350
Vuln IDs: V-253087
Rule IDs: SV-253087r991561_rule

Use of a complex password helps to increase the time and resources required to compromise the password. Password complexity or strength is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. TOSS utilizes "pwquality" as a mechanism to enforce password complexity. Note that to require special characters without degrading the "minlen" value, the credit value must be expressed as a negative number in "/etc/security/pwquality.conf."

Fix: F-56490r824932_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

b

A firewall must be installed on TOSS.

RMF Control: AC-17
Severity: Medium
CCI: CCI-002314
Version: TOSS-04-040370
Vuln IDs: V-253088
Rule IDs: SV-253088r958672_rule

"Firewalld" provides an easy and effective way to block/limit remote access to the system via ports, services, and protocols. Remote access services, such as those providing remote access to network devices and information systems, which lack automated control capabilities, increase risk and make remote user access management difficult at best. Remote access is access to DoD nonpublic information systems by an authorized user (or an information system) communicating through an external, non-organization-controlled network. Remote access methods include, for example, dial-up, broadband, and wireless. TOSS functionality (e.g., SSH) must be capable of taking enforcement action if the audit reveals unauthorized activity. Automated control of remote access sessions allows organizations to ensure ongoing compliance with remote access policies by enforcing connection rules of remote access applications on a variety of information system components (e.g., servers, workstations, notebook computers, smartphones, and tablets).

Fix: F-56491r824935_fix

Install "firewalld" and enable with the following commands: $ sudo yum install firewalld.noarch $ sudo systemctl enable firewalld

b

TOSS must take appropriate action when the internal event queue is full.

RMF Control: AU-4
Severity: Medium
CCI: CCI-001851
Version: TOSS-04-040390
Vuln IDs: V-253089
Rule IDs: SV-253089r958754_rule

Information stored in one location is vulnerable to accidental or incidental deletion or alteration. Offloading is a common process in information systems with limited audit storage capacity. TOSS installation media provides "rsyslogd." "rsyslogd" is a system utility providing support for message logging. Support for both internet and UNIX domain sockets enables this utility to support both local and remote logging. Couple this utility with "gnutls" (which is a secure communications library implementing the SSL, TLS, and DTLS protocols), and now there is a method to securely encrypt and offload auditing.

Fix: F-56492r824938_fix

Edit the /etc/audit/auditd.conf file and add or update the "overflow_action" option to one of "syslog", "single", or "halt": overflow_action = syslog The audit daemon must be restarted for changes to take effect.

b

A firewall must be able to protect against or limit the effects of Denial of Service (DoS) attacks by ensuring TOSS can implement rate-limiting measures on impacted network interfaces.

RMF Control: SC-5
Severity: Medium
CCI: CCI-002385
Version: TOSS-04-040480
Vuln IDs: V-253092
Rule IDs: SV-253092r958902_rule

DoS is a condition when a resource is not available for legitimate users. When this occurs, the organization either cannot accomplish its mission or must operate at degraded capacity. This requirement addresses the configuration of TOSS to mitigate the impact of DoS attacks that have occurred or are ongoing on system availability. For each system, known and potential DoS attacks must be identified and solutions for each type implemented. A variety of technologies exists to limit or, in some cases, eliminate the effects of DoS attacks (e.g., limiting processes or establishing memory partitions). Employing increased capacity and bandwidth, combined with service redundancy, may reduce the susceptibility to some DoS attacks. Since version 0.6.0, "firewalld" has incorporated "nftables" as its backend support. Utilizing the limit statement in "nftables" can help to mitigate DoS attacks.

Fix: F-56495r824947_fix

Configure "nftables" to be the default "firewallbackend" for "firewalld" by adding or editing the following line in "/etc/firewalld/firewalld.conf": FirewallBackend=nftables Establish rate-limiting rules based on organization-defined types of DoS attacks on impacted network interfaces.

a

YUM must remove all software components after updated versions have been installed on TOSS.

RMF Control: SI-2
Severity: Low
CCI: CCI-002617
Version: TOSS-04-040500
Vuln IDs: V-253094
Rule IDs: SV-253094r958936_rule

Previous versions of software components that are not removed from the information system after updates have been installed may be exploited by adversaries. Some information technology products may remove older versions of software automatically from the information system.

Fix: F-56497r824953_fix

Configure the operating system to remove all software components after updated versions have been installed. Set the "clean_requirements_on_remove" option to "True" in the "/etc/dnf/dnf.conf" file: clean_requirements_on_remove=True

b

TOSS must enable the "SELinux" targeted policy.

RMF Control: SI-6
Severity: Medium
CCI: CCI-002696
Version: TOSS-04-040510
Vuln IDs: V-253095
Rule IDs: SV-253095r958944_rule

Without verification of the security functions, security functions may not operate correctly and the failure may go unnoticed. Security function is defined as the hardware, software, and/or firmware of the information system responsible for enforcing the system security policy and supporting the isolation of code and data on which the protection is based. Security functionality includes, but is not limited to, establishing system accounts, configuring access authorizations (i.e., permissions, privileges), setting events to be audited, and setting intrusion detection parameters. This requirement applies to operating systems performing security function verification/testing and/or systems and environments that require this functionality.

Fix: F-56498r824956_fix

Configure the operating system to verify correct operation of all security functions. Set the "SELinuxtype" to the "targeted" policy by modifying the "/etc/selinux/config" file to have the following line: SELINUXTYPE=targeted A reboot is required for the changes to take effect.

b

TOSS must prevent the use of dictionary words for passwords.

RMF Control: CM-6
Severity: Medium
CCI: CCI-000366
Version: TOSS-04-040540
Vuln IDs: V-253096
Rule IDs: SV-253096r991587_rule

If TOSS allows the user to select passwords based on dictionary words, then this increases the chances of password compromise by increasing the opportunity for successful guesses and brute-force attacks.

Fix: F-56499r824959_fix

Configure TOSS to prevent the use of dictionary words for passwords. Add or update the following line in the "/etc/security/pwquality.conf" file or a configuration file in the /etc/pwquality.conf.d/ directory to contain the "dictcheck" parameter: dictcheck=1

b

TOSS must enforce a delay of at least four seconds between logon prompts following a failed logon attempt.

RMF Control: CM-6
Severity: Medium
CCI: CCI-000366
Version: TOSS-04-040550
Vuln IDs: V-253097
Rule IDs: SV-253097r991588_rule

Limiting the number of logon attempts over a certain time interval reduces the chances that an unauthorized user may gain access to an account.

Fix: F-56500r824962_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

c

A File Transfer Protocol (FTP) server package must not be installed unless mission essential on TOSS.

RMF Control: CM-6
Severity: High
CCI: CCI-000366
Version: TOSS-04-040560
Vuln IDs: V-253098
Rule IDs: SV-253098r991589_rule

The FTP service provides an unencrypted remote access that does not provide for the confidentiality and integrity of user passwords or the remote session. If a privileged user were to log on using this service, the privileged user password could be compromised. SSH or other encrypted file transfer methods must be used in place of this service.

Fix: F-56501r824965_fix

Document the FTP server package with the ISSO as an operational requirement or remove it from the system with the following command: $ sudo yum remove vsftpd

b

If the Trivial File Transfer Protocol (TFTP) server is required, the TOSS TFTP daemon must be configured to operate in secure mode.

RMF Control: CM-6
Severity: Medium
CCI: CCI-000366
Version: TOSS-04-040600
Vuln IDs: V-253102
Rule IDs: SV-253102r991589_rule

Restricting TFTP to a specific directory prevents remote users from copying, transferring, or overwriting system files.

Fix: F-56505r824977_fix

Configure the TFTP daemon to operate in secure mode by adding the following line to "/etc/xinetd.d/tftp" (or modify the line to have the required value): server_args = -s /var/lib/tftpboot

b

The TOSS SSH daemon must perform strict mode checking of home directory configuration files.

RMF Control: CM-6
Severity: Medium
CCI: CCI-000366
Version: TOSS-04-040650
Vuln IDs: V-253106
Rule IDs: SV-253106r991589_rule

If other users have access to modify user-specific SSH configuration files, they may be able to log on to the system as another user.

Fix: F-56509r824989_fix

Configure SSH to perform strict mode checking of home directory configuration files. Uncomment the "StrictModes" keyword in "/etc/ssh/sshd_config" and set the value to "yes": StrictModes yes The SSH daemon must be restarted for the changes to take effect. To restart the SSH daemon, run the following command: $ sudo systemctl restart sshd.service

b

The TOSS SSH private host key files must have mode 0600 or less permissive.

RMF Control: CM-6
Severity: Medium
CCI: CCI-000366
Version: TOSS-04-040660
Vuln IDs: V-253107
Rule IDs: SV-253107r991589_rule

If an unauthorized user obtains the private SSH host key file, the host could be impersonated.

Fix: F-56510r824992_fix

Configure the mode of SSH private host key files under "/etc/ssh" to "0600" with the following command: $ sudo chmod 0600 /etc/ssh/ssh_host*key The SSH daemon must be restarted for the changes to take effect. To restart the SSH daemon, run the following command: $ sudo systemctl restart sshd.service

b

The TOSS SSH public host key files must have mode 0644 or less permissive.

RMF Control: CM-6
Severity: Medium
CCI: CCI-000366
Version: TOSS-04-040670
Vuln IDs: V-253108
Rule IDs: SV-253108r991589_rule

If a public host key file is modified by an unauthorized user, the SSH service may be compromised.

Fix: F-56511r824995_fix

Change the mode of public host key files under "/etc/ssh" to "0644" with the following command: $ sudo chmod 0644 /etc/ssh/*key.pub The SSH daemon must be restarted for the changes to take effect. To restart the SSH daemon, run the following command: $ sudo systemctl restart sshd.service

c

TOSS must be a vendor-supported release.

RMF Control: CM-6
Severity: High
CCI: CCI-000366
Version: TOSS-04-040690
Vuln IDs: V-253110
Rule IDs: SV-253110r991589_rule

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

Fix: F-56513r825001_fix

Upgrade to a supported version of TOSS.

b

TOSS must be configured to prevent unrestricted mail relaying.

RMF Control: CM-6
Severity: Medium
CCI: CCI-000366
Version: TOSS-04-040700
Vuln IDs: V-253111
Rule IDs: SV-253111r991589_rule

If unrestricted mail relaying is permitted, unauthorized senders could use this host as a mail relay for the purpose of sending spam or other unauthorized activity.

Fix: F-56514r825004_fix

If "postfix" is installed, modify the "/etc/postfix/main.cf" file to restrict client connections to the local network with the following command: $ sudo postconf -e 'smtpd_client_restrictions = permit_mynetworks,reject'

b

TOSS must define default permissions for logon and non-logon shells.

RMF Control: CM-6
Severity: Medium
CCI: CCI-000366
Version: TOSS-04-040710
Vuln IDs: V-253112
Rule IDs: SV-253112r991589_rule

The umask controls the default access mode assigned to newly created files. A umask of 077 limits new files to mode 600 or less permissive. Although umask can be represented as a four-digit number, the first digit representing special access modes is typically ignored or required to be "0." This requirement applies to the globally configured system defaults and the local interactive user defaults for each account on the system.

Fix: F-56515r825007_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 lines for the "UMASK" parameter in the "/etc/bashrc" and "etc/csh.cshrc" files to "077": UMASK 077

b

TOSS must disable access to network bpf syscall from unprivileged processes.

RMF Control: CM-6
Severity: Medium
CCI: CCI-000366
Version: TOSS-04-040720
Vuln IDs: V-253113
Rule IDs: SV-253113r991589_rule

It is detrimental for operating systems to provide, or install by default, functionality exceeding requirements or mission objectives. These unnecessary capabilities or services are often overlooked and therefore may remain unsecured. They increase the risk to the platform by providing additional attack vectors.

Fix: F-56516r825010_fix

Configure TOSS to prevent privilege escalation thru the kernel by disabling access to the bpf syscall by adding the following line to a file in the "/etc/sysctl.d" directory: kernel.unprivileged_bpf_disabled = 1 The system configuration files need to be reloaded for the changes to take effect. To reload the contents of the files, run the following command: $ sudo sysctl --system

b

TOSS must enable hardening for the Berkeley Packet Filter Just-in-time compiler.

RMF Control: CM-6
Severity: Medium
CCI: CCI-000366
Version: TOSS-04-040730
Vuln IDs: V-253114
Rule IDs: SV-253114r991589_rule

It is detrimental for operating systems to provide, or install by default, functionality exceeding requirements or mission objectives. These unnecessary capabilities or services are often overlooked and therefore may remain unsecured. They increase the risk to the platform by providing additional attack vectors. Enabling hardening for the Berkeley Packet Filter (BPF) Just-in-time (JIT) compiler aids in mitigating JIT spraying attacks. Setting the value to "2" enables JIT hardening for all users.

Fix: F-56517r825013_fix

Configure TOSS to enable hardening for the BPF JIT compiler by adding the following line to a file in the "/etc/sysctl.d" directory: net.core.bpf_jit_harden = 2 The system configuration files need to be reloaded for the changes to take effect. To reload the contents of the files, run the following command: $ sudo sysctl --system

a

TOSS must ensure the SSH server uses strong entropy.

RMF Control: CM-6
Severity: Low
CCI: CCI-000366
Version: TOSS-04-040750
Vuln IDs: V-253116
Rule IDs: SV-253116r991589_rule

The most important characteristic of a random number generator is its randomness, namely its ability to deliver random numbers that are impossible to predict. Entropy in computer security is associated with the unpredictability of a source of randomness. The random source with high entropy tends to achieve a uniform distribution of random values. Random number generators are one of the most important building blocks of cryptosystems. The SSH implementation in TOSS uses the OPENSSL library, which does not use high-entropy sources by default. By using the SSH_USE_STRONG_RNG environment variable the OPENSSL random generator is reseeded from /dev/random. This setting is not recommended on computers without the hardware random generator because insufficient entropy causes the connection to be blocked until enough entropy is available.

Fix: F-56519r825019_fix

Configure the operating system SSH server to use strong entropy. Add or modify the following line in the "/etc/sysconfig/sshd" file. SSH_USE_STRONG_RNG=32 The SSH service must be restarted for changes to take effect.

a

TOSS must have the packages required to use the hardware random number generator entropy gatherer service.

RMF Control: CM-6
Severity: Low
CCI: CCI-000366
Version: TOSS-04-040760
Vuln IDs: V-253117
Rule IDs: SV-253117r991589_rule

The most important characteristic of a random number generator is its randomness, namely its ability to deliver random numbers that are impossible to predict. Entropy in computer security is associated with the unpredictability of a source of randomness. The random source with high entropy tends to achieve a uniform distribution of random values. Random number generators are one of the most important building blocks of cryptosystems. The rngd service feeds random data from hardware device to kernel random device. Quality (non-predictable) random number generation is important for several security functions (i.e., ciphers).

Fix: F-56520r825022_fix

Install the packages required to enable the hardware random number generator entropy gatherer service with the following command: $ sudo yum install rng-tools

b

TOSS must ignore IPv4 Internet Control Message Protocol (ICMP) redirect messages.

RMF Control: CM-6
Severity: Medium
CCI: CCI-000366
Version: TOSS-04-040770
Vuln IDs: V-253118
Rule IDs: SV-253118r991589_rule

ICMP redirect messages are used by routers to inform hosts that a more direct route exists for a particular destination. These messages modify the host's route table and are unauthenticated. An illicit ICMP redirect message could result in a man-in-the-middle attack.

Fix: F-56521r825025_fix

Configure TOSS to ignore IPv4 ICMP redirect messages with the following command: $ sudo sysctl -w net.ipv4.conf.all.accept_redirects=0 If "0" is not the system's default value then add or update the following line in the appropriate file under "/etc/sysctl.d": net.ipv4.conf.all.accept_redirects = 0

b

TOSS must not accept router advertisements on all IPv6 interfaces by default.

RMF Control: CM-6
Severity: Medium
CCI: CCI-000366
Version: TOSS-04-040790
Vuln IDs: V-253120
Rule IDs: SV-253120r991589_rule

Routing protocol daemons are typically used on routers to exchange network topology information with other routers. If this software is used when not required, system network information may be unnecessarily transmitted across the network. An illicit router advertisement message could result in a man-in-the-middle attack.

Fix: F-56523r825031_fix

Configure TOSS to not accept router advertisements on all IPv6 interfaces by default unless the system is a router with the following commands: $ sudo sysctl -w net.ipv6.conf.default.accept_ra=0 If "0" is not the system's default value then add or update the following lines in the appropriate file under "/etc/sysctl.d": net.ipv6.conf.default.accept_ra=0

b

TOSS must not accept router advertisements on all IPv6 interfaces.

RMF Control: CM-6
Severity: Medium
CCI: CCI-000366
Version: TOSS-04-040800
Vuln IDs: V-253121
Rule IDs: SV-253121r991589_rule

Routing protocol daemons are typically used on routers to exchange network topology information with other routers. If this software is used when not required, system network information may be unnecessarily transmitted across the network. An illicit router advertisement message could result in a man-in-the-middle attack.

Fix: F-56524r825034_fix

Configure TOSS to not accept router advertisements on all IPv6 interfaces unless the system is a router with the following commands: $ sudo sysctl -w net.ipv6.conf.all.accept_ra=0 If "0" is not the system's default value then add or update the following lines in the appropriate file under "/etc/sysctl.d": net.ipv6.conf.all.accept_ra=0

c

TOSS must not allow blank or null passwords in the password-auth file.

RMF Control: CM-6
Severity: High
CCI: CCI-000366
Version: TOSS-04-040810
Vuln IDs: V-253122
Rule IDs: SV-253122r991589_rule

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

Fix: F-56525r825037_fix

Remove any instances of the "nullok" option in the "/etc/pam.d/password-auth" file to prevent logons with empty passwords. Note: Manual changes to the listed file may be overwritten by the "authselect" program.

b

TOSS must not forward IPv4 source-routed packets by default.

RMF Control: CM-6
Severity: Medium
CCI: CCI-000366
Version: TOSS-04-040830
Vuln IDs: V-253124
Rule IDs: SV-253124r991589_rule

Source-routed packets allow the source of the packet to suggest that routers forward the packet along a different path than configured on the router, which can be used to bypass network security measures. This requirement applies only to the forwarding of source-routed traffic, such as when forwarding is enabled and the system is functioning as a router.

Fix: F-56527r825043_fix

Configure TOSS to not forward IPv4 source-routed packets by default with the following command: $ sudo sysctl -w net.ipv4.conf.default.accept_source_route=0 If "0" is not the system's default value then add or update the following line in the appropriate file under "/etc/sysctl.d": net.ipv4.conf.default.accept_source_route=0

b

TOSS must not forward IPv4 source-routed packets.

RMF Control: CM-6
Severity: Medium
CCI: CCI-000366
Version: TOSS-04-040840
Vuln IDs: V-253125
Rule IDs: SV-253125r991589_rule

Source-routed packets allow the source of the packet to suggest that routers forward the packet along a different path than configured on the router, which can be used to bypass network security measures. This requirement applies only to the forwarding of source-routed traffic, such as when forwarding is enabled and the system is functioning as a router.

Fix: F-56528r825046_fix

Configure TOSS to not forward IPv4 source-routed packets with the following command: $ sudo sysctl -w net.ipv4.conf.all.accept_source_route=0 If "0" is not the system's all value then add or update the following line in the appropriate file under "/etc/sysctl.d": net.ipv4.conf.all.accept_source_route=0

b

TOSS must not forward IPv6 source-routed packets.

RMF Control: CM-6
Severity: Medium
CCI: CCI-000366
Version: TOSS-04-040860
Vuln IDs: V-253127
Rule IDs: SV-253127r991589_rule

Source-routed packets allow the source of the packet to suggest that routers forward the packet along a different path than configured on the router, which can be used to bypass network security measures. This requirement applies only to the forwarding of source-routed traffic, such as when forwarding is enabled and the system is functioning as a router.

Fix: F-56530r825052_fix

Configure TOSS to not forward IPv6 source-routed packets with the following command: $ sudo sysctl -w net.ipv6.conf.all.accept_source_route=0 If "0" is not the system's all value then add or update the following line in the appropriate file under "/etc/sysctl.d": net.ipv6.conf.all.accept_source_route=0

b

TOSS must not respond to Internet Control Message Protocol (ICMP) echoes sent to a broadcast address.

RMF Control: CM-6
Severity: Medium
CCI: CCI-000366
Version: TOSS-04-040870
Vuln IDs: V-253128
Rule IDs: SV-253128r991589_rule

Responding to broadcast ICMP echoes facilitates network mapping and provides a vector for amplification attacks. There are notable differences between Internet Protocol version 4 (IPv4) and Internet Protocol version 6 (IPv6). IPv6 does not implement the same method of broadcast as IPv4. Instead, IPv6 uses multicast addressing to the all-hosts multicast group. Refer to RFC4294 for an explanation of "IPv6 Node Requirements", which resulted in this difference between IPv4 and IPv6.

Fix: F-56531r825055_fix

Configure TOSS to not respond to IPv4 ICMP echoes sent to a broadcast address with the following command: $ sudo sysctl -w net.ipv4.icmp_echo_ignore_broadcasts=1 If "1" is not the system's default value then add or update the following line in the appropriate file under "/etc/sysctl.d": net.ipv4.icmp_echo_ignore_broadcasts=1

b

TOSS must prevent IPv4 Internet Control Message Protocol (ICMP) redirect messages from being accepted.

RMF Control: CM-6
Severity: Medium
CCI: CCI-000366
Version: TOSS-04-040890
Vuln IDs: V-253130
Rule IDs: SV-253130r991589_rule

ICMP redirect messages are used by routers to inform hosts that a more direct route exists for a particular destination. These messages modify the host's route table and are unauthenticated. An illicit ICMP redirect message could result in a man-in-the-middle attack.

Fix: F-56533r825061_fix

Configure TOSS to prevent IPv4 ICMP redirect messages from being accepted with the following command: $ sudo sysctl -w net.ipv4.conf.default.accept_redirects=0 If "0" is not the system's default value then add or update the following line in the appropriate file under "/etc/sysctl.d": net.ipv4.conf.default.accept_redirects=0

b

TOSS must prevent IPv6 Internet Control Message Protocol (ICMP) redirect messages from being accepted.

RMF Control: CM-6
Severity: Medium
CCI: CCI-000366
Version: TOSS-04-040900
Vuln IDs: V-253131
Rule IDs: SV-253131r991589_rule

ICMP redirect messages are used by routers to inform hosts that a more direct route exists for a particular destination. These messages modify the host's route table and are unauthenticated. An illicit ICMP redirect message could result in a man-in-the-middle attack.

Fix: F-56534r825064_fix

Configure TOSS to prevent IPv6 ICMP redirect messages from being accepted with the following command: $ sudo sysctl -w net.ipv6.conf.default.accept_redirects=0 If "0" is not the system's default value then add or update the following line in the appropriate file under "/etc/sysctl.d": net.ipv6.conf.default.accept_redirects=0

b

TOSS must restrict privilege elevation to authorized personnel.

RMF Control: CM-6
Severity: Medium
CCI: CCI-000366
Version: TOSS-04-040920
Vuln IDs: V-253133
Rule IDs: SV-253133r991589_rule

The sudo command allows a user to execute programs with elevated (administrator) privileges. It prompts the user for their password and confirms the request to execute a command by checking a file, called sudoers. If the "sudoers" file is not configured correctly, any user defined on the system can initiate privileged actions on the target system.

Fix: F-56536r825070_fix

Remove the following entries from the sudoers file: ALL ALL=(ALL) ALL ALL ALL=(ALL:ALL) ALL

b

TOSS must use reverse path filtering on all IPv4 interfaces.

RMF Control: CM-6
Severity: Medium
CCI: CCI-000366
Version: TOSS-04-040930
Vuln IDs: V-253134
Rule IDs: SV-253134r991589_rule

It is detrimental for operating systems to provide, or install by default, functionality exceeding requirements or mission objectives. These unnecessary capabilities or services are often overlooked and therefore may remain unsecured. They increase the risk to the platform by providing additional attack vectors. Enabling reverse path filtering drops packets with source addresses that are not routable. There is not an equivalent filter for IPv6 traffic.

Fix: F-56537r825073_fix

Configure TOSS to use reverse path filtering on all IPv4 interfaces by adding the following line to a file in the "/etc/sysctl.d" directory: net.ipv4.conf.all.rp_filter = 1 The system configuration files need to be reloaded for the changes to take effect. To reload the contents of the files, run the following command: $ sudo sysctl --system

b

TOSS must enable kernel parameters to enforce discretionary access control on symlinks.

RMF Control: AC-3
Severity: Medium
CCI: CCI-002165
Version: TOSS-04-040950
Vuln IDs: V-253136
Rule IDs: SV-253136r958702_rule

Discretionary Access Control (DAC) is based on the notion that individual users are "owners" of objects and therefore have discretion over who should be authorized to access the object and in which mode (e.g., read or write). Ownership is usually acquired as a consequence of creating the object or via specified ownership assignment. DAC allows the owner to determine who will have access to objects they control. An example of DAC includes user-controlled file permissions. When discretionary access control policies are implemented, subjects are not constrained with regard to what actions they can take with information for which they have already been granted access. Thus, subjects that have been granted access to information are not prevented from passing (i.e., the subjects have the discretion to pass) the information to other subjects or objects. A subject that is constrained in its operation by Mandatory Access Control policies is still able to operate under the less rigorous constraints of this requirement. Thus, while Mandatory Access Control imposes constraints preventing a subject from passing information to another subject operating at a different sensitivity level, this requirement permits the subject to pass the information to any subject at the same sensitivity level. The policy is bounded by the information system boundary. Once the information is passed outside the control of the information system, additional means may be required to ensure the constraints remain in effect. While the older, more traditional definitions of discretionary access control require identity-based access control, that limitation is not required for this use of discretionary access control. By enabling the fs.protected_symlinks kernel parameter, symbolic links are permitted to be followed only when outside a sticky world-writable directory, or when the UID of the link and follower match, or when the directory owner matches the symlink's owner. Disallowing such symlinks helps mitigate vulnerabilities based on insecure file system accessed by privileged programs, avoiding an exploitation vector exploiting unsafe use of open() or creat(). Satisfies: SRG-OS-000312-GPOS-00122, SRG-OS-000324-GPOS-00125

Fix: F-56539r825079_fix

Configure the operating system to enable DAC on symlinks. Add or edit the following line in a system configuration file, in the "/etc/sysctl.d/" directory: fs.protected_symlinks = 1 Load settings from all system configuration files with the following command: $ sudo sysctl --system

b

TOSS must enable kernel parameters to enforce discretionary access control on hardlinks.

RMF Control: AC-3
Severity: Medium
CCI: CCI-002165
Version: TOSS-04-040960
Vuln IDs: V-253137
Rule IDs: SV-253137r958702_rule

Discretionary Access Control (DAC) is based on the notion that individual users are "owners" of objects and therefore have discretion over who should be authorized to access the object and in which mode (e.g., read or write). Ownership is usually acquired as a consequence of creating the object or via specified ownership assignment. DAC allows the owner to determine who will have access to objects they control. An example of DAC includes user-controlled file permissions. When discretionary access control policies are implemented, subjects are not constrained with regard to what actions they can take with information for which they have already been granted access. Thus, subjects that have been granted access to information are not prevented from passing (i.e., the subjects have the discretion to pass) the information to other subjects or objects. A subject that is constrained in its operation by Mandatory Access Control policies is still able to operate under the less rigorous constraints of this requirement. Thus, while Mandatory Access Control imposes constraints preventing a subject from passing information to another subject operating at a different sensitivity level, this requirement permits the subject to pass the information to any subject at the same sensitivity level. The policy is bounded by the information system boundary. Once the information is passed outside the control of the information system, additional means may be required to ensure the constraints remain in effect. While the older, more traditional definitions of discretionary access control require identity-based access control, that limitation is not required for this use of discretionary access control. By enabling the fs.protected_hardlinks kernel parameter, users can no longer create soft or hard links to files they do not own. Disallowing such hardlinks mitigate vulnerabilities based on insecure file system accessed by privileged programs, avoiding an exploitation vector exploiting unsafe use of open() or creat(). Satisfies: SRG-OS-000312-GPOS-00122, SRG-OS-000324-GPOS-00125

Fix: F-56540r825082_fix

Configure the operating system to enable DAC on hardlinks. Add or edit the following line in a system configuration file, in the "/etc/sysctl.d/" directory: fs.protected_hardlinks = 1 Load settings from all system configuration files with the following command: $ sudo sysctl --system