From 6599674681b2635fae04bde219f4c10aaedf6fea Mon Sep 17 00:00:00 2001 From: Matthew Burket Date: Wed, 4 Sep 2024 11:22:18 -0500 Subject: [PATCH] Move vuln_discussion to vuldiscussion --- .../policy/stig/shared.yml | 7 +--- .../policy/stig/shared.yml | 7 +--- .../policy/stig/shared.yml | 14 ++------ .../policy/stig/shared.yml | 14 ++------ .../policy/stig/shared.yml | 10 +----- .../policy/stig/shared.yml | 14 ++------ .../policy/stig/shared.yml | 14 ++------ .../policy/stig/shared.yml | 14 ++------ .../policy/stig/shared.yml | 14 ++------ .../policy/stig/shared.yml | 4 +-- .../policy/stig/shared.yml | 4 +-- .../policy/stig/shared.yml | 4 +-- .../policy/stig/shared.yml | 2 -- .../policy/stig/shared.yml | 2 -- .../policy/stig/shared.yml | 2 -- .../policy/stig/shared.yml | 2 -- .../policy/stig/shared.yml | 14 ++------ .../policy/stig/shared.yml | 14 ++------ .../policy/stig/shared.yml | 14 ++------ .../policy/stig/shared.yml | 14 ++------ .../policy/stig/shared.yml | 12 ++----- .../policy/stig/shared.yml | 14 +++----- .../policy/stig/shared.yml | 12 ++----- .../policy/stig/shared.yml | 14 ++------ .../policy/stig/shared.yml | 14 ++------ .../policy/stig/shared.yml | 14 ++------ .../policy/stig/shared.yml | 14 ++------ .../policy/stig/shared.yml | 14 ++------ .../policy/stig/shared.yml | 14 ++------ .../policy/stig/shared.yml | 14 ++------ .../policy/stig/shared.yml | 14 ++------ .../policy/stig/shared.yml | 14 ++------ .../policy/stig/shared.yml | 14 ++------ .../policy/stig/shared.yml | 14 ++------ .../policy/stig/shared.yml | 14 ++------ .../policy/stig/shared.yml | 14 ++------ .../policy/stig/shared.yml | 14 ++------ .../policy/stig/shared.yml | 8 +---- .../policy/stig/shared.yml | 2 -- .../policy/stig/shared.yml | 8 +---- .../policy/stig/shared.yml | 8 +---- .../policy/stig/shared.yml | 9 +---- .../policy/stig/shared.yml | 9 ++--- .../policy/stig/shared.yml | 6 +--- .../policy/stig/shared.yml | 6 +--- .../policy/stig/shared.yml | 6 +--- .../policy/stig/shared.yml | 6 +--- .../policy/stig/shared.yml | 6 +--- .../policy/stig/shared.yml | 2 -- .../policy/stig/shared.yml | 2 -- .../policy/stig/shared.yml | 4 --- .../policy/stig/shared.yml | 4 --- .../policy/stig/shared.yml | 2 -- .../policy/stig/shared.yml | 4 --- .../auditd_log_format/policy/stig/shared.yml | 8 +---- .../policy/stig/shared.yml | 9 ++--- .../auditd_write_logs/policy/stig/shared.yml | 5 +-- .../policy/stig/shared.yml | 4 --- .../policy/stig/shared.yml | 10 +----- .../policy/stig/shared.yml | 6 +--- .../policy/stig/shared.yml | 6 ---- .../policy/stig/shared.yml | 15 ++------ .../policy/stig/shared.yml | 8 +---- .../policy/stig/shared.yml | 6 +--- .../policy/stig/shared.yml | 20 +++-------- .../policy/stig/shared.yml | 20 +++-------- .../policy/stig/shared.yml | 9 ++--- .../policy/stig/shared.yml | 8 ----- .../policy/stig/shared.yml | 2 -- .../policy/stig/shared.yml | 6 +--- .../policy/stig/shared.yml | 6 ---- .../policy/stig/shared.yml | 12 ++----- .../policy/stig/shared.yml | 6 +--- .../policy/stig/shared.yml | 2 -- .../policy/stig/shared.yml | 4 +-- .../policy/stig/shared.yml | 4 +-- .../policy/stig/shared.yml | 4 +-- .../policy/stig/shared.yml | 8 +---- .../policy/stig/shared.yml | 5 +-- .../policy/stig/shared.yml | 5 +-- .../policy/stig/shared.yml | 8 +---- .../policy/stig/shared.yml | 4 --- .../policy/stig/shared.yml | 4 --- .../policy/stig/shared.yml | 8 +---- .../policy/stig/shared.yml | 8 +---- .../policy/stig/shared.yml | 2 -- .../policy/stig/shared.yml | 22 ++---------- .../policy/stig/shared.yml | 12 ++----- .../policy/stig/shared.yml | 5 +-- .../policy/stig/shared.yml | 6 +--- .../policy/stig/shared.yml | 7 +--- .../policy/stig/shared.yml | 7 +--- .../policy/stig/shared.yml | 7 +--- .../policy/stig/shared.yml | 5 +-- .../policy/stig/shared.yml | 5 +-- .../policy/stig/shared.yml | 2 -- .../policy/stig/shared.yml | 6 ---- .../policy/stig/shared.yml | 6 ---- .../policy/stig/shared.yml | 10 +----- .../disable_host_auth/policy/stig/shared.yml | 5 +-- .../policy/stig/shared.yml | 4 +-- .../policy/stig/shared.yml | 2 -- .../policy/stig/shared.yml | 5 +-- .../policy/stig/shared.yml | 7 +--- .../policy/stig/shared.yml | 5 +-- .../policy/stig/shared.yml | 8 +---- .../policy/stig/shared.yml | 6 +--- .../policy/stig/shared.yml | 4 +-- .../policy/stig/shared.yml | 5 +-- .../sshd_enable_pam/policy/stig/shared.yml | 7 +--- .../policy/stig/shared.yml | 10 +----- .../policy/stig/shared.yml | 2 -- .../policy/stig/shared.yml | 7 +--- .../policy/stig/shared.yml | 2 -- .../policy/stig/shared.yml | 10 +----- .../policy/stig/shared.yml | 2 -- .../policy/stig/shared.yml | 9 +---- .../policy/stig/shared.yml | 2 -- .../policy/stig/shared.yml | 10 +----- .../policy/stig/shared.yml | 8 ----- .../policy/stig/shared.yml | 2 -- .../policy/stig/shared.yml | 20 +---------- .../policy/stig/shared.yml | 6 +--- .../policy/stig/shared.yml | 6 +--- .../policy/stig/shared.yml | 6 +--- .../policy/stig/shared.yml | 7 ++-- .../policy/stig/shared.yml | 5 +-- .../policy/stig/shared.yml | 15 ++------ .../policy/stig/shared.yml | 6 +--- .../policy/stig/shared.yml | 8 +---- .../policy/stig/shared.yml | 5 +-- .../policy/stig/shared.yml | 5 +-- .../policy/stig/shared.yml | 2 -- .../policy/stig/shared.yml | 10 +----- .../policy/stig/shared.yml | 4 +-- .../policy/stig/shared.yml | 6 +--- .../policy/stig/shared.yml | 5 +-- .../policy/stig/shared.yml | 4 --- .../policy/stig/shared.yml | 5 +-- .../policy/stig/shared.yml | 5 +-- .../policy/stig/shared.yml | 18 ++-------- .../policy/stig/shared.yml | 6 ---- .../policy/stig/shared.yml | 12 +------ .../policy/stig/shared.yml | 2 -- .../policy/stig/shared.yml | 2 -- .../policy/stig/shared.yml | 2 -- .../policy/stig/shared.yml | 9 ++--- .../policy/stig/shared.yml | 9 ++--- .../policy/stig/shared.yml | 2 -- .../policy/stig/shared.yml | 8 +---- .../no_tmux_in_shells/policy/stig/shared.yml | 6 +--- .../policy/stig/shared.yml | 8 +---- .../policy/stig/shared.yml | 10 +----- .../policy/stig/shared.yml | 6 +--- .../policy/stig/shared.yml | 5 +-- .../policy/stig/shared.yml | 10 ++---- .../policy/stig/shared.yml | 4 +-- .../policy/stig/shared.yml | 15 +++----- .../account_unique_id/policy/stig/shared.yml | 4 +-- .../group_unique_id/policy/stig/shared.yml | 4 +-- .../policy/stig/shared.yml | 16 ++------- .../policy/stig/shared.yml | 13 ++----- .../policy/stig/shared.yml | 6 ---- .../policy/stig/shared.yml | 4 --- .../policy/stig/shared.yml | 12 ++----- .../policy/stig/shared.yml | 6 +--- .../no_empty_passwords/policy/stig/shared.yml | 6 +--- .../policy/stig/shared.yml | 6 +--- .../policy/stig/shared.yml | 8 +---- .../policy/stig/shared.yml | 5 +-- .../policy/stig/shared.yml | 6 +--- .../policy/stig/shared.yml | 2 -- .../accounts_tmout/policy/stig/shared.yml | 7 +--- .../policy/stig/shared.yml | 8 +---- .../policy/stig/shared.yml | 16 ++------- .../policy/stig/shared.yml | 5 +-- .../policy/stig/shared.yml | 8 +---- .../policy/stig/shared.yml | 7 +--- .../policy/stig/shared.yml | 2 -- .../policy/stig/shared.yml | 2 -- .../policy/stig/shared.yml | 5 +-- .../policy/stig/shared.yml | 2 -- .../policy/stig/shared.yml | 2 -- .../policy/stig/shared.yml | 2 -- .../policy/stig/shared.yml | 2 -- .../grub2_pti_argument/policy/stig/shared.yml | 7 +--- .../policy/stig/shared.yml | 8 ++--- .../policy/stig/shared.yml | 5 +-- .../policy/stig/shared.yml | 2 -- .../policy/stig/shared.yml | 4 +-- .../grub2_password/policy/stig/shared.yml | 9 ++--- .../policy/stig/shared.yml | 6 +--- .../policy/stig/shared.yml | 16 ++------- .../policy/stig/shared.yml | 16 ++------- .../policy/stig/shared.yml | 10 ++---- .../policy/stig/shared.yml | 7 +--- .../policy/stig/shared.yml | 2 -- .../policy/stig/shared.yml | 5 +-- .../policy/stig/shared.yml | 4 +-- .../rsyslog_nolisten/policy/stig/shared.yml | 8 ++--- .../policy/stig/shared.yml | 19 ++--------- .../policy/stig/shared.yml | 5 +-- .../firewalld-backend/policy/stig/shared.yml | 4 --- .../policy/stig/shared.yml | 13 ++----- .../policy/stig/shared.yml | 11 ++---- .../policy/stig/shared.yml | 27 ++------------- .../policy/stig/shared.yml | 4 --- .../policy/stig/shared.yml | 4 +-- .../policy/stig/shared.yml | 6 +--- .../policy/stig/shared.yml | 2 -- .../policy/stig/shared.yml | 2 -- .../policy/stig/shared.yml | 3 -- .../policy/stig/shared.yml | 6 +--- .../policy/stig/shared.yml | 2 -- .../policy/stig/shared.yml | 2 -- .../policy/stig/shared.yml | 7 +--- .../policy/stig/shared.yml | 13 ++----- .../policy/stig/shared.yml | 15 ++------ .../policy/stig/shared.yml | 2 -- .../policy/stig/shared.yml | 7 +--- .../policy/stig/shared.yml | 8 +---- .../policy/stig/shared.yml | 12 ++----- .../policy/stig/shared.yml | 14 ++------ .../policy/stig/shared.yml | 3 -- .../policy/stig/shared.yml | 8 +---- .../policy/stig/shared.yml | 11 ++---- .../policy/stig/shared.yml | 4 +-- .../policy/stig/shared.yml | 6 +--- .../policy/stig/shared.yml | 9 +---- .../policy/stig/shared.yml | 9 +---- .../policy/stig/shared.yml | 5 +-- .../policy/stig/shared.yml | 2 -- .../policy/stig/shared.yml | 2 -- .../policy/stig/shared.yml | 6 ---- .../policy/stig/shared.yml | 6 ---- .../policy/stig/shared.yml | 4 +-- .../policy/stig/shared.yml | 4 +-- .../policy/stig/shared.yml | 7 +--- .../policy/stig/shared.yml | 13 ++----- .../policy/stig/shared.yml | 6 +--- .../policy/stig/shared.yml | 6 +--- .../policy/stig/shared.yml | 9 +---- .../policy/stig/shared.yml | 2 -- .../policy/stig/shared.yml | 2 -- .../policy/stig/shared.yml | 4 +-- .../policy/stig/shared.yml | 6 +--- .../policy/stig/shared.yml | 5 +-- .../policy/stig/shared.yml | 6 +--- .../policy/stig/shared.yml | 6 +--- .../policy/stig/shared.yml | 5 +-- .../policy/stig/shared.yml | 5 +-- .../policy/stig/shared.yml | 5 +-- .../policy/stig/shared.yml | 5 +-- .../policy/stig/shared.yml | 6 +--- .../policy/stig/shared.yml | 5 +-- .../policy/stig/shared.yml | 6 +--- .../policy/stig/shared.yml | 6 +--- .../policy/stig/shared.yml | 5 +-- .../policy/stig/shared.yml | 5 +-- .../policy/stig/shared.yml | 5 +-- .../policy/stig/shared.yml | 8 +---- .../policy/stig/shared.yml | 6 +--- .../policy/stig/shared.yml | 5 +-- .../policy/stig/shared.yml | 6 +--- .../policy/stig/shared.yml | 6 +--- .../policy/stig/shared.yml | 5 +-- .../policy/stig/shared.yml | 5 +-- .../policy/stig/shared.yml | 7 +--- .../policy/stig/shared.yml | 8 +---- .../policy/stig/shared.yml | 6 +--- .../policy/stig/shared.yml | 6 +--- .../file_owner_var_log/policy/stig/shared.yml | 6 +--- .../policy/stig/shared.yml | 6 +--- .../policy/stig/shared.yml | 6 +--- .../policy/stig/shared.yml | 6 +--- .../policy/stig/shared.yml | 4 --- .../policy/stig/shared.yml | 4 --- .../policy/stig/shared.yml | 14 ++------ .../policy/stig/shared.yml | 4 --- .../policy/stig/shared.yml | 4 --- .../policy/stig/shared.yml | 4 --- .../policy/stig/shared.yml | 4 --- .../policy/stig/shared.yml | 4 --- .../policy/stig/shared.yml | 4 --- .../policy/stig/shared.yml | 4 +-- .../policy/stig/shared.yml | 4 +-- .../policy/stig/shared.yml | 8 +---- .../policy/stig/shared.yml | 2 -- .../policy/stig/shared.yml | 4 +-- .../policy/stig/shared.yml | 4 +-- .../policy/stig/shared.yml | 5 +-- .../policy/stig/shared.yml | 4 +-- .../policy/stig/shared.yml | 6 +--- .../policy/stig/shared.yml | 4 +-- .../policy/stig/shared.yml | 4 +-- .../policy/stig/shared.yml | 6 +--- .../policy/stig/shared.yml | 4 +-- .../policy/stig/shared.yml | 4 +-- .../policy/stig/shared.yml | 6 +--- .../policy/stig/shared.yml | 7 +--- .../policy/stig/shared.yml | 4 +-- .../policy/stig/shared.yml | 6 +--- .../policy/stig/shared.yml | 6 +--- .../policy/stig/shared.yml | 4 +-- .../policy/stig/shared.yml | 4 +-- .../policy/stig/shared.yml | 6 +--- .../policy/stig/shared.yml | 4 +-- .../policy/stig/shared.yml | 4 +-- .../policy/stig/shared.yml | 6 +--- .../policy/stig/shared.yml | 4 +-- .../policy/stig/shared.yml | 4 +-- .../policy/stig/shared.yml | 6 +--- .../policy/stig/shared.yml | 6 +--- .../policy/stig/shared.yml | 4 +-- .../policy/stig/shared.yml | 4 +-- .../policy/stig/shared.yml | 14 ++------ .../policy/stig/shared.yml | 10 +----- .../policy/stig/shared.yml | 2 -- .../policy/stig/shared.yml | 6 +--- .../policy/stig/shared.yml | 10 +----- .../policy/stig/shared.yml | 4 +-- .../policy/stig/shared.yml | 6 +--- .../policy/stig/shared.yml | 8 +---- .../policy/stig/shared.yml | 10 ++---- .../policy/stig/shared.yml | 6 +--- .../policy/stig/shared.yml | 12 ++----- .../policy/stig/shared.yml | 4 --- .../policy/stig/shared.yml | 12 ++----- .../policy/stig/shared.yml | 5 +-- .../policy/stig/shared.yml | 6 +--- .../policy/stig/shared.yml | 6 +--- .../policy/stig/shared.yml | 5 +-- .../policy/stig/shared.yml | 4 +-- .../policy/stig/shared.yml | 4 --- .../policy/stig/shared.yml | 2 -- .../encrypt_partitions/policy/stig/shared.yml | 4 --- .../partition_for_home/policy/stig/shared.yml | 6 +--- .../partition_for_tmp/policy/stig/shared.yml | 6 +--- .../partition_for_var/policy/stig/shared.yml | 8 +---- .../policy/stig/shared.yml | 6 +--- .../policy/stig/shared.yml | 5 +-- .../policy/stig/shared.yml | 6 +--- .../policy/stig/shared.yml | 5 +-- .../policy/stig/shared.yml | 5 +-- .../policy/stig/shared.yml | 2 -- .../policy/stig/shared.yml | 4 --- .../policy/stig/shared.yml | 2 -- .../policy/stig/shared.yml | 4 +-- .../policy/stig/shared.yml | 4 +-- .../policy/stig/shared.yml | 8 +---- .../policy/stig/shared.yml | 5 +-- .../policy/stig/shared.yml | 12 ++----- .../policy/stig/shared.yml | 2 -- .../policy/stig/shared.yml | 8 +---- .../policy/stig/shared.yml | 8 +---- .../policy/stig/shared.yml | 7 +--- .../policy/stig/shared.yml | 8 +---- .../policy/stig/shared.yml | 6 ---- .../policy/stig/shared.yml | 6 +--- .../policy/stig/shared.yml | 2 -- .../policy/stig/shared.yml | 6 +--- .../policy/stig/shared.yml | 10 +----- .../policy/stig/shared.yml | 10 +----- .../policy/stig/shared.yml | 20 ++--------- .../policy/stig/shared.yml | 10 +----- .../policy/stig/shared.yml | 6 +--- .../policy/stig/shared.yml | 34 ++++--------------- .../policy/stig/shared.yml | 4 --- .../aide_verify_acls/policy/stig/shared.yml | 7 +--- .../policy/stig/shared.yml | 7 +--- .../policy/stig/shared.yml | 8 +---- .../policy/stig/shared.yml | 6 ---- .../policy/stig/shared.yml | 6 ---- .../policy/stig/shared.yml | 2 -- .../policy/stig/shared.yml | 7 +--- .../policy/stig/shared.yml | 10 ++---- .../policy/stig/shared.yml | 10 ++---- .../policy/stig/shared.yml | 12 ++----- .../policy/stig/shared.yml | 5 +-- .../policy/stig/shared.yml | 5 +-- .../policy/stig/shared.yml | 10 +----- .../policy/stig/shared.yml | 10 ++---- .../policy/stig/shared.yml | 6 ---- .../policy/stig/shared.yml | 8 +---- .../policy/stig/shared.yml | 5 +-- .../policy/stig/shared.yml | 14 +------- .../policy/stig/shared.yml | 6 ---- .../policy/stig/shared.yml | 2 -- .../policy/stig/shared.yml | 10 ++---- .../policy/stig/shared.yml | 10 ++---- .../policy/stig/shared.yml | 10 ++---- .../policy/stig/shared.yml | 8 +---- .../policy/stig/shared.yml | 8 +---- 393 files changed, 430 insertions(+), 2323 deletions(-) diff --git a/linux_os/guide/auditing/auditd_configure_rules/audit_dac_actions/audit_rules_dac_modification_umount/policy/stig/shared.yml b/linux_os/guide/auditing/auditd_configure_rules/audit_dac_actions/audit_rules_dac_modification_umount/policy/stig/shared.yml index 94fe05eea12c..2ccdaa4bc31b 100644 --- a/linux_os/guide/auditing/auditd_configure_rules/audit_dac_actions/audit_rules_dac_modification_umount/policy/stig/shared.yml +++ b/linux_os/guide/auditing/auditd_configure_rules/audit_dac_actions/audit_rules_dac_modification_umount/policy/stig/shared.yml @@ -2,10 +2,7 @@ srg_requirement: |- Successful/unsuccessful uses of the umount system call in {{{ full_name }}} must generate an audit record. vuldiscussion: |- - The changing of file permissions could indicate that a user is attempting to - gain access to information that would otherwise be disallowed. Auditing DAC modifications - can facilitate the identification of patterns of abuse among both authorized and - unauthorized users. + The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users. checktext: |- Verify that {{{ full_name }}} generates an audit record for all uses of the "umount" and system call with the following command: @@ -25,5 +22,3 @@ fixtext: |- The audit daemon must be restarted for the changes to take effect. -vuln_discussion: |- - The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users. diff --git a/linux_os/guide/auditing/auditd_configure_rules/audit_dac_actions/audit_rules_dac_modification_umount2/policy/stig/shared.yml b/linux_os/guide/auditing/auditd_configure_rules/audit_dac_actions/audit_rules_dac_modification_umount2/policy/stig/shared.yml index 546410034004..23c444f324a6 100644 --- a/linux_os/guide/auditing/auditd_configure_rules/audit_dac_actions/audit_rules_dac_modification_umount2/policy/stig/shared.yml +++ b/linux_os/guide/auditing/auditd_configure_rules/audit_dac_actions/audit_rules_dac_modification_umount2/policy/stig/shared.yml @@ -2,10 +2,7 @@ srg_requirement: |- Successful/unsuccessful uses of the umount2 system call in {{{ full_name }}} must generate an audit record. vuldiscussion: |- - The changing of file permissions could indicate that a user is attempting to - gain access to information that would otherwise be disallowed. Auditing DAC modifications - can facilitate the identification of patterns of abuse among both authorized and - unauthorized users. + The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users. checktext: |- To determine if the system is configured to audit calls to the umount2 system call, run the following command: @@ -24,5 +21,3 @@ fixtext: |- The audit daemon must be restarted for the changes to take effect. -vuln_discussion: |- - The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users. diff --git a/linux_os/guide/auditing/auditd_configure_rules/audit_execution_acl_commands/audit_rules_execution_chacl/policy/stig/shared.yml b/linux_os/guide/auditing/auditd_configure_rules/audit_execution_acl_commands/audit_rules_execution_chacl/policy/stig/shared.yml index df9f20ba414d..e3e67e740bed 100644 --- a/linux_os/guide/auditing/auditd_configure_rules/audit_execution_acl_commands/audit_rules_execution_chacl/policy/stig/shared.yml +++ b/linux_os/guide/auditing/auditd_configure_rules/audit_execution_acl_commands/audit_rules_execution_chacl/policy/stig/shared.yml @@ -2,13 +2,13 @@ srg_requirement: |- {{{ full_name }}} must audit all uses of the chacl command. vuldiscussion: |- - 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. + Without generating audit records 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). - 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. + When a user logs on, the auid is set to the uid of the account 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. - The system call rules are loaded into a matching engine that intercepts each syscall made by all programs on the system. Therefore, it is very important to use syscall rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining syscalls into one rule whenever possible. + The system call rules are loaded into a matching engine that intercepts each system call made by all programs on the system. Therefore, it is very important to use system call rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining system calls into one rule whenever possible. checktext: |- Verify that {{{ full_name }}} is configured to audit the execution of the "chacl" command with the following command: @@ -26,11 +26,3 @@ fixtext: |- The audit daemon must be restarted for the changes to take effect. -vuln_discussion: |- - Without generating audit records 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). - - When a user logs on, the auid is set to the uid of the account 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. - - The system call rules are loaded into a matching engine that intercepts each system call made by all programs on the system. Therefore, it is very important to use system call rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining system calls into one rule whenever possible. diff --git a/linux_os/guide/auditing/auditd_configure_rules/audit_execution_acl_commands/audit_rules_execution_setfacl/policy/stig/shared.yml b/linux_os/guide/auditing/auditd_configure_rules/audit_execution_acl_commands/audit_rules_execution_setfacl/policy/stig/shared.yml index 58020dfe48e3..8075e19e533f 100644 --- a/linux_os/guide/auditing/auditd_configure_rules/audit_execution_acl_commands/audit_rules_execution_setfacl/policy/stig/shared.yml +++ b/linux_os/guide/auditing/auditd_configure_rules/audit_execution_acl_commands/audit_rules_execution_setfacl/policy/stig/shared.yml @@ -2,13 +2,13 @@ srg_requirement: |- {{{ full_name }}} must audit all uses of the setfacl command. vuldiscussion: |- - 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. + Without generating audit records 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). - 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. + When a user logs on, the auid is set to the uid of the account 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. - The system call rules are loaded into a matching engine that intercepts each syscall made by all programs on the system. Therefore, it is very important to use syscall rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining syscalls into one rule whenever possible. + The system call rules are loaded into a matching engine that intercepts each system call made by all programs on the system. Therefore, it is very important to use system call rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining system calls into one rule whenever possible. checktext: |- Verify that {{{ full_name }}} is configured to audit the execution of the "setfacl" command with the following command: @@ -26,11 +26,3 @@ fixtext: |- The audit daemon must be restarted for the changes to take effect. -vuln_discussion: |- - Without generating audit records 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). - - When a user logs on, the auid is set to the uid of the account 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. - - The system call rules are loaded into a matching engine that intercepts each system call made by all programs on the system. Therefore, it is very important to use system call rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining system calls into one rule whenever possible. diff --git a/linux_os/guide/auditing/auditd_configure_rules/audit_execution_selinux_commands/audit_rules_execution_chcon/policy/stig/shared.yml b/linux_os/guide/auditing/auditd_configure_rules/audit_execution_selinux_commands/audit_rules_execution_chcon/policy/stig/shared.yml index 60e687d850f4..67c448992ac7 100644 --- a/linux_os/guide/auditing/auditd_configure_rules/audit_execution_selinux_commands/audit_rules_execution_chcon/policy/stig/shared.yml +++ b/linux_os/guide/auditing/auditd_configure_rules/audit_execution_selinux_commands/audit_rules_execution_chcon/policy/stig/shared.yml @@ -8,7 +8,7 @@ vuldiscussion: |- 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. - The system call rules are loaded into a matching engine that intercepts each syscall made by all programs on the system. Therefore, it is very important to use syscall rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining syscalls into one rule whenever possible. + The system call rules are loaded into a matching engine that intercepts each system call made by all programs on the system. Therefore, it is very important to use system call rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining system calls into one rule whenever possible. checktext: |- Verify that {{{ full_name }}} is configured to audit the execution of the "chcon" command with the following command: @@ -26,11 +26,3 @@ fixtext: |- The audit daemon must be restarted for the changes to take effect. -vuln_discussion: |- - 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). - - 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. - - The system call rules are loaded into a matching engine that intercepts each system call made by all programs on the system. Therefore, it is very important to use system call rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining system calls into one rule whenever possible. diff --git a/linux_os/guide/auditing/auditd_configure_rules/audit_execution_selinux_commands/audit_rules_execution_semanage/policy/stig/shared.yml b/linux_os/guide/auditing/auditd_configure_rules/audit_execution_selinux_commands/audit_rules_execution_semanage/policy/stig/shared.yml index 286b086ff00e..3ef67c9b66ae 100644 --- a/linux_os/guide/auditing/auditd_configure_rules/audit_execution_selinux_commands/audit_rules_execution_semanage/policy/stig/shared.yml +++ b/linux_os/guide/auditing/auditd_configure_rules/audit_execution_selinux_commands/audit_rules_execution_semanage/policy/stig/shared.yml @@ -2,13 +2,13 @@ srg_requirement: |- {{{ full_name }}} must audit all uses of the semanage command. vuldiscussion: |- - 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. + Without generating audit records 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). - 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. + When a user logs on, the auid is set to the uid of the account 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. - The system call rules are loaded into a matching engine that intercepts each syscall made by all programs on the system. Therefore, it is very important to use syscall rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining syscalls into one rule whenever possible. + The system call rules are loaded into a matching engine that intercepts each system call made by all programs on the system. Therefore, it is very important to use system call rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining system calls into one rule whenever possible. checktext: |- Verify that {{{ full_name }}} is configured to audit the execution of the "semanage" command with the following command: @@ -26,11 +26,3 @@ fixtext: |- The audit daemon must be restarted for the changes to take effect. -vuln_discussion: |- - Without generating audit records 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). - - When a user logs on, the auid is set to the uid of the account 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. - - The system call rules are loaded into a matching engine that intercepts each system call made by all programs on the system. Therefore, it is very important to use system call rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining system calls into one rule whenever possible. diff --git a/linux_os/guide/auditing/auditd_configure_rules/audit_execution_selinux_commands/audit_rules_execution_setfiles/policy/stig/shared.yml b/linux_os/guide/auditing/auditd_configure_rules/audit_execution_selinux_commands/audit_rules_execution_setfiles/policy/stig/shared.yml index ab036965fc4f..535f809e2b6e 100644 --- a/linux_os/guide/auditing/auditd_configure_rules/audit_execution_selinux_commands/audit_rules_execution_setfiles/policy/stig/shared.yml +++ b/linux_os/guide/auditing/auditd_configure_rules/audit_execution_selinux_commands/audit_rules_execution_setfiles/policy/stig/shared.yml @@ -2,13 +2,13 @@ srg_requirement: |- {{{ full_name }}} must audit all uses of the setfiles command. vuldiscussion: |- - 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. + Without generating audit records 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). - 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. + When a user logs on, the auid is set to the uid of the account 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. - The system call rules are loaded into a matching engine that intercepts each syscall made by all programs on the system. Therefore, it is very important to use syscall rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining syscalls into one rule whenever possible. + The system call rules are loaded into a matching engine that intercepts each system call made by all programs on the system. Therefore, it is very important to use system call rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining system calls into one rule whenever possible. checktext: |- Verify that {{{ full_name }}} is configured to audit the execution of the "setfiles" command with the following command: @@ -26,11 +26,3 @@ fixtext: |- The audit daemon must be restarted for the changes to take effect. -vuln_discussion: |- - Without generating audit records 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). - - When a user logs on, the auid is set to the uid of the account 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. - - The system call rules are loaded into a matching engine that intercepts each system call made by all programs on the system. Therefore, it is very important to use system call rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining system calls into one rule whenever possible. diff --git a/linux_os/guide/auditing/auditd_configure_rules/audit_execution_selinux_commands/audit_rules_execution_setsebool/policy/stig/shared.yml b/linux_os/guide/auditing/auditd_configure_rules/audit_execution_selinux_commands/audit_rules_execution_setsebool/policy/stig/shared.yml index f45184955be7..6f19d05e2bc6 100644 --- a/linux_os/guide/auditing/auditd_configure_rules/audit_execution_selinux_commands/audit_rules_execution_setsebool/policy/stig/shared.yml +++ b/linux_os/guide/auditing/auditd_configure_rules/audit_execution_selinux_commands/audit_rules_execution_setsebool/policy/stig/shared.yml @@ -2,13 +2,13 @@ srg_requirement: |- {{{ full_name }}} must audit all uses of the setsebool command. vuldiscussion: |- - 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. + Without generating audit records 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). - 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. + When a user logs on, the auid is set to the uid of the account 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. - The system call rules are loaded into a matching engine that intercepts each syscall made by all programs on the system. Therefore, it is very important to use syscall rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining syscalls into one rule whenever possible. + The system call rules are loaded into a matching engine that intercepts each system call made by all programs on the system. Therefore, it is very important to use system call rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining system calls into one rule whenever possible. checktext: |- Verify that {{{ full_name }}} is configured to audit the execution of the "setsebool" command with the following command: @@ -26,11 +26,3 @@ fixtext: |- The audit daemon must be restarted for the changes to take effect. -vuln_discussion: |- - Without generating audit records 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). - - When a user logs on, the auid is set to the uid of the account 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. - - The system call rules are loaded into a matching engine that intercepts each system call made by all programs on the system. Therefore, it is very important to use system call rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining system calls into one rule whenever possible. diff --git a/linux_os/guide/auditing/auditd_configure_rules/audit_kernel_module_loading/audit_rules_kernel_module_loading_delete/policy/stig/shared.yml b/linux_os/guide/auditing/auditd_configure_rules/audit_kernel_module_loading/audit_rules_kernel_module_loading_delete/policy/stig/shared.yml index dab6c0c0eeeb..147a3e739e85 100644 --- a/linux_os/guide/auditing/auditd_configure_rules/audit_kernel_module_loading/audit_rules_kernel_module_loading_delete/policy/stig/shared.yml +++ b/linux_os/guide/auditing/auditd_configure_rules/audit_kernel_module_loading/audit_rules_kernel_module_loading_delete/policy/stig/shared.yml @@ -2,13 +2,13 @@ srg_requirement: |- {{{ full_name }}} must audit all uses of the delete_module system call. vuldiscussion: |- - 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. + Without generating audit records 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). - 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. + When a user logs on, the auid is set to the uid of the account 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. - The system call rules are loaded into a matching engine that intercepts each syscall made by all programs on the system. Therefore, it is very important to use syscall rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining syscalls into one rule whenever possible. + The system call rules are loaded into a matching engine that intercepts each system call made by all programs on the system. Therefore, it is very important to use system call rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining system calls into one rule whenever possible. checktext: |- Verify that {{{ full_name }}} is configured to audit the execution of the "delete_module" system call with the following command: @@ -28,11 +28,3 @@ fixtext: |- The audit daemon must be restarted for the changes to take effect. -vuln_discussion: |- - Without generating audit records 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). - - When a user logs on, the auid is set to the uid of the account 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. - - The system call rules are loaded into a matching engine that intercepts each system call made by all programs on the system. Therefore, it is very important to use system call rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining system calls into one rule whenever possible. diff --git a/linux_os/guide/auditing/auditd_configure_rules/audit_login_events/audit_rules_login_events_faillock/policy/stig/shared.yml b/linux_os/guide/auditing/auditd_configure_rules/audit_login_events/audit_rules_login_events_faillock/policy/stig/shared.yml index 33444b99cb36..93a916ffafc2 100644 --- a/linux_os/guide/auditing/auditd_configure_rules/audit_login_events/audit_rules_login_events_faillock/policy/stig/shared.yml +++ b/linux_os/guide/auditing/auditd_configure_rules/audit_login_events/audit_rules_login_events_faillock/policy/stig/shared.yml @@ -2,7 +2,7 @@ srg_requirement: |- {{{ full_name }}} must generate audit records for all account creations, modifications, disabling, and termination events that affect /var/log/faillock. vuldiscussion: |- - 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. + Without generating audit records 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. checktext: |- Verify {{{ full_name }}} generates audit records for all account creations, modifications, disabling, and termination events that affect "/var/log/faillock" with the following command: @@ -22,5 +22,3 @@ fixtext: |- The audit daemon must be restarted for the changes to take effect. -vuln_discussion: |- - Without generating audit records 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. diff --git a/linux_os/guide/auditing/auditd_configure_rules/audit_login_events/audit_rules_login_events_lastlog/policy/stig/shared.yml b/linux_os/guide/auditing/auditd_configure_rules/audit_login_events/audit_rules_login_events_lastlog/policy/stig/shared.yml index 9fc2d30213e9..0a8dc68e8bf2 100644 --- a/linux_os/guide/auditing/auditd_configure_rules/audit_login_events/audit_rules_login_events_lastlog/policy/stig/shared.yml +++ b/linux_os/guide/auditing/auditd_configure_rules/audit_login_events/audit_rules_login_events_lastlog/policy/stig/shared.yml @@ -2,7 +2,7 @@ srg_requirement: |- {{{ full_name }}} must generate audit records for all account creations, modifications, disabling, and termination events that affect /var/log/lastlog. vuldiscussion: |- - 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. + Without generating audit records 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. checktext: |- Verify {{{ full_name }}} generates audit records for all account creations, modifications, disabling, and termination events that affect "/var/log/lastlog" with the following command: @@ -22,5 +22,3 @@ fixtext: |- The audit daemon must be restarted for the changes to take effect. -vuln_discussion: |- - Without generating audit records 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. diff --git a/linux_os/guide/auditing/auditd_configure_rules/audit_login_events/audit_rules_login_events_tallylog/policy/stig/shared.yml b/linux_os/guide/auditing/auditd_configure_rules/audit_login_events/audit_rules_login_events_tallylog/policy/stig/shared.yml index 729aacb69edf..2ce10c9d4365 100644 --- a/linux_os/guide/auditing/auditd_configure_rules/audit_login_events/audit_rules_login_events_tallylog/policy/stig/shared.yml +++ b/linux_os/guide/auditing/auditd_configure_rules/audit_login_events/audit_rules_login_events_tallylog/policy/stig/shared.yml @@ -2,7 +2,7 @@ srg_requirement: |- {{{ full_name }}} must generate audit records for all account creations, modifications, disabling, and termination events that affect /var/log/tallylog. vuldiscussion: |- - 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. + Without generating audit records 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. checktext: |- Verify {{{ full_name }}} generates audit records for all account creations, modifications, disabling, and termination events that affect "/var/log/tallylog" with the following command: @@ -22,5 +22,3 @@ fixtext: |- The audit daemon must be restarted for the changes to take effect. -vuln_discussion: |- - Without generating audit records 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. diff --git a/linux_os/guide/auditing/auditd_configure_rules/audit_privileged_commands/audit_privileged_commands_init/policy/stig/shared.yml b/linux_os/guide/auditing/auditd_configure_rules/audit_privileged_commands/audit_privileged_commands_init/policy/stig/shared.yml index 46d23fca935e..7fb0c751a0e4 100644 --- a/linux_os/guide/auditing/auditd_configure_rules/audit_privileged_commands/audit_privileged_commands_init/policy/stig/shared.yml +++ b/linux_os/guide/auditing/auditd_configure_rules/audit_privileged_commands/audit_privileged_commands_init/policy/stig/shared.yml @@ -20,5 +20,3 @@ fixtext: |- The audit daemon must be restarted for the changes to take effect. -vuln_discussion: |- - Misuse of the init command may cause availability issues for the system. diff --git a/linux_os/guide/auditing/auditd_configure_rules/audit_privileged_commands/audit_privileged_commands_poweroff/policy/stig/shared.yml b/linux_os/guide/auditing/auditd_configure_rules/audit_privileged_commands/audit_privileged_commands_poweroff/policy/stig/shared.yml index 1deec7d454b3..1e6329e32e8e 100644 --- a/linux_os/guide/auditing/auditd_configure_rules/audit_privileged_commands/audit_privileged_commands_poweroff/policy/stig/shared.yml +++ b/linux_os/guide/auditing/auditd_configure_rules/audit_privileged_commands/audit_privileged_commands_poweroff/policy/stig/shared.yml @@ -20,5 +20,3 @@ fixtext: |- The audit daemon must be restarted for the changes to take effect. -vuln_discussion: |- - Misuse of the poweroff command may cause availability issues for the system. diff --git a/linux_os/guide/auditing/auditd_configure_rules/audit_privileged_commands/audit_privileged_commands_reboot/policy/stig/shared.yml b/linux_os/guide/auditing/auditd_configure_rules/audit_privileged_commands/audit_privileged_commands_reboot/policy/stig/shared.yml index eecf4b6bbffa..c3cd5a2ee402 100644 --- a/linux_os/guide/auditing/auditd_configure_rules/audit_privileged_commands/audit_privileged_commands_reboot/policy/stig/shared.yml +++ b/linux_os/guide/auditing/auditd_configure_rules/audit_privileged_commands/audit_privileged_commands_reboot/policy/stig/shared.yml @@ -20,5 +20,3 @@ fixtext: |- The audit daemon must be restarted for the changes to take effect. -vuln_discussion: |- - Misuse of the reboot command may cause availability issues for the system. diff --git a/linux_os/guide/auditing/auditd_configure_rules/audit_privileged_commands/audit_privileged_commands_shutdown/policy/stig/shared.yml b/linux_os/guide/auditing/auditd_configure_rules/audit_privileged_commands/audit_privileged_commands_shutdown/policy/stig/shared.yml index 7c0b0785f830..abf075d8c380 100644 --- a/linux_os/guide/auditing/auditd_configure_rules/audit_privileged_commands/audit_privileged_commands_shutdown/policy/stig/shared.yml +++ b/linux_os/guide/auditing/auditd_configure_rules/audit_privileged_commands/audit_privileged_commands_shutdown/policy/stig/shared.yml @@ -20,5 +20,3 @@ fixtext: |- The audit daemon must be restarted for the changes to take effect. -vuln_discussion: |- - Misuse of the shutdown command may cause availability issues for the system. diff --git a/linux_os/guide/auditing/auditd_configure_rules/audit_privileged_commands/audit_rules_privileged_commands_chage/policy/stig/shared.yml b/linux_os/guide/auditing/auditd_configure_rules/audit_privileged_commands/audit_rules_privileged_commands_chage/policy/stig/shared.yml index d749232be781..04383df8f1e0 100644 --- a/linux_os/guide/auditing/auditd_configure_rules/audit_privileged_commands/audit_rules_privileged_commands_chage/policy/stig/shared.yml +++ b/linux_os/guide/auditing/auditd_configure_rules/audit_privileged_commands/audit_rules_privileged_commands_chage/policy/stig/shared.yml @@ -2,13 +2,13 @@ srg_requirement: |- {{{ full_name }}} must audit all uses of the chage command. vuldiscussion: |- - 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. + Without generating audit records 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). - 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. + When a user logs on, the auid is set to the uid of the account 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. - The system call rules are loaded into a matching engine that intercepts each syscall made by all programs on the system. Therefore, it is very important to use syscall rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining syscalls into one rule whenever possible. + The system call rules are loaded into a matching engine that intercepts each system call made by all programs on the system. Therefore, it is very important to use system call rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining system calls into one rule whenever possible. checktext: |- Verify that {{{ full_name }}} is configured to audit the execution of the "chage" command with the following command: @@ -26,11 +26,3 @@ fixtext: |- The audit daemon must be restarted for the changes to take effect. -vuln_discussion: |- - Without generating audit records 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). - - When a user logs on, the auid is set to the uid of the account 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. - - The system call rules are loaded into a matching engine that intercepts each system call made by all programs on the system. Therefore, it is very important to use system call rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining system calls into one rule whenever possible. diff --git a/linux_os/guide/auditing/auditd_configure_rules/audit_privileged_commands/audit_rules_privileged_commands_chsh/policy/stig/shared.yml b/linux_os/guide/auditing/auditd_configure_rules/audit_privileged_commands/audit_rules_privileged_commands_chsh/policy/stig/shared.yml index c01122f6e27a..b88534d85dbd 100644 --- a/linux_os/guide/auditing/auditd_configure_rules/audit_privileged_commands/audit_rules_privileged_commands_chsh/policy/stig/shared.yml +++ b/linux_os/guide/auditing/auditd_configure_rules/audit_privileged_commands/audit_rules_privileged_commands_chsh/policy/stig/shared.yml @@ -2,13 +2,13 @@ srg_requirement: |- {{{ full_name }}} must audit all uses of the chsh command. vuldiscussion: |- - 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. + Without generating audit records 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). - 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. + When a user logs on, the auid is set to the uid of the account 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. - The system call rules are loaded into a matching engine that intercepts each syscall made by all programs on the system. Therefore, it is very important to use syscall rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining syscalls into one rule whenever possible. + The system call rules are loaded into a matching engine that intercepts each system call made by all programs on the system. Therefore, it is very important to use system call rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining system calls into one rule whenever possible. checktext: |- Verify that {{{ full_name }}} is configured to audit the execution of the "chsh" command with the following command: @@ -26,11 +26,3 @@ fixtext: |- The audit daemon must be restarted for the changes to take effect. -vuln_discussion: |- - Without generating audit records 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). - - When a user logs on, the auid is set to the uid of the account 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. - - The system call rules are loaded into a matching engine that intercepts each system call made by all programs on the system. Therefore, it is very important to use system call rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining system calls into one rule whenever possible. diff --git a/linux_os/guide/auditing/auditd_configure_rules/audit_privileged_commands/audit_rules_privileged_commands_crontab/policy/stig/shared.yml b/linux_os/guide/auditing/auditd_configure_rules/audit_privileged_commands/audit_rules_privileged_commands_crontab/policy/stig/shared.yml index ea02d9333311..074ef21ce63a 100644 --- a/linux_os/guide/auditing/auditd_configure_rules/audit_privileged_commands/audit_rules_privileged_commands_crontab/policy/stig/shared.yml +++ b/linux_os/guide/auditing/auditd_configure_rules/audit_privileged_commands/audit_rules_privileged_commands_crontab/policy/stig/shared.yml @@ -2,13 +2,13 @@ srg_requirement: |- {{{ full_name }}} must audit all uses of the crontab command. vuldiscussion: |- - 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. + Without generating audit records 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). - 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. + When a user logs on, the auid is set to the uid of the account 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. - The system call rules are loaded into a matching engine that intercepts each syscall made by all programs on the system. Therefore, it is very important to use syscall rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining syscalls into one rule whenever possible. + The system call rules are loaded into a matching engine that intercepts each system call made by all programs on the system. Therefore, it is very important to use system call rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining system calls into one rule whenever possible. checktext: |- Verify that {{{ full_name }}} is configured to audit the execution of the "crontab" command with the following command: @@ -26,11 +26,3 @@ fixtext: |- The audit daemon must be restarted for the changes to take effect. -vuln_discussion: |- - Without generating audit records 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). - - When a user logs on, the auid is set to the uid of the account 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. - - The system call rules are loaded into a matching engine that intercepts each system call made by all programs on the system. Therefore, it is very important to use system call rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining system calls into one rule whenever possible. diff --git a/linux_os/guide/auditing/auditd_configure_rules/audit_privileged_commands/audit_rules_privileged_commands_gpasswd/policy/stig/shared.yml b/linux_os/guide/auditing/auditd_configure_rules/audit_privileged_commands/audit_rules_privileged_commands_gpasswd/policy/stig/shared.yml index 7683db928884..39b660931215 100644 --- a/linux_os/guide/auditing/auditd_configure_rules/audit_privileged_commands/audit_rules_privileged_commands_gpasswd/policy/stig/shared.yml +++ b/linux_os/guide/auditing/auditd_configure_rules/audit_privileged_commands/audit_rules_privileged_commands_gpasswd/policy/stig/shared.yml @@ -2,13 +2,13 @@ srg_requirement: |- {{{ full_name }}} must audit all uses of the gpasswd command. vuldiscussion: |- - 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. + Without generating audit records 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). - 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. + When a user logs on, the auid is set to the uid of the account 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. - The system call rules are loaded into a matching engine that intercepts each syscall made by all programs on the system. Therefore, it is very important to use syscall rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining syscalls into one rule whenever possible. + The system call rules are loaded into a matching engine that intercepts each system call made by all programs on the system. Therefore, it is very important to use system call rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining system calls into one rule whenever possible. checktext: |- Verify that {{{ full_name }}} is configured to audit the execution of the "gpasswd" command with the following command: @@ -26,11 +26,3 @@ fixtext: |- The audit daemon must be restarted for the changes to take effect. -vuln_discussion: |- - Without generating audit records 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). - - When a user logs on, the auid is set to the uid of the account 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. - - The system call rules are loaded into a matching engine that intercepts each system call made by all programs on the system. Therefore, it is very important to use system call rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining system calls into one rule whenever possible. diff --git a/linux_os/guide/auditing/auditd_configure_rules/audit_privileged_commands/audit_rules_privileged_commands_kmod/policy/stig/shared.yml b/linux_os/guide/auditing/auditd_configure_rules/audit_privileged_commands/audit_rules_privileged_commands_kmod/policy/stig/shared.yml index 2de786a1d892..049bd803a415 100644 --- a/linux_os/guide/auditing/auditd_configure_rules/audit_privileged_commands/audit_rules_privileged_commands_kmod/policy/stig/shared.yml +++ b/linux_os/guide/auditing/auditd_configure_rules/audit_privileged_commands/audit_rules_privileged_commands_kmod/policy/stig/shared.yml @@ -6,9 +6,9 @@ vuldiscussion: |- Audit records can be generated from various components within the information system (e.g., module or policy filter). - 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. + When a user logs on, the auid is set to the uid of the account 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. - The system call rules are loaded into a matching engine that intercepts each syscall made by all programs on the system. Therefore, it is very important to use syscall rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining syscalls into one rule whenever possible. + The system call rules are loaded into a matching engine that intercepts each system call made by all programs on the system. Therefore, it is very important to use system call rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining system calls into one rule whenever possible. checktext: |- Verify that {{{ full_name }}} is configured to audit the execution of the "kmod" command with the following command: @@ -26,11 +26,3 @@ fixtext: |- The audit daemon must be restarted for the changes to take effect. -vuln_discussion: |- - 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). - - When a user logs on, the auid is set to the uid of the account 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. - - The system call rules are loaded into a matching engine that intercepts each system call made by all programs on the system. Therefore, it is very important to use system call rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining system calls into one rule whenever possible. diff --git a/linux_os/guide/auditing/auditd_configure_rules/audit_privileged_commands/audit_rules_privileged_commands_mount/policy/stig/shared.yml b/linux_os/guide/auditing/auditd_configure_rules/audit_privileged_commands/audit_rules_privileged_commands_mount/policy/stig/shared.yml index 61d4bac948fa..f86f7d8cdf15 100644 --- a/linux_os/guide/auditing/auditd_configure_rules/audit_privileged_commands/audit_rules_privileged_commands_mount/policy/stig/shared.yml +++ b/linux_os/guide/auditing/auditd_configure_rules/audit_privileged_commands/audit_rules_privileged_commands_mount/policy/stig/shared.yml @@ -4,9 +4,11 @@ srg_requirement: |- vuldiscussion: |- 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. + Audit records can be generated from various components within the information system (e.g., module or policy filter). + + 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. - 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. + The system call rules are loaded into a matching engine that intercepts each system call made by all programs on the system. Therefore, it is very important to use system call rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining system calls into one rule whenever possible. checktext: |- Verify that {{{ full_name }}} is configured to audit the execution of the "mount" command with the following command: @@ -24,11 +26,3 @@ fixtext: |- The audit daemon must be restarted for the changes to take effect. -vuln_discussion: |- - 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). - - 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. - - The system call rules are loaded into a matching engine that intercepts each system call made by all programs on the system. Therefore, it is very important to use system call rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining system calls into one rule whenever possible. diff --git a/linux_os/guide/auditing/auditd_configure_rules/audit_privileged_commands/audit_rules_privileged_commands_newgrp/policy/stig/shared.yml b/linux_os/guide/auditing/auditd_configure_rules/audit_privileged_commands/audit_rules_privileged_commands_newgrp/policy/stig/shared.yml index 8d02a9204852..229bd0f3a131 100644 --- a/linux_os/guide/auditing/auditd_configure_rules/audit_privileged_commands/audit_rules_privileged_commands_newgrp/policy/stig/shared.yml +++ b/linux_os/guide/auditing/auditd_configure_rules/audit_privileged_commands/audit_rules_privileged_commands_newgrp/policy/stig/shared.yml @@ -2,13 +2,13 @@ srg_requirement: |- {{{ full_name }}} must audit all uses of the newgrp command. vuldiscussion: |- - 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. + Without generating audit records 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). 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. - The system call rules are loaded into a matching engine that intercepts each syscall made by all programs on the system. Therefore, it is very important to use syscall rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining syscalls into one rule whenever possible. + The system call rules are loaded into a matching engine that intercepts each system call made by all programs on the system. Therefore, it is very important to use system call rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining system calls into one rule whenever possible. checktext: |- Verify that {{{ full_name }}} is configured to audit the execution of the "newgrp" command with the following command: @@ -26,11 +26,3 @@ fixtext: |- The audit daemon must be restarted for the changes to take effect. -vuln_discussion: |- - Without generating audit records 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). - - 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. - - The system call rules are loaded into a matching engine that intercepts each system call made by all programs on the system. Therefore, it is very important to use system call rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining system calls into one rule whenever possible. diff --git a/linux_os/guide/auditing/auditd_configure_rules/audit_privileged_commands/audit_rules_privileged_commands_pam_timestamp_check/policy/stig/shared.yml b/linux_os/guide/auditing/auditd_configure_rules/audit_privileged_commands/audit_rules_privileged_commands_pam_timestamp_check/policy/stig/shared.yml index 934edbbc0501..eb90fb24ed02 100644 --- a/linux_os/guide/auditing/auditd_configure_rules/audit_privileged_commands/audit_rules_privileged_commands_pam_timestamp_check/policy/stig/shared.yml +++ b/linux_os/guide/auditing/auditd_configure_rules/audit_privileged_commands/audit_rules_privileged_commands_pam_timestamp_check/policy/stig/shared.yml @@ -2,13 +2,13 @@ srg_requirement: |- {{{ full_name }}} must audit all uses of the pam_timestamp_check command. vuldiscussion: |- - 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. + Without generating audit records 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). - 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. + When a user logs on, the auid is set to the uid of the account 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. - The system call rules are loaded into a matching engine that intercepts each syscall made by all programs on the system. Therefore, it is very important to use syscall rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining syscalls into one rule whenever possible. + The system call rules are loaded into a matching engine that intercepts each system call made by all programs on the system. Therefore, it is very important to use system call rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining system calls into one rule whenever possible. checktext: |- Verify that {{{ full_name }}} is configured to audit the execution of the "pam_timestamp_check" command with the following command: @@ -26,11 +26,3 @@ fixtext: |- The audit daemon must be restarted for the changes to take effect. -vuln_discussion: |- - Without generating audit records 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). - - When a user logs on, the auid is set to the uid of the account 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. - - The system call rules are loaded into a matching engine that intercepts each system call made by all programs on the system. Therefore, it is very important to use system call rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining system calls into one rule whenever possible. diff --git a/linux_os/guide/auditing/auditd_configure_rules/audit_privileged_commands/audit_rules_privileged_commands_passwd/policy/stig/shared.yml b/linux_os/guide/auditing/auditd_configure_rules/audit_privileged_commands/audit_rules_privileged_commands_passwd/policy/stig/shared.yml index 4aa81ea7f6e3..30155c3986c8 100644 --- a/linux_os/guide/auditing/auditd_configure_rules/audit_privileged_commands/audit_rules_privileged_commands_passwd/policy/stig/shared.yml +++ b/linux_os/guide/auditing/auditd_configure_rules/audit_privileged_commands/audit_rules_privileged_commands_passwd/policy/stig/shared.yml @@ -2,13 +2,13 @@ srg_requirement: |- {{{ full_name }}} must audit all uses of the passwd command. vuldiscussion: |- - 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. + Without generating audit records 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). - 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. + When a user logs on, the auid is set to the uid of the account 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. - The system call rules are loaded into a matching engine that intercepts each syscall made by all programs on the system. Therefore, it is very important to use syscall rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining syscalls into one rule whenever possible. + The system call rules are loaded into a matching engine that intercepts each system call made by all programs on the system. Therefore, it is very important to use system call rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining system calls into one rule whenever possible. checktext: |- Verify {{{ full_name }}} generates audit records for all account creations, modifications, disabling, and termination events that affect "/etc/gshadow" with the following command: @@ -26,11 +26,3 @@ fixtext: |- The audit daemon must be restarted for the changes to take effect. -vuln_discussion: |- - Without generating audit records 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). - - When a user logs on, the auid is set to the uid of the account 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. - - The system call rules are loaded into a matching engine that intercepts each system call made by all programs on the system. Therefore, it is very important to use system call rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining system calls into one rule whenever possible. diff --git a/linux_os/guide/auditing/auditd_configure_rules/audit_privileged_commands/audit_rules_privileged_commands_postdrop/policy/stig/shared.yml b/linux_os/guide/auditing/auditd_configure_rules/audit_privileged_commands/audit_rules_privileged_commands_postdrop/policy/stig/shared.yml index cc9921f76203..1376477448de 100644 --- a/linux_os/guide/auditing/auditd_configure_rules/audit_privileged_commands/audit_rules_privileged_commands_postdrop/policy/stig/shared.yml +++ b/linux_os/guide/auditing/auditd_configure_rules/audit_privileged_commands/audit_rules_privileged_commands_postdrop/policy/stig/shared.yml @@ -2,13 +2,13 @@ srg_requirement: |- {{{ full_name }}} must audit all uses of the postdrop command. vuldiscussion: |- - 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. + Without generating audit records 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). - 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. + When a user logs on, the auid is set to the uid of the account 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. - The system call rules are loaded into a matching engine that intercepts each syscall made by all programs on the system. Therefore, it is very important to use syscall rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining syscalls into one rule whenever possible. + The system call rules are loaded into a matching engine that intercepts each system call made by all programs on the system. Therefore, it is very important to use system call rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped however, by combining system calls into one rule whenever possible. checktext: |- Verify that {{{ full_name }}} is configured to audit the execution of the "postdrop" command with the following command: @@ -26,11 +26,3 @@ fixtext: |- The audit daemon must be restarted for the changes to take effect. -vuln_discussion: |- - Without generating audit records 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). - - When a user logs on, the auid is set to the uid of the account 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. - - The system call rules are loaded into a matching engine that intercepts each system call made by all programs on the system. Therefore, it is very important to use system call rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped however, by combining system calls into one rule whenever possible. diff --git a/linux_os/guide/auditing/auditd_configure_rules/audit_privileged_commands/audit_rules_privileged_commands_postqueue/policy/stig/shared.yml b/linux_os/guide/auditing/auditd_configure_rules/audit_privileged_commands/audit_rules_privileged_commands_postqueue/policy/stig/shared.yml index 7d7106415624..4da838de2eab 100644 --- a/linux_os/guide/auditing/auditd_configure_rules/audit_privileged_commands/audit_rules_privileged_commands_postqueue/policy/stig/shared.yml +++ b/linux_os/guide/auditing/auditd_configure_rules/audit_privileged_commands/audit_rules_privileged_commands_postqueue/policy/stig/shared.yml @@ -2,13 +2,13 @@ srg_requirement: |- {{{ full_name }}} must audit all uses of the postqueue command. vuldiscussion: |- - 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. + Without generating audit record 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). - 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. + When a user logs on, the auid is set to the uid of the account 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. - The system call rules are loaded into a matching engine that intercepts each syscall made by all programs on the system. Therefore, it is very important to use syscall rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining syscalls into one rule whenever possible. + The system call rules are loaded into a matching engine that intercepts each system call made by all programs on the system. Therefore, it is very important to use system call rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining system calls into one rule whenever possible. checktext: |- Verify that {{{ full_name }}} is configured to audit the execution of the "postqueue" command with the following command: @@ -26,11 +26,3 @@ fixtext: |- The audit daemon must be restarted for the changes to take effect. -vuln_discussion: |- - Without generating audit record 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). - - When a user logs on, the auid is set to the uid of the account 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. - - The system call rules are loaded into a matching engine that intercepts each system call made by all programs on the system. Therefore, it is very important to use system call rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining system calls into one rule whenever possible. diff --git a/linux_os/guide/auditing/auditd_configure_rules/audit_privileged_commands/audit_rules_privileged_commands_ssh_agent/policy/stig/shared.yml b/linux_os/guide/auditing/auditd_configure_rules/audit_privileged_commands/audit_rules_privileged_commands_ssh_agent/policy/stig/shared.yml index 3c23a00f0d12..bb0996b56b23 100644 --- a/linux_os/guide/auditing/auditd_configure_rules/audit_privileged_commands/audit_rules_privileged_commands_ssh_agent/policy/stig/shared.yml +++ b/linux_os/guide/auditing/auditd_configure_rules/audit_privileged_commands/audit_rules_privileged_commands_ssh_agent/policy/stig/shared.yml @@ -2,13 +2,13 @@ srg_requirement: |- {{{ full_name }}} must audit all uses of the ssh-agent command. vuldiscussion: |- - 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. + Without generating audit record 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). - 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. + When a user logs on, the auid is set to the uid of the account 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. - The system call rules are loaded into a matching engine that intercepts each syscall made by all programs on the system. Therefore, it is very important to use syscall rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining syscalls into one rule whenever possible. + The system call rules are loaded into a matching engine that intercepts each system call made by all programs on the system. Therefore, it is very important to use system call rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining system calls into one rule whenever possible. checktext: |- Verify that {{{ full_name }}} is configured to audit the execution of the "ssh-agent" command with the following command: @@ -26,11 +26,3 @@ fixtext: |- The audit daemon must be restarted for the changes to take effect. -vuln_discussion: |- - Without generating audit record 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). - - When a user logs on, the auid is set to the uid of the account 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. - - The system call rules are loaded into a matching engine that intercepts each system call made by all programs on the system. Therefore, it is very important to use system call rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining system calls into one rule whenever possible. diff --git a/linux_os/guide/auditing/auditd_configure_rules/audit_privileged_commands/audit_rules_privileged_commands_ssh_keysign/policy/stig/shared.yml b/linux_os/guide/auditing/auditd_configure_rules/audit_privileged_commands/audit_rules_privileged_commands_ssh_keysign/policy/stig/shared.yml index 42b7be9be209..3324ba34e6ce 100644 --- a/linux_os/guide/auditing/auditd_configure_rules/audit_privileged_commands/audit_rules_privileged_commands_ssh_keysign/policy/stig/shared.yml +++ b/linux_os/guide/auditing/auditd_configure_rules/audit_privileged_commands/audit_rules_privileged_commands_ssh_keysign/policy/stig/shared.yml @@ -2,13 +2,13 @@ srg_requirement: |- {{{ full_name }}} must audit all uses of the ssh-keysign command. vuldiscussion: |- - 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. + Without generating audit record 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). - 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. + When a user logs on, the auid is set to the uid of the account 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. - The system call rules are loaded into a matching engine that intercepts each syscall made by all programs on the system. Therefore, it is very important to use syscall rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining syscalls into one rule whenever possible. + The system call rules are loaded into a matching engine that intercepts each system call made by all programs on the system. Therefore, it is very important to use system call rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining system calls into one rule whenever possible. checktext: |- Verify that {{{ full_name }}} is configured to audit the execution of the "ssh-keysign" command with the following command: @@ -26,11 +26,3 @@ fixtext: |- The audit daemon must be restarted for the changes to take effect. -vuln_discussion: |- - Without generating audit record 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). - - When a user logs on, the auid is set to the uid of the account 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. - - The system call rules are loaded into a matching engine that intercepts each system call made by all programs on the system. Therefore, it is very important to use system call rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining system calls into one rule whenever possible. diff --git a/linux_os/guide/auditing/auditd_configure_rules/audit_privileged_commands/audit_rules_privileged_commands_su/policy/stig/shared.yml b/linux_os/guide/auditing/auditd_configure_rules/audit_privileged_commands/audit_rules_privileged_commands_su/policy/stig/shared.yml index d01da3c51384..5190b4fa6981 100644 --- a/linux_os/guide/auditing/auditd_configure_rules/audit_privileged_commands/audit_rules_privileged_commands_su/policy/stig/shared.yml +++ b/linux_os/guide/auditing/auditd_configure_rules/audit_privileged_commands/audit_rules_privileged_commands_su/policy/stig/shared.yml @@ -2,13 +2,13 @@ srg_requirement: |- {{{ full_name }}} must audit all uses of the su command. vuldiscussion: |- - 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. + Without generating audit record 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). - 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. + When a user logs on, the auid is set to the uid of the account 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. - The system call rules are loaded into a matching engine that intercepts each syscall made by all programs on the system. Therefore, it is very important to use syscall rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining syscalls into one rule whenever possible. + The system call rules are loaded into a matching engine that intercepts each system call made by all programs on the system. Therefore, it is very important to use system call rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining system calls into one rule whenever possible. checktext: |- Verify that {{{ full_name }}} is configured to audit the execution of the "su" command with the following command: @@ -26,11 +26,3 @@ fixtext: |- The audit daemon must be restarted for the changes to take effect. -vuln_discussion: |- - Without generating audit record 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). - - When a user logs on, the auid is set to the uid of the account 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. - - The system call rules are loaded into a matching engine that intercepts each system call made by all programs on the system. Therefore, it is very important to use system call rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining system calls into one rule whenever possible. diff --git a/linux_os/guide/auditing/auditd_configure_rules/audit_privileged_commands/audit_rules_privileged_commands_sudo/policy/stig/shared.yml b/linux_os/guide/auditing/auditd_configure_rules/audit_privileged_commands/audit_rules_privileged_commands_sudo/policy/stig/shared.yml index c3086d03bca1..c1525b22d5cf 100644 --- a/linux_os/guide/auditing/auditd_configure_rules/audit_privileged_commands/audit_rules_privileged_commands_sudo/policy/stig/shared.yml +++ b/linux_os/guide/auditing/auditd_configure_rules/audit_privileged_commands/audit_rules_privileged_commands_sudo/policy/stig/shared.yml @@ -2,13 +2,13 @@ srg_requirement: |- {{{ full_name }}} must audit all uses of the sudo command. vuldiscussion: |- - 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. + Without generating audit record 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). - 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. + When a user logs on, the auid is set to the uid of the account 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. - The system call rules are loaded into a matching engine that intercepts each syscall made by all programs on the system. Therefore, it is very important to use syscall rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining syscalls into one rule whenever possible. + The system call rules are loaded into a matching engine that intercepts each system call made by all programs on the system. Therefore, it is very important to use system call rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining system calls into one rule whenever possible. checktext: |- Verify that {{{ full_name }}} is configured to audit the execution of the "sudo" command with the following command: @@ -26,11 +26,3 @@ fixtext: |- The audit daemon must be restarted for the changes to take effect. -vuln_discussion: |- - Without generating audit record 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). - - When a user logs on, the auid is set to the uid of the account 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. - - The system call rules are loaded into a matching engine that intercepts each system call made by all programs on the system. Therefore, it is very important to use system call rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining system calls into one rule whenever possible. diff --git a/linux_os/guide/auditing/auditd_configure_rules/audit_privileged_commands/audit_rules_privileged_commands_sudoedit/policy/stig/shared.yml b/linux_os/guide/auditing/auditd_configure_rules/audit_privileged_commands/audit_rules_privileged_commands_sudoedit/policy/stig/shared.yml index 80206949bab7..94318fdb3439 100644 --- a/linux_os/guide/auditing/auditd_configure_rules/audit_privileged_commands/audit_rules_privileged_commands_sudoedit/policy/stig/shared.yml +++ b/linux_os/guide/auditing/auditd_configure_rules/audit_privileged_commands/audit_rules_privileged_commands_sudoedit/policy/stig/shared.yml @@ -2,13 +2,13 @@ srg_requirement: |- {{{ full_name }}} must audit all uses of the sudoedit command. vuldiscussion: |- - 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. + Without generating audit record 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). - 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. + When a user logs on, the auid is set to the uid of the account 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. - The system call rules are loaded into a matching engine that intercepts each syscall made by all programs on the system. Therefore, it is very important to use syscall rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining syscalls into one rule whenever possible. + The system call rules are loaded into a matching engine that intercepts each system call made by all programs on the system. Therefore, it is very important to use system call rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining system calls into one rule whenever possible. checktext: |- Verify that {{{ full_name }}} is configured to audit the execution of the "sudoedit" command with the following command: @@ -26,11 +26,3 @@ fixtext: |- The audit daemon must be restarted for the changes to take effect. -vuln_discussion: |- - Without generating audit record 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). - - When a user logs on, the auid is set to the uid of the account 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. - - The system call rules are loaded into a matching engine that intercepts each system call made by all programs on the system. Therefore, it is very important to use system call rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining system calls into one rule whenever possible. diff --git a/linux_os/guide/auditing/auditd_configure_rules/audit_privileged_commands/audit_rules_privileged_commands_umount/policy/stig/shared.yml b/linux_os/guide/auditing/auditd_configure_rules/audit_privileged_commands/audit_rules_privileged_commands_umount/policy/stig/shared.yml index 374b5fe8490a..6a51d39859a5 100644 --- a/linux_os/guide/auditing/auditd_configure_rules/audit_privileged_commands/audit_rules_privileged_commands_umount/policy/stig/shared.yml +++ b/linux_os/guide/auditing/auditd_configure_rules/audit_privileged_commands/audit_rules_privileged_commands_umount/policy/stig/shared.yml @@ -2,13 +2,13 @@ srg_requirement: |- {{{ full_name }}} must audit all uses of umount system calls. vuldiscussion: |- - 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. + Without generating audit records 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). - 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. + When a user logs on, the auid is set to the uid of the account 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. - The system call rules are loaded into a matching engine that intercepts each syscall made by all programs on the system. Therefore, it is very important to use syscall rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining syscalls into one rule whenever possible. + The system call rules are loaded into a matching engine that intercepts each system call made by all programs on the system. Therefore, it is very important to use system call rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining system calls into one rule whenever possible. checktext: |- Verify that {{{ full_name }}} is configured to audit the execution of the "umount" command with the following command: @@ -26,11 +26,3 @@ fixtext: |- The audit daemon must be restarted for the changes to take effect. -vuln_discussion: |- - Without generating audit records 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). - - When a user logs on, the auid is set to the uid of the account 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. - - The system call rules are loaded into a matching engine that intercepts each system call made by all programs on the system. Therefore, it is very important to use system call rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining system calls into one rule whenever possible. diff --git a/linux_os/guide/auditing/auditd_configure_rules/audit_privileged_commands/audit_rules_privileged_commands_unix_chkpwd/policy/stig/shared.yml b/linux_os/guide/auditing/auditd_configure_rules/audit_privileged_commands/audit_rules_privileged_commands_unix_chkpwd/policy/stig/shared.yml index 515e14672046..854aa6f6fd93 100644 --- a/linux_os/guide/auditing/auditd_configure_rules/audit_privileged_commands/audit_rules_privileged_commands_unix_chkpwd/policy/stig/shared.yml +++ b/linux_os/guide/auditing/auditd_configure_rules/audit_privileged_commands/audit_rules_privileged_commands_unix_chkpwd/policy/stig/shared.yml @@ -2,13 +2,13 @@ srg_requirement: |- {{{ full_name }}} must audit all uses of the unix_chkpwd command. vuldiscussion: |- - 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. + Without generating audit record 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). - 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. + When a user logs on, the auid is set to the uid of the account 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. - The system call rules are loaded into a matching engine that intercepts each syscall made by all programs on the system. Therefore, it is very important to use syscall rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining syscalls into one rule whenever possible. + The system call rules are loaded into a matching engine that intercepts each system call made by all programs on the system. Therefore, it is very important to use system call rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining system calls into one rule whenever possible. checktext: |- Verify that {{{ full_name }}} is configured to audit the execution of the "unix_chkpwd" command with the following command: @@ -26,11 +26,3 @@ fixtext: |- The audit daemon must be restarted for the changes to take effect. -vuln_discussion: |- - Without generating audit record 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). - - When a user logs on, the auid is set to the uid of the account 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. - - The system call rules are loaded into a matching engine that intercepts each system call made by all programs on the system. Therefore, it is very important to use system call rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining system calls into one rule whenever possible. diff --git a/linux_os/guide/auditing/auditd_configure_rules/audit_privileged_commands/audit_rules_privileged_commands_unix_update/policy/stig/shared.yml b/linux_os/guide/auditing/auditd_configure_rules/audit_privileged_commands/audit_rules_privileged_commands_unix_update/policy/stig/shared.yml index b51729117cf5..5161eccf8077 100644 --- a/linux_os/guide/auditing/auditd_configure_rules/audit_privileged_commands/audit_rules_privileged_commands_unix_update/policy/stig/shared.yml +++ b/linux_os/guide/auditing/auditd_configure_rules/audit_privileged_commands/audit_rules_privileged_commands_unix_update/policy/stig/shared.yml @@ -2,13 +2,13 @@ srg_requirement: |- {{{ full_name }}} must audit all uses of the unix_update command. vuldiscussion: |- - 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. + Without generating audit record 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). - 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. + When a user logs on, the auid is set to the uid of the account 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. - The system call rules are loaded into a matching engine that intercepts each syscall made by all programs on the system. Therefore, it is very important to use syscall rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining syscalls into one rule whenever possible. + The system call rules are loaded into a matching engine that intercepts each system call made by all programs on the system. Therefore, it is very important to use system call rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining system calls into one rule whenever possible. checktext: |- Verify that {{{ full_name }}} is configured to audit the execution of the "unix_update" command with the following command: @@ -26,11 +26,3 @@ fixtext: |- The audit daemon must be restarted for the changes to take effect. -vuln_discussion: |- - Without generating audit record 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). - - When a user logs on, the auid is set to the uid of the account 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. - - The system call rules are loaded into a matching engine that intercepts each system call made by all programs on the system. Therefore, it is very important to use system call rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining system calls into one rule whenever possible. diff --git a/linux_os/guide/auditing/auditd_configure_rules/audit_privileged_commands/audit_rules_privileged_commands_userhelper/policy/stig/shared.yml b/linux_os/guide/auditing/auditd_configure_rules/audit_privileged_commands/audit_rules_privileged_commands_userhelper/policy/stig/shared.yml index 0fb6f36f7bde..f12e573f86aa 100644 --- a/linux_os/guide/auditing/auditd_configure_rules/audit_privileged_commands/audit_rules_privileged_commands_userhelper/policy/stig/shared.yml +++ b/linux_os/guide/auditing/auditd_configure_rules/audit_privileged_commands/audit_rules_privileged_commands_userhelper/policy/stig/shared.yml @@ -2,13 +2,13 @@ srg_requirement: |- {{{ full_name }}} must audit all uses of the userhelper command. vuldiscussion: |- - 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. + Without generating audit record 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). - 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. + When a user logs on, the auid is set to the uid of the account 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. - The system call rules are loaded into a matching engine that intercepts each syscall made by all programs on the system. Therefore, it is very important to use syscall rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining syscalls into one rule whenever possible. + The system call rules are loaded into a matching engine that intercepts each system call made by all programs on the system. Therefore, it is very important to use system call rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining system calls into one rule whenever possible. checktext: |- Verify that {{{ full_name }}} is configured to audit the execution of the "userhelper" command with the following command: @@ -26,11 +26,3 @@ fixtext: |- The audit daemon must be restarted for the changes to take effect. -vuln_discussion: |- - Without generating audit record 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). - - When a user logs on, the auid is set to the uid of the account 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. - - The system call rules are loaded into a matching engine that intercepts each system call made by all programs on the system. Therefore, it is very important to use system call rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining system calls into one rule whenever possible. diff --git a/linux_os/guide/auditing/auditd_configure_rules/audit_privileged_commands/audit_rules_privileged_commands_usermod/policy/stig/shared.yml b/linux_os/guide/auditing/auditd_configure_rules/audit_privileged_commands/audit_rules_privileged_commands_usermod/policy/stig/shared.yml index 82f15b4154ac..df8ac4aebe77 100644 --- a/linux_os/guide/auditing/auditd_configure_rules/audit_privileged_commands/audit_rules_privileged_commands_usermod/policy/stig/shared.yml +++ b/linux_os/guide/auditing/auditd_configure_rules/audit_privileged_commands/audit_rules_privileged_commands_usermod/policy/stig/shared.yml @@ -2,13 +2,13 @@ srg_requirement: |- {{{ full_name }}} must audit all uses of the usermod command. vuldiscussion: |- - 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. + Without generating audit record 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). - 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. + When a user logs on, the auid is set to the uid of the account 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. - The system call rules are loaded into a matching engine that intercepts each syscall made by all programs on the system. Therefore, it is very important to use syscall rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining syscalls into one rule whenever possible. + The system call rules are loaded into a matching engine that intercepts each system call made by all programs on the system. Therefore, it is very important to use system call rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining system calls into one rule whenever possible. checktext: |- Verify that {{{ full_name }}} is configured to audit the execution of the "usermod" command with the following command: @@ -26,11 +26,3 @@ fixtext: |- The audit daemon must be restarted for the changes to take effect. -vuln_discussion: |- - Without generating audit record 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). - - When a user logs on, the auid is set to the uid of the account 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. - - The system call rules are loaded into a matching engine that intercepts each system call made by all programs on the system. Therefore, it is very important to use system call rules only when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance can be helped, however, by combining system calls into one rule whenever possible. diff --git a/linux_os/guide/auditing/auditd_configure_rules/audit_rules_immutable/policy/stig/shared.yml b/linux_os/guide/auditing/auditd_configure_rules/audit_rules_immutable/policy/stig/shared.yml index 25dc71a27ff6..b248934be62f 100644 --- a/linux_os/guide/auditing/auditd_configure_rules/audit_rules_immutable/policy/stig/shared.yml +++ b/linux_os/guide/auditing/auditd_configure_rules/audit_rules_immutable/policy/stig/shared.yml @@ -6,7 +6,7 @@ vuldiscussion: |- Audit information includes all information (e.g., audit records, audit settings, audit reports) needed to successfully audit {{{ full_name }}} 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. + 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. checktext: |- Verify the audit system prevents unauthorized changes with the following command: @@ -24,9 +24,3 @@ fixtext: |- The audit daemon must be restarted for the changes to take effect. -vuln_discussion: |- - 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 {{{ full_name }}} 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. diff --git a/linux_os/guide/auditing/auditd_configure_rules/audit_rules_immutable_login_uids/policy/stig/shared.yml b/linux_os/guide/auditing/auditd_configure_rules/audit_rules_immutable_login_uids/policy/stig/shared.yml index 21eab79b679b..0c5b37628419 100644 --- a/linux_os/guide/auditing/auditd_configure_rules/audit_rules_immutable_login_uids/policy/stig/shared.yml +++ b/linux_os/guide/auditing/auditd_configure_rules/audit_rules_immutable_login_uids/policy/stig/shared.yml @@ -17,5 +17,3 @@ checktext: |- If the "--loginuid-immutable" option is not returned in the "/etc/audit/audit.rules", or the line is commented out, this is a finding. -vuln_discussion: |- - If modification of login user identifiers (UIDs) is not prevented, they can be changed by nonprivileged users and make auditing complicated or impossible. diff --git a/linux_os/guide/auditing/auditd_configure_rules/audit_rules_sudoers/policy/stig/shared.yml b/linux_os/guide/auditing/auditd_configure_rules/audit_rules_sudoers/policy/stig/shared.yml index 71de65b11296..25f30dc5b4da 100644 --- a/linux_os/guide/auditing/auditd_configure_rules/audit_rules_sudoers/policy/stig/shared.yml +++ b/linux_os/guide/auditing/auditd_configure_rules/audit_rules_sudoers/policy/stig/shared.yml @@ -2,11 +2,7 @@ srg_requirement: |- {{{ full_name }}} must generate audit records for all account creations, modifications, disabling, and termination events that affect /etc/sudoers. vuldiscussion: |- - The actions taken by system administrators should be audited to keep a record - of what was executed on the system, as well as, for accountability purposes. - Editing the sudoers file may be sign of an attacker trying to - establish persistent methods to a system, auditing the editing of the sudoers - files mitigates this risk. + The actions taken by system administrators must be audited to keep a record of what was executed on the system, as well as for accountability purposes. Editing the sudoers file may be sign of an attacker trying to establish persistent methods to a system, auditing the editing of the sudoers files mitigates this risk. checktext: |- Verify {{{ full_name }}} generates audit records for all account creations, modifications, disabling, and termination events that affect "/etc/sudoers" with the following command: @@ -26,5 +22,3 @@ fixtext: |- The audit daemon must be restarted for the changes to take effect. -vuln_discussion: |- - The actions taken by system administrators must be audited to keep a record of what was executed on the system, as well as for accountability purposes. Editing the sudoers file may be sign of an attacker trying to establish persistent methods to a system, auditing the editing of the sudoers files mitigates this risk. diff --git a/linux_os/guide/auditing/auditd_configure_rules/audit_rules_sudoers_d/policy/stig/shared.yml b/linux_os/guide/auditing/auditd_configure_rules/audit_rules_sudoers_d/policy/stig/shared.yml index d6048cec4d9b..2c1ffe65dc9b 100644 --- a/linux_os/guide/auditing/auditd_configure_rules/audit_rules_sudoers_d/policy/stig/shared.yml +++ b/linux_os/guide/auditing/auditd_configure_rules/audit_rules_sudoers_d/policy/stig/shared.yml @@ -2,11 +2,7 @@ srg_requirement: |- {{{ full_name }}} must generate audit records for all account creations, modifications, disabling, and termination events that affect /etc/sudoers.d/ directory. vuldiscussion: |- - The actions taken by system administrators should be audited to keep a record - of what was executed on the system, as well as, for accountability purposes. - Editing the sudoers file may be sign of an attacker trying to - establish persistent methods to a system, auditing the editing of the sudoers - files mitigates this risk. + The actions taken by system administrators must be audited to keep a record of what was executed on the system, as well as for accountability purposes. Editing the sudoers file may be sign of an attacker trying to establish persistent methods to a system, auditing the editing of the sudoers files mitigates this risk. checktext: |- Verify {{{ full_name }}} generates audit records for all account creations, modifications, disabling, and termination events that affect "/etc/sudoers.d/" with the following command: @@ -26,5 +22,3 @@ fixtext: |- The audit daemon must be restarted for the changes to take effect. -vuln_discussion: |- - The actions taken by system administrators must be audited to keep a record of what was executed on the system, as well as for accountability purposes. Editing the sudoers file may be sign of an attacker trying to establish persistent methods to a system, auditing the editing of the sudoers files mitigates this risk. diff --git a/linux_os/guide/auditing/auditd_configure_rules/audit_rules_suid_privilege_function/policy/stig/shared.yml b/linux_os/guide/auditing/auditd_configure_rules/audit_rules_suid_privilege_function/policy/stig/shared.yml index ed6d75dc8477..1b415a90807f 100644 --- a/linux_os/guide/auditing/auditd_configure_rules/audit_rules_suid_privilege_function/policy/stig/shared.yml +++ b/linux_os/guide/auditing/auditd_configure_rules/audit_rules_suid_privilege_function/policy/stig/shared.yml @@ -2,12 +2,7 @@ srg_requirement: |- {{{ full_name }}} must audit uses of the "execve" system call. vuldiscussion: |- - Misuse of privileged functions, either intentionally or unintentionally by - authorized users, or by unauthorized external entities that have - compromised information system accounts, is a serious and ongoing concern - and can have significant adverse impacts on organizations. Auditing the use - of privileged functions is one way to detect such misuse and identify the - risk from insider threats and the advanced persistent threat. + Misuse of privileged functions, either intentionally or unintentionally by authorized users, or by unauthorized external entities that have compromised information system accounts, is a serious and ongoing concern and can have significant adverse impacts on organizations. Auditing the use of privileged functions is one way to detect such misuse and identify the risk from insider threats and the advanced persistent threat. checktext: |- Verify that {{{ full_name }}} is configured to audit the execution of the "execve" system call with the following command: @@ -33,5 +28,3 @@ fixtext: |- The audit daemon must be restarted for the changes to take effect. -vuln_discussion: |- - Misuse of privileged functions, either intentionally or unintentionally by authorized users, or by unauthorized external entities that have compromised information system accounts, is a serious and ongoing concern and can have significant adverse impacts on organizations. Auditing the use of privileged functions is one way to detect such misuse and identify the risk from insider threats and the advanced persistent threat. diff --git a/linux_os/guide/auditing/auditd_configure_rules/audit_rules_system_shutdown/policy/stig/shared.yml b/linux_os/guide/auditing/auditd_configure_rules/audit_rules_system_shutdown/policy/stig/shared.yml index ab0df3f66ffe..2430ebb43f9b 100644 --- a/linux_os/guide/auditing/auditd_configure_rules/audit_rules_system_shutdown/policy/stig/shared.yml +++ b/linux_os/guide/auditing/auditd_configure_rules/audit_rules_system_shutdown/policy/stig/shared.yml @@ -2,8 +2,9 @@ srg_requirement: |- {{{ full_name }}} must take appropriate action when a critical audit processing failure occurs. vuldiscussion: |- - It is critical for the appropriate personnel to be aware if a systemis at risk of failing to process audit logs as required. Without thisnotification, the security personnel may be unaware of an impending failure ofthe audit capability, and system operation may be adversely affected. - Audit processing failures include software/hardware errors, failures in theaudit capturing mechanisms, and audit storage capacity being reached orexceeded. + 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. checktext: |- Verify the audit service is configured to panic on a critical error with the following command: @@ -21,7 +22,3 @@ fixtext: |- -f 2 -vuln_discussion: |- - 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. diff --git a/linux_os/guide/auditing/auditd_configure_rules/audit_rules_usergroup_modification_group/policy/stig/shared.yml b/linux_os/guide/auditing/auditd_configure_rules/audit_rules_usergroup_modification_group/policy/stig/shared.yml index ee6de6c628cf..692a47664bea 100644 --- a/linux_os/guide/auditing/auditd_configure_rules/audit_rules_usergroup_modification_group/policy/stig/shared.yml +++ b/linux_os/guide/auditing/auditd_configure_rules/audit_rules_usergroup_modification_group/policy/stig/shared.yml @@ -2,9 +2,7 @@ srg_requirement: |- {{{ full_name }}} must generate audit records for all account creations, modifications, disabling, and termination events that affect /etc/group. vuldiscussion: |- - In addition to auditing new user and group accounts, these watches - will alert the system administrator(s) to any modifications. Any unexpected - users, groups, or modifications should be investigated for legitimacy. + In addition to auditing new user and group accounts, these watches will alert the system administrator(s) to any modifications. Any unexpected users, groups, or modifications must be investigated for legitimacy. checktext: |- Verify {{{ full_name }}} generates audit records for all account creations, modifications, disabling, and termination events that affect "/etc/group" with the following command: @@ -24,5 +22,3 @@ fixtext: |- The audit daemon must be restarted for the changes to take effect. -vuln_discussion: |- - In addition to auditing new user and group accounts, these watches will alert the system administrator(s) to any modifications. Any unexpected users, groups, or modifications must be investigated for legitimacy. diff --git a/linux_os/guide/auditing/auditd_configure_rules/audit_rules_usergroup_modification_gshadow/policy/stig/shared.yml b/linux_os/guide/auditing/auditd_configure_rules/audit_rules_usergroup_modification_gshadow/policy/stig/shared.yml index 9c3b605b22fc..e8b774d5cded 100644 --- a/linux_os/guide/auditing/auditd_configure_rules/audit_rules_usergroup_modification_gshadow/policy/stig/shared.yml +++ b/linux_os/guide/auditing/auditd_configure_rules/audit_rules_usergroup_modification_gshadow/policy/stig/shared.yml @@ -2,9 +2,7 @@ srg_requirement: |- {{{ full_name }}} must generate audit records for all account creations, modifications, disabling, and termination events that affect /etc/gshadow. vuldiscussion: |- - In addition to auditing new user and group accounts, these watches - will alert the system administrator(s) to any modifications. Any unexpected - users, groups, or modifications should be investigated for legitimacy. + In addition to auditing new user and group accounts, these watches will alert the system administrator(s) to any modifications. Any unexpected users, groups, or modifications should be investigated for legitimacy. checktext: |- Verify {{{ full_name }}} generates audit records for all account creations, modifications, disabling, and termination events that affect "/etc/gshadow" with the following command: @@ -24,5 +22,3 @@ fixtext: |- The audit daemon must be restarted for the changes to take effect. -vuln_discussion: |- - In addition to auditing new user and group accounts, these watches will alert the system administrator(s) to any modifications. Any unexpected users, groups, or modifications should be investigated for legitimacy. diff --git a/linux_os/guide/auditing/auditd_configure_rules/audit_rules_usergroup_modification_opasswd/policy/stig/shared.yml b/linux_os/guide/auditing/auditd_configure_rules/audit_rules_usergroup_modification_opasswd/policy/stig/shared.yml index 8fe387b85b2f..d5191a8c7410 100644 --- a/linux_os/guide/auditing/auditd_configure_rules/audit_rules_usergroup_modification_opasswd/policy/stig/shared.yml +++ b/linux_os/guide/auditing/auditd_configure_rules/audit_rules_usergroup_modification_opasswd/policy/stig/shared.yml @@ -2,9 +2,7 @@ srg_requirement: |- {{{ full_name }}} must generate audit records for all account creations, modifications, disabling, and termination events that affect /etc/opasswd. vuldiscussion: |- - In addition to auditing new user and group accounts, these watches - will alert the system administrator(s) to any modifications. Any unexpected - users, groups, or modifications should be investigated for legitimacy. + In addition to auditing new user and group accounts, these watches will alert the system administrator(s) to any modifications. Any unexpected users, groups, or modifications should be investigated for legitimacy. checktext: |- Verify {{{ full_name }}} generates audit records for all account creations, modifications, disabling, and termination events that affect "/etc/security/opasswd" with the following command: @@ -24,5 +22,3 @@ fixtext: |- The audit daemon must be restarted for the changes to take effect. -vuln_discussion: |- - In addition to auditing new user and group accounts, these watches will alert the system administrator(s) to any modifications. Any unexpected users, groups, or modifications should be investigated for legitimacy. diff --git a/linux_os/guide/auditing/auditd_configure_rules/audit_rules_usergroup_modification_passwd/policy/stig/shared.yml b/linux_os/guide/auditing/auditd_configure_rules/audit_rules_usergroup_modification_passwd/policy/stig/shared.yml index 5905bd76db8b..e8b77c57d5b7 100644 --- a/linux_os/guide/auditing/auditd_configure_rules/audit_rules_usergroup_modification_passwd/policy/stig/shared.yml +++ b/linux_os/guide/auditing/auditd_configure_rules/audit_rules_usergroup_modification_passwd/policy/stig/shared.yml @@ -2,9 +2,7 @@ srg_requirement: |- {{{ full_name }}} must generate audit records for all account creations, modifications, disabling, and termination events that affect /etc/passwd. vuldiscussion: |- - In addition to auditing new user and group accounts, these watches - will alert the system administrator(s) to any modifications. Any unexpected - users, groups, or modifications should be investigated for legitimacy. + In addition to auditing new user and group accounts, these watches will alert the system administrator(s) to any modifications. Any unexpected users, groups, or modifications should be investigated for legitimacy. checktext: |- Verify {{{ full_name }}} generates audit records for all account creations, modifications, disabling, and termination events that affect "/etc/passwd" with the following command: @@ -24,5 +22,3 @@ fixtext: |- The audit daemon must be restarted for the changes to take effect. -vuln_discussion: |- - In addition to auditing new user and group accounts, these watches will alert the system administrator(s) to any modifications. Any unexpected users, groups, or modifications should be investigated for legitimacy. diff --git a/linux_os/guide/auditing/auditd_configure_rules/audit_rules_usergroup_modification_shadow/policy/stig/shared.yml b/linux_os/guide/auditing/auditd_configure_rules/audit_rules_usergroup_modification_shadow/policy/stig/shared.yml index dc85f577d110..80c339197973 100644 --- a/linux_os/guide/auditing/auditd_configure_rules/audit_rules_usergroup_modification_shadow/policy/stig/shared.yml +++ b/linux_os/guide/auditing/auditd_configure_rules/audit_rules_usergroup_modification_shadow/policy/stig/shared.yml @@ -2,9 +2,7 @@ srg_requirement: |- {{{ full_name }}} must generate audit records for all account creations, modifications, disabling, and termination events that affect /etc/shadow. vuldiscussion: |- - In addition to auditing new user and group accounts, these watches - will alert the system administrator(s) to any modifications. Any unexpected - users, groups, or modifications should be investigated for legitimacy. + In addition to auditing new user and group accounts, these watches will alert the system administrator(s) to any modifications. Any unexpected users, groups, or modifications should be investigated for legitimacy. checktext: |- Verify {{{ full_name }}} generates audit records for all account creations, modifications, disabling, and termination events that affect "/etc/passwd with the following command: @@ -24,5 +22,3 @@ fixtext: |- The audit daemon must be restarted for the changes to take effect. -vuln_discussion: |- - In addition to auditing new user and group accounts, these watches will alert the system administrator(s) to any modifications. Any unexpected users, groups, or modifications should be investigated for legitimacy. diff --git a/linux_os/guide/auditing/auditd_configure_rules/directory_group_ownership_var_log_audit/policy/stig/shared.yml b/linux_os/guide/auditing/auditd_configure_rules/directory_group_ownership_var_log_audit/policy/stig/shared.yml index 2749f4bf51af..ef7cee753fbd 100644 --- a/linux_os/guide/auditing/auditd_configure_rules/directory_group_ownership_var_log_audit/policy/stig/shared.yml +++ b/linux_os/guide/auditing/auditd_configure_rules/directory_group_ownership_var_log_audit/policy/stig/shared.yml @@ -36,5 +36,3 @@ fixtext: |- $ sudo chgrp ${GROUP} /var/log/audit -vuln_discussion: |- - Unauthorized disclosure of audit records can reveal system and configuration data to attackers, thus compromising its confidentiality. diff --git a/linux_os/guide/auditing/auditd_configure_rules/directory_ownership_var_log_audit/policy/stig/shared.yml b/linux_os/guide/auditing/auditd_configure_rules/directory_ownership_var_log_audit/policy/stig/shared.yml index c315c0be692b..e44c7a254a4f 100644 --- a/linux_os/guide/auditing/auditd_configure_rules/directory_ownership_var_log_audit/policy/stig/shared.yml +++ b/linux_os/guide/auditing/auditd_configure_rules/directory_ownership_var_log_audit/policy/stig/shared.yml @@ -26,5 +26,3 @@ fixtext: |- $ sudo chown root /var/log/audit -vuln_discussion: |- - Unauthorized disclosure of audit records can reveal system and configuration data to attackers, thus compromising its confidentiality. diff --git a/linux_os/guide/auditing/auditd_configure_rules/file_permissions_var_log_audit/policy/stig/shared.yml b/linux_os/guide/auditing/auditd_configure_rules/file_permissions_var_log_audit/policy/stig/shared.yml index fc2d9aa2b2a5..caa3ec8f0da6 100644 --- a/linux_os/guide/auditing/auditd_configure_rules/file_permissions_var_log_audit/policy/stig/shared.yml +++ b/linux_os/guide/auditing/auditd_configure_rules/file_permissions_var_log_audit/policy/stig/shared.yml @@ -44,7 +44,3 @@ fixtext: |- $ sudo chmod 0600 $log_file $ sudo chmod 0400 $log_file.* -vuln_discussion: |- - 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 {{{ full_name }}} 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. diff --git a/linux_os/guide/auditing/configure_auditd_data_retention/auditd_audispd_configure_sufficiently_large_partition/policy/stig/shared.yml b/linux_os/guide/auditing/configure_auditd_data_retention/auditd_audispd_configure_sufficiently_large_partition/policy/stig/shared.yml index db33c8be5a29..d2f344962c75 100644 --- a/linux_os/guide/auditing/configure_auditd_data_retention/auditd_audispd_configure_sufficiently_large_partition/policy/stig/shared.yml +++ b/linux_os/guide/auditing/configure_auditd_data_retention/auditd_audispd_configure_sufficiently_large_partition/policy/stig/shared.yml @@ -30,7 +30,3 @@ fixtext: |- If audit records are not stored on a partition made specifically for audit records, a new partition with sufficient space will need be to be created. -vuln_discussion: |- - To ensure {{{ full_name }}} systems have a sufficient storage capacity in which to write the audit logs, {{{ full_name }}} needs to be able to allocate audit record storage capacity. - - The task of allocating audit record storage capacity is usually performed during initial installation of {{{ full_name }}}. diff --git a/linux_os/guide/auditing/configure_auditd_data_retention/auditd_audispd_syslog_plugin_activated/policy/stig/shared.yml b/linux_os/guide/auditing/configure_auditd_data_retention/auditd_audispd_syslog_plugin_activated/policy/stig/shared.yml index b659046c1904..c3e0512ab18e 100644 --- a/linux_os/guide/auditing/configure_auditd_data_retention/auditd_audispd_syslog_plugin_activated/policy/stig/shared.yml +++ b/linux_os/guide/auditing/configure_auditd_data_retention/auditd_audispd_syslog_plugin_activated/policy/stig/shared.yml @@ -17,5 +17,3 @@ checktext: |- If the "active" keyword does not have a value of "yes", the line is commented out, or the line is missing, this is a finding. -vuln_discussion: |- - The auditd service does not include the ability to send audit records to a centralized server for management directly. However, it can use a plug-in for audit event multiplexor (audispd) to pass audit records to the local syslog server. diff --git a/linux_os/guide/auditing/configure_auditd_data_retention/auditd_local_events/policy/stig/shared.yml b/linux_os/guide/auditing/configure_auditd_data_retention/auditd_local_events/policy/stig/shared.yml index 230539c5a777..fe544a1e59d8 100644 --- a/linux_os/guide/auditing/configure_auditd_data_retention/auditd_local_events/policy/stig/shared.yml +++ b/linux_os/guide/auditing/configure_auditd_data_retention/auditd_local_events/policy/stig/shared.yml @@ -22,7 +22,3 @@ fixtext: |- The audit daemon must be restarted for the changes to take effect. -vuln_discussion: |- - 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. - - If option "local_events" isn't set to "yes" only events from network will be aggregated. diff --git a/linux_os/guide/auditing/configure_auditd_data_retention/auditd_log_format/policy/stig/shared.yml b/linux_os/guide/auditing/configure_auditd_data_retention/auditd_log_format/policy/stig/shared.yml index 9dea464e9a92..d43021445b12 100644 --- a/linux_os/guide/auditing/configure_auditd_data_retention/auditd_log_format/policy/stig/shared.yml +++ b/linux_os/guide/auditing/configure_auditd_data_retention/auditd_log_format/policy/stig/shared.yml @@ -6,7 +6,7 @@ vuldiscussion: |- 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. + 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. checktext: |- Verify that {{{ full_name }}} audit system is configured to resolve audit information before writing to disk, with the following command: @@ -24,9 +24,3 @@ fixtext: |- The audit daemon must be restarted for changes to take effect. -vuln_discussion: |- - 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. diff --git a/linux_os/guide/auditing/configure_auditd_data_retention/auditd_overflow_action/policy/stig/shared.yml b/linux_os/guide/auditing/configure_auditd_data_retention/auditd_overflow_action/policy/stig/shared.yml index 6808bd08712c..29bc255e2292 100644 --- a/linux_os/guide/auditing/configure_auditd_data_retention/auditd_overflow_action/policy/stig/shared.yml +++ b/linux_os/guide/auditing/configure_auditd_data_retention/auditd_overflow_action/policy/stig/shared.yml @@ -2,10 +2,9 @@ srg_requirement: |- {{{ full_name }}} must take appropriate action when the internal event queue is full. vuldiscussion: |- - The audit system should have an action setup in the event the internal event queue becomes full - so that no data is lost.Information stored in one location is vulnerable to accidental or incidental deletion or alteration. + The audit system should have an action setup in the event the internal event queue becomes full so that no data is lost. Information stored in one location is vulnerable to accidental or incidental deletion or alteration. - Off-loading is a common process in information systems with limited audit storage capacity. + Offloading is a common process in information systems with limited audit storage capacity. checktext: |- Verify that {{{ full_name }}} audit system is configured to take an appropriate action when the internal event queue is full: @@ -25,7 +24,3 @@ fixtext: |- The audit daemon must be restarted for changes to take effect. -vuln_discussion: |- - The audit system should have an action setup in the event the internal event queue becomes full so that no data is lost. 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. diff --git a/linux_os/guide/auditing/configure_auditd_data_retention/auditd_write_logs/policy/stig/shared.yml b/linux_os/guide/auditing/configure_auditd_data_retention/auditd_write_logs/policy/stig/shared.yml index f1b07b0732e5..f5ebf21e2a5d 100644 --- a/linux_os/guide/auditing/configure_auditd_data_retention/auditd_write_logs/policy/stig/shared.yml +++ b/linux_os/guide/auditing/configure_auditd_data_retention/auditd_write_logs/policy/stig/shared.yml @@ -2,8 +2,7 @@ srg_requirement: |- {{{ full_name }}} must write audit records to disk. vuldiscussion: |- - Audit data should be synchronously written to disk to ensure - log integrity. This setting assures that all audit event data is written disk. + Audit data should be synchronously written to disk to ensure log integrity. This setting assures that all audit event data is written disk. checktext: |- Verify that the audit system is configured to write logs to the disk with the following command: @@ -23,5 +22,3 @@ fixtext: |- The audit daemon must be restarted for changes to take effect. -vuln_discussion: |- - Audit data should be synchronously written to disk to ensure log integrity. This setting assures that all audit event data is written disk. diff --git a/linux_os/guide/auditing/grub2_audit_argument/policy/stig/shared.yml b/linux_os/guide/auditing/grub2_audit_argument/policy/stig/shared.yml index ead6e0b865cb..6170f7362934 100644 --- a/linux_os/guide/auditing/grub2_audit_argument/policy/stig/shared.yml +++ b/linux_os/guide/auditing/grub2_audit_argument/policy/stig/shared.yml @@ -34,7 +34,3 @@ fixtext: |- GRUB_CMDLINE_LINUX="audit=1" -vuln_discussion: |- - Without the capability to generate audit records, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. - - If auditing is enabled late in the startup process, the actions of some startup processes may not be audited. Some audit systems also maintain state information only available if auditing is enabled before a given process is created. diff --git a/linux_os/guide/auditing/grub2_audit_backlog_limit_argument/policy/stig/shared.yml b/linux_os/guide/auditing/grub2_audit_backlog_limit_argument/policy/stig/shared.yml index 09d39a96ea7a..97432a645b62 100644 --- a/linux_os/guide/auditing/grub2_audit_backlog_limit_argument/policy/stig/shared.yml +++ b/linux_os/guide/auditing/grub2_audit_backlog_limit_argument/policy/stig/shared.yml @@ -8,7 +8,7 @@ vuldiscussion: |- Audit records can be generated from various components within the information system (e.g., module or policy filter). - Allocating an audit_backlog_limit of sufficient size is critical in maintaining a stable boot process. With an insufficient limit allocated, the system is susceptible to boot failures and crashes. + Allocating an audit_backlog_limit of sufficient size is critical in maintaining a stable boot process. With an insufficient limit allocated, the system is susceptible to boot failures and crashes. checktext: |- Verify {{{ full_name }}} allocates a sufficient audit_backlog_limit to capture processes that start prior to the audit daemon with the following command: @@ -22,11 +22,3 @@ fixtext: |- $ sudo grubby --update-kernel=ALL --args=audit_backlog_limit=8192 -vuln_discussion: |- - Without the capability to generate audit records, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. - - If auditing is enabled late in the startup process, the actions of some startup processes may not be audited. Some audit systems also maintain state information only available if auditing is enabled before a given process is created. - - Audit records can be generated from various components within the information system (e.g., module or policy filter). - - Allocating an audit_backlog_limit of sufficient size is critical in maintaining a stable boot process. With an insufficient limit allocated, the system is susceptible to boot failures and crashes. diff --git a/linux_os/guide/auditing/package_audispd-plugins_installed/policy/stig/shared.yml b/linux_os/guide/auditing/package_audispd-plugins_installed/policy/stig/shared.yml index 98d7f1203078..93c7654cf784 100644 --- a/linux_os/guide/auditing/package_audispd-plugins_installed/policy/stig/shared.yml +++ b/linux_os/guide/auditing/package_audispd-plugins_installed/policy/stig/shared.yml @@ -2,9 +2,7 @@ srg_requirement: |- {{{ full_name }}} audispd-plugins package must be installed. vuldiscussion: |- - "audispd-plugins" provides plugins for the real-time interface to the - audit subsystem, "audispd". These plugins can do things like relay events - to remote machines or analyze events for suspicious behavior. + "audispd-plugins" provides plugins for the real-time interface to the audit subsystem, "audispd". These plugins can do things like relay events to remote machines or analyze events for suspicious behavior. fixtext: |- The audispd-plugins package can be installed with the following command: @@ -22,5 +20,3 @@ checktext: |- If the "audispd-plugins" package is not installed, this is a finding. -vuln_discussion: |- - "audispd-plugins" provides plugins for the real-time interface to the audit subsystem, "audispd". These plugins can do things like relay events to remote machines or analyze events for suspicious behavior. diff --git a/linux_os/guide/auditing/package_audit_installed/policy/stig/shared.yml b/linux_os/guide/auditing/package_audit_installed/policy/stig/shared.yml index bc4a59377ab1..ab56fcb45008 100644 --- a/linux_os/guide/auditing/package_audit_installed/policy/stig/shared.yml +++ b/linux_os/guide/auditing/package_audit_installed/policy/stig/shared.yml @@ -26,9 +26,3 @@ fixtext: |- $ sudo dnf install audit -vuln_discussion: |- - 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. - - Associating event types with detected events in audit logs provides a means of investigating an attack, recognizing resource utilization or capacity thresholds, or identifying an improperly configured {{{ full_name }}} system. diff --git a/linux_os/guide/auditing/service_auditd_enabled/policy/stig/shared.yml b/linux_os/guide/auditing/service_auditd_enabled/policy/stig/shared.yml index bd6fcac8bfba..68b78e52e4aa 100644 --- a/linux_os/guide/auditing/service_auditd_enabled/policy/stig/shared.yml +++ b/linux_os/guide/auditing/service_auditd_enabled/policy/stig/shared.yml @@ -2,16 +2,9 @@ srg_requirement: |- {{{ full_name }}} audit service must be enabled. vuldiscussion: |- - Without establishing what type of events occurred, it would be difficult - to establish, correlate, and investigate the events leading up to an outage or attack. - Ensuring the "auditd" service is active ensures audit records - generated by the kernel are appropriately recorded. - - + Without establishing what type of events occurred, it would be difficult to establish, correlate, and investigate the events leading up to an outage or attack. Ensuring the "auditd" service is active ensures audit records generated by the kernel are appropriately recorded. - Additionally, a properly configured audit subsystem ensures that actions of - individual system users can be uniquely traced to those users so they - can be held accountable for their actions. + Additionally, a properly configured audit subsystem ensures that actions of individual system users can be uniquely traced to those users so they can be held accountable for their actions. checktext: |- Verify the audit service is configured to produce audit records with the following command: @@ -29,7 +22,3 @@ fixtext: |- $ sudo systemctl enable --now auditd -vuln_discussion: |- - Without establishing what type of events occurred, it would be difficult to establish, correlate, and investigate the events leading up to an outage or attack. Ensuring the "auditd" service is active ensures audit records generated by the kernel are appropriately recorded. - - Additionally, a properly configured audit subsystem ensures that actions of individual system users can be uniquely traced to those users so they can be held accountable for their actions. diff --git a/linux_os/guide/services/base/service_kdump_disabled/policy/stig/shared.yml b/linux_os/guide/services/base/service_kdump_disabled/policy/stig/shared.yml index 577e4d46a348..3fbc3a579a66 100644 --- a/linux_os/guide/services/base/service_kdump_disabled/policy/stig/shared.yml +++ b/linux_os/guide/services/base/service_kdump_disabled/policy/stig/shared.yml @@ -2,11 +2,7 @@ srg_requirement: |- The kdump service on {{{ full_name }}} must be disabled. vuldiscussion: |- - Kernel core dumps may contain the full contents of system memory at the - time of the crash. Kernel core dumps consume a considerable amount of disk - space and may result in denial of service by exhausting the available space - on the target file system partition. Unless the system is used for kernel - development or testing, there is little need to run the kdump service. + Kernel core dumps may contain the full contents of system memory at the time of the crash. Kernel core dumps consume a considerable amount of disk space and may result in denial of service by exhausting the available space on the target file system partition. Unless the system is used for kernel development or testing, there is little need to run the kdump service. checktext: |- Verify that the kdump service is disabled in system boot configuration with the following command: @@ -42,5 +38,3 @@ fixtext: |- $ sudo systemctl mask --now kdump -vuln_discussion: |- - Kernel core dumps may contain the full contents of system memory at the time of the crash. Kernel core dumps consume a considerable amount of disk space and may result in denial of service by exhausting the available space on the target file system partition. Unless the system is used for kernel development or testing, there is little need to run the kdump service. diff --git a/linux_os/guide/services/cron_and_at/file_permissions_crontab/policy/stig/shared.yml b/linux_os/guide/services/cron_and_at/file_permissions_crontab/policy/stig/shared.yml index 663746f97c11..c62a6384a490 100644 --- a/linux_os/guide/services/cron_and_at/file_permissions_crontab/policy/stig/shared.yml +++ b/linux_os/guide/services/cron_and_at/file_permissions_crontab/policy/stig/shared.yml @@ -2,9 +2,7 @@ srg_requirement: |- {{{ full_name }}} /etc/crontab file must have mode 0600. vuldiscussion: |- - Service configuration files enable or disable features of their respective services that if configured incorrectly - can lead to insecure and vulnerable configurations. Therefore, service configuration files should have the - correct access rights to prevent unauthorized changes. + Service configuration files enable or disable features of their respective services that if configured incorrectly can lead to insecure and vulnerable configurations; therefore, service configuration files must have the correct access rights to prevent unauthorized changes. checktext: |- Verify the permissions of /etc/crontab with the following command: @@ -20,5 +18,3 @@ fixtext: |- $ sudo chmod 0600 /etc/crontab -vuln_discussion: |- - Service configuration files enable or disable features of their respective services that if configured incorrectly can lead to insecure and vulnerable configurations; therefore, service configuration files must have the correct access rights to prevent unauthorized changes. diff --git a/linux_os/guide/services/fapolicyd/package_fapolicyd_installed/policy/stig/shared.yml b/linux_os/guide/services/fapolicyd/package_fapolicyd_installed/policy/stig/shared.yml index d885733eb7c0..d29327a9a67c 100644 --- a/linux_os/guide/services/fapolicyd/package_fapolicyd_installed/policy/stig/shared.yml +++ b/linux_os/guide/services/fapolicyd/package_fapolicyd_installed/policy/stig/shared.yml @@ -2,15 +2,15 @@ srg_requirement: |- {{{ full_name }}} fapolicy module must be installed. vuldiscussion: |- - The organization must identify authorized software programs and permit execution of authorized software. The process used to identify software programs that are authorized to execute on organizational information systems is commonly referred to as whitelisting. + The organization must identify authorized software programs and permit execution of authorized software. The process used to identify software programs that are authorized to execute on organizational information systems is commonly referred to as allowlisting. - Utilizing a whitelist provides a configuration management method for allowing the execution of only authorized software. Using only authorized software decreases risk by limiting the number of potential vulnerabilities. Verification of whitelisted software occurs prior to execution or at system startup. + Utilizing an allowlist provides a configuration management method for allowing the execution of only authorized software. Using only authorized software decreases risk by limiting the number of potential vulnerabilities. Verification of allowlisted software occurs prior to execution or at system startup. - User home directories/folders may contain information of a sensitive nature. Non-privileged users should coordinate any sharing of information with an SA through shared resources. + User home directories/folders may contain information of a sensitive nature. Nonprivileged users should coordinate any sharing of information with an SA through shared resources. - {{{ full_name }}} ships with many optional packages. One such package is a file access policy daemon called "fapolicyd". "fapolicyd" is a userspace daemon that determines access rights to files based on attributes of the process and file. It can be used to either blacklist or whitelist processes or file access. + {{{ full_name }}} ships with many optional packages. One such package is a file access policy daemon called "fapolicyd". "fapolicyd" is a userspace daemon that determines access rights to files based on attributes of the process and file. It can be used to either blocklist or allowlist processes or file access. - Proceed with caution with enforcing the use of this daemon. Improper configuration may render the system non-functional. The "fapolicyd" API is not namespace aware and can cause issues when launching or running containers. + Proceed with caution with enforcing the use of this daemon. Improper configuration may render the system nonfunctional. The "fapolicyd" API is not namespace aware and can cause issues when launching or running containers. checktext: |- Verify that {{{ full_name }}} fapolicyd package is installed with the following command: @@ -28,13 +28,3 @@ fixtext: |- $ sudo dnf install fapolicyd -vuln_discussion: |- - The organization must identify authorized software programs and permit execution of authorized software. The process used to identify software programs that are authorized to execute on organizational information systems is commonly referred to as allowlisting. - - Utilizing an allowlist provides a configuration management method for allowing the execution of only authorized software. Using only authorized software decreases risk by limiting the number of potential vulnerabilities. Verification of allowlisted software occurs prior to execution or at system startup. - - User home directories/folders may contain information of a sensitive nature. Nonprivileged users should coordinate any sharing of information with an SA through shared resources. - - {{{ full_name }}} ships with many optional packages. One such package is a file access policy daemon called "fapolicyd". "fapolicyd" is a userspace daemon that determines access rights to files based on attributes of the process and file. It can be used to either blocklist or allowlist processes or file access. - - Proceed with caution with enforcing the use of this daemon. Improper configuration may render the system nonfunctional. The "fapolicyd" API is not namespace aware and can cause issues when launching or running containers. diff --git a/linux_os/guide/services/fapolicyd/service_fapolicyd_enabled/policy/stig/shared.yml b/linux_os/guide/services/fapolicyd/service_fapolicyd_enabled/policy/stig/shared.yml index e4fe3e481217..b6f1d1db0a4d 100644 --- a/linux_os/guide/services/fapolicyd/service_fapolicyd_enabled/policy/stig/shared.yml +++ b/linux_os/guide/services/fapolicyd/service_fapolicyd_enabled/policy/stig/shared.yml @@ -2,15 +2,15 @@ srg_requirement: |- {{{ full_name }}} fapolicy module must be enabled. vuldiscussion: |- - The organization must identify authorized software programs and permit execution of authorized software. The process used to identify software programs that are authorized to execute on organizational information systems is commonly referred to as whitelisting. + The organization must identify authorized software programs and permit execution of authorized software. The process used to identify software programs that are authorized to execute on organizational information systems is commonly referred to as allowlisting. - Utilizing a whitelist provides a configuration management method for allowing the execution of only authorized software. Using only authorized software decreases risk by limiting the number of potential vulnerabilities. Verification of whitelisted software occurs prior to execution or at system startup. + Utilizing an allowlist provides a configuration management method for allowing the execution of only authorized software. Using only authorized software decreases risk by limiting the number of potential vulnerabilities. Verification of allowlisted software occurs prior to execution or at system startup. - User home directories/folders may contain information of a sensitive nature. Non-privileged users should coordinate any sharing of information with an SA through shared resources. + User home directories/folders may contain information of a sensitive nature. Nonprivileged users should coordinate any sharing of information with an SA through shared resources. - {{{ full_name }}} ships with many optional packages. One such package is a file access policy daemon called "fapolicyd". "fapolicyd" is a userspace daemon that determines access rights to files based on attributes of the process and file. It can be used to either blacklist or whitelist processes or file access. + {{{ full_name }}} ships with many optional packages. One such package is a file access policy daemon called "fapolicyd". "fapolicyd" is a userspace daemon that determines access rights to files based on attributes of the process and file. It can be used to either blocklist or allowlist processes or file access. - Proceed with caution with enforcing the use of this daemon. Improper configuration may render the system non-functional. The "fapolicyd" API is not namespace aware and can cause issues when launching or running containers. + Proceed with caution with enforcing the use of this daemon. Improper configuration may render the system nonfunctional. The "fapolicyd" API is not namespace aware and can cause issues when launching or running containers. checktext: |- Verify that {{{ full_name }}} fapolicyd is active with the following command: @@ -26,13 +26,3 @@ fixtext: |- $ systemctl enable --now fapolicyd -vuln_discussion: |- - The organization must identify authorized software programs and permit execution of authorized software. The process used to identify software programs that are authorized to execute on organizational information systems is commonly referred to as allowlisting. - - Utilizing an allowlist provides a configuration management method for allowing the execution of only authorized software. Using only authorized software decreases risk by limiting the number of potential vulnerabilities. Verification of allowlisted software occurs prior to execution or at system startup. - - User home directories/folders may contain information of a sensitive nature. Nonprivileged users should coordinate any sharing of information with an SA through shared resources. - - {{{ full_name }}} ships with many optional packages. One such package is a file access policy daemon called "fapolicyd". "fapolicyd" is a userspace daemon that determines access rights to files based on attributes of the process and file. It can be used to either blocklist or allowlist processes or file access. - - Proceed with caution with enforcing the use of this daemon. Improper configuration may render the system nonfunctional. The "fapolicyd" API is not namespace aware and can cause issues when launching or running containers. diff --git a/linux_os/guide/services/ftp/disabling_vsftpd/package_vsftpd_removed/policy/stig/shared.yml b/linux_os/guide/services/ftp/disabling_vsftpd/package_vsftpd_removed/policy/stig/shared.yml index 33846ce51fe0..28acc066619c 100644 --- a/linux_os/guide/services/ftp/disabling_vsftpd/package_vsftpd_removed/policy/stig/shared.yml +++ b/linux_os/guide/services/ftp/disabling_vsftpd/package_vsftpd_removed/policy/stig/shared.yml @@ -2,8 +2,9 @@ srg_requirement: |- {{{ full_name }}} must not have a File Transfer Protocol (FTP) server package installed. vuldiscussion: |- - Removing the "vsftpd" package decreases the risk of its - accidental activation. + 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. + + Removing the "vsftpd" package decreases the risk of accidental activation. checktext: |- Verify that {{{ full_name }}} does not have a File Transfer Protocol (FTP) server package installed with the following command: @@ -17,7 +18,3 @@ fixtext: |- $ sudo dnf remove vsftpd -vuln_discussion: |- - 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. - - Removing the "vsftpd" package decreases the risk of accidental activation. diff --git a/linux_os/guide/services/kerberos/kerberos_disable_no_keytab/policy/stig/shared.yml b/linux_os/guide/services/kerberos/kerberos_disable_no_keytab/policy/stig/shared.yml index f66abdcf3f60..e2fa2b576e5e 100644 --- a/linux_os/guide/services/kerberos/kerberos_disable_no_keytab/policy/stig/shared.yml +++ b/linux_os/guide/services/kerberos/kerberos_disable_no_keytab/policy/stig/shared.yml @@ -17,11 +17,3 @@ checktext: |- If this command produces any "keytab" file(s), this is a finding. -vuln_discussion: |- - Unapproved mechanisms used for authentication to the cryptographic module are not verified; therefore, cannot be relied upon to provide confidentiality or integrity and DOD data may be compromised. - - {{{ full_name }}} systems utilizing encryption are required to use FIPS-compliant mechanisms for authenticating to cryptographic modules. - - The key derivation function (KDF) in Kerberos is not FIPS compatible. Ensuring the system does not have any keytab files present prevents system daemons from using Kerberos for authentication. A keytab is a file containing pairs of Kerberos principals and encrypted keys. - - FIPS 140-3 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. diff --git a/linux_os/guide/services/mail/package_s-nail_installed/policy/stig/shared.yml b/linux_os/guide/services/mail/package_s-nail_installed/policy/stig/shared.yml index 72823506d100..33e4ba81b1a0 100644 --- a/linux_os/guide/services/mail/package_s-nail_installed/policy/stig/shared.yml +++ b/linux_os/guide/services/mail/package_s-nail_installed/policy/stig/shared.yml @@ -19,5 +19,3 @@ checktext: |- If "s-nail" package is not installed, this is a finding. -vuln_discussion: |- - The "s-nail" package provides the mail command required to allow sending email notifications of unauthorized configuration changes to designated personnel. diff --git a/linux_os/guide/services/mail/package_sendmail_removed/policy/stig/shared.yml b/linux_os/guide/services/mail/package_sendmail_removed/policy/stig/shared.yml index 5a0ee658755c..283f5e9f3435 100644 --- a/linux_os/guide/services/mail/package_sendmail_removed/policy/stig/shared.yml +++ b/linux_os/guide/services/mail/package_sendmail_removed/policy/stig/shared.yml @@ -2,9 +2,7 @@ srg_requirement: |- {{{ full_name }}} must not have the sendmail package installed. vuldiscussion: |- - The sendmail software was not developed with security in mind and - its design prevents it from being effectively contained by SELinux. Postfix - should be used instead. + The sendmail software was not developed with security in mind, and its design prevents it from being effectively contained by SELinux. Postfix must be used instead. checktext: |- Verify that the sendmail package is not installed with the following command: @@ -20,5 +18,3 @@ fixtext: |- $ sudo dnf remove sendmail -vuln_discussion: |- - The sendmail software was not developed with security in mind, and its design prevents it from being effectively contained by SELinux. Postfix must be used instead. diff --git a/linux_os/guide/services/mail/postfix_client/postfix_client_configure_mail_alias/policy/stig/shared.yml b/linux_os/guide/services/mail/postfix_client/postfix_client_configure_mail_alias/policy/stig/shared.yml index cf50bc607c05..b01388ba012c 100644 --- a/linux_os/guide/services/mail/postfix_client/postfix_client_configure_mail_alias/policy/stig/shared.yml +++ b/linux_os/guide/services/mail/postfix_client/postfix_client_configure_mail_alias/policy/stig/shared.yml @@ -33,9 +33,3 @@ fixtext: |- $ sudo newaliases -vuln_discussion: |- - 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. diff --git a/linux_os/guide/services/mail/postfix_client/postfix_client_configure_mail_alias_postmaster/policy/stig/shared.yml b/linux_os/guide/services/mail/postfix_client/postfix_client_configure_mail_alias_postmaster/policy/stig/shared.yml index a18118e6e6a6..f9c885da7b54 100644 --- a/linux_os/guide/services/mail/postfix_client/postfix_client_configure_mail_alias_postmaster/policy/stig/shared.yml +++ b/linux_os/guide/services/mail/postfix_client/postfix_client_configure_mail_alias_postmaster/policy/stig/shared.yml @@ -2,13 +2,9 @@ srg_requirement: |- {{{ full_name }}} must forward mail from postmaster to the root account using a postfix alias. vuldiscussion: |- - 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. + 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. + Audit processing failures include software/hardware errors, failures in the audit capturing mechanisms, and audit storage capacity being reached or exceeded. checktext: |- Verify that the administrators are notified in the event of an audit processing failure. @@ -30,7 +26,3 @@ fixtext: |- $ sudo newaliases -vuln_discussion: |- - 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. diff --git a/linux_os/guide/services/mail/postfix_harden_os/postfix_server_cfg/postfix_server_relay/postfix_prevent_unrestricted_relay/policy/stig/shared.yml b/linux_os/guide/services/mail/postfix_harden_os/postfix_server_cfg/postfix_server_relay/postfix_prevent_unrestricted_relay/policy/stig/shared.yml index 05389d00e58b..b27a72d40b8c 100644 --- a/linux_os/guide/services/mail/postfix_harden_os/postfix_server_cfg/postfix_server_relay/postfix_prevent_unrestricted_relay/policy/stig/shared.yml +++ b/linux_os/guide/services/mail/postfix_harden_os/postfix_server_cfg/postfix_server_relay/postfix_prevent_unrestricted_relay/policy/stig/shared.yml @@ -2,9 +2,7 @@ srg_requirement: |- {{{ full_name }}} must be configured to prevent unrestricted mail relaying. vuldiscussion: |- - 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. + 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. checktext: |- Verify {{{ full_name }}} is configured to prevent unrestricted mail relaying with the following command: @@ -20,5 +18,3 @@ fixtext: |- $ sudo postconf -e 'smtpd_client_restrictions = permit_mynetworks,reject' -vuln_discussion: |- - 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. diff --git a/linux_os/guide/services/nfs_and_rpc/nfs_configuring_clients/mounting_remote_filesystems/mount_option_krb_sec_remote_filesystems/policy/stig/shared.yml b/linux_os/guide/services/nfs_and_rpc/nfs_configuring_clients/mounting_remote_filesystems/mount_option_krb_sec_remote_filesystems/policy/stig/shared.yml index d95d131e6b46..f84596aa4704 100644 --- a/linux_os/guide/services/nfs_and_rpc/nfs_configuring_clients/mounting_remote_filesystems/mount_option_krb_sec_remote_filesystems/policy/stig/shared.yml +++ b/linux_os/guide/services/nfs_and_rpc/nfs_configuring_clients/mounting_remote_filesystems/mount_option_krb_sec_remote_filesystems/policy/stig/shared.yml @@ -20,5 +20,3 @@ fixtext: |- Ensure the "sec" option is defined as "krb5p:krb5i:krb5". -vuln_discussion: |- - When an NFS server is configured to use RPCSEC_SYS, a selected userid and groupid are used to handle requests from the remote user. The userid and groupid could mistakenly or maliciously be set incorrectly. The RPCSEC_GSS method of authentication uses certificates on the server and client systems to more securely authenticate the remote mount request. diff --git a/linux_os/guide/services/nfs_and_rpc/nfs_configuring_clients/mounting_remote_filesystems/mount_option_nodev_remote_filesystems/policy/stig/shared.yml b/linux_os/guide/services/nfs_and_rpc/nfs_configuring_clients/mounting_remote_filesystems/mount_option_nodev_remote_filesystems/policy/stig/shared.yml index 45087239454c..92e5592f677f 100644 --- a/linux_os/guide/services/nfs_and_rpc/nfs_configuring_clients/mounting_remote_filesystems/mount_option_nodev_remote_filesystems/policy/stig/shared.yml +++ b/linux_os/guide/services/nfs_and_rpc/nfs_configuring_clients/mounting_remote_filesystems/mount_option_nodev_remote_filesystems/policy/stig/shared.yml @@ -2,7 +2,7 @@ srg_requirement: |- {{{ full_name }}} must prevent special devices on file systems that are imported via Network File System (NFS). vuldiscussion: |- - The "nodev" mount option causes the system to not interpret character or block special devices. Executing character or block special devices from untrusted file systems increases the opportunity for unprivileged users to attain unauthorized administrative access. + The "nodev" mount option causes the system to not interpret character or block special devices. Executing character or block special devices from untrusted file systems increases the opportunity for nonprivileged users to attain unauthorized administrative access. checktext: |- Verify {{{ full_name }}} has the "nodev" option configured for all NFS mounts with the following command: @@ -18,5 +18,3 @@ checktext: |- fixtext: |- Update each NFS mounted file system to use the "nodev" option on file systems that are being imported via NFS. -vuln_discussion: |- - The "nodev" mount option causes the system to not interpret character or block special devices. Executing character or block special devices from untrusted file systems increases the opportunity for nonprivileged users to attain unauthorized administrative access. diff --git a/linux_os/guide/services/nfs_and_rpc/nfs_configuring_clients/mounting_remote_filesystems/mount_option_noexec_remote_filesystems/policy/stig/shared.yml b/linux_os/guide/services/nfs_and_rpc/nfs_configuring_clients/mounting_remote_filesystems/mount_option_noexec_remote_filesystems/policy/stig/shared.yml index e2db19b543fb..a24c71429b7e 100644 --- a/linux_os/guide/services/nfs_and_rpc/nfs_configuring_clients/mounting_remote_filesystems/mount_option_noexec_remote_filesystems/policy/stig/shared.yml +++ b/linux_os/guide/services/nfs_and_rpc/nfs_configuring_clients/mounting_remote_filesystems/mount_option_noexec_remote_filesystems/policy/stig/shared.yml @@ -2,7 +2,7 @@ srg_requirement: |- {{{ full_name }}} must prevent code from being executed on file systems that are imported via Network File System (NFS). vuldiscussion: |- - The "noexec" mount option causes the system not to execute binary files. This option must be used for mounting any file system not containing approved binary as they may be incompatible. Executing files from untrusted file systems increases the opportunity for unprivileged users to attain unauthorized administrative access. + The "noexec" mount option causes the system not to execute binary files. This option must be used for mounting any file system not containing approved binary as they may be incompatible. Executing files from untrusted file systems increases the opportunity for nonprivileged users to attain unauthorized administrative access. checktext: |- Verify {{{ full_name }}} has the "noexec" option configured for all NFS mounts with the following command: @@ -18,5 +18,3 @@ checktext: |- fixtext: |- Update each NFS mounted file system to use the "noexec" option on file systems that are being imported via NFS. -vuln_discussion: |- - The "noexec" mount option causes the system not to execute binary files. This option must be used for mounting any file system not containing approved binary as they may be incompatible. Executing files from untrusted file systems increases the opportunity for nonprivileged users to attain unauthorized administrative access. diff --git a/linux_os/guide/services/nfs_and_rpc/nfs_configuring_clients/mounting_remote_filesystems/mount_option_nosuid_remote_filesystems/policy/stig/shared.yml b/linux_os/guide/services/nfs_and_rpc/nfs_configuring_clients/mounting_remote_filesystems/mount_option_nosuid_remote_filesystems/policy/stig/shared.yml index 80fb0448fe52..a843e387ceb5 100644 --- a/linux_os/guide/services/nfs_and_rpc/nfs_configuring_clients/mounting_remote_filesystems/mount_option_nosuid_remote_filesystems/policy/stig/shared.yml +++ b/linux_os/guide/services/nfs_and_rpc/nfs_configuring_clients/mounting_remote_filesystems/mount_option_nosuid_remote_filesystems/policy/stig/shared.yml @@ -2,7 +2,7 @@ srg_requirement: |- {{{ full_name }}} must prevent files with the setuid and setgid bit set from being executed on file systems that are imported via Network File System (NFS). vuldiscussion: |- - The "nosuid" mount option causes the system not to execute "setuid" and "setgid" files with owner privileges. This option must be used for mounting any file system not containing approved "setuid" and "setguid" files. Executing files from untrusted file systems increases the opportunity for unprivileged users to attain unauthorized administrative access. + The "nosuid" mount option causes the system not to execute "setuid" and "setgid" files with owner privileges. This option must be used for mounting any file system not containing approved "setuid" and "setguid" files. Executing files from untrusted file systems increases the opportunity for nonprivileged users to attain unauthorized administrative access. checktext: |- Verify {{{ full_name }}} has the "nosuid" option configured for all NFS mounts with the following command: @@ -18,5 +18,3 @@ checktext: |- fixtext: |- Update each NFS mounted file system to use the "nosuid" option on file systems that are being imported via NFS. -vuln_discussion: |- - The "nosuid" mount option causes the system not to execute "setuid" and "setgid" files with owner privileges. This option must be used for mounting any file system not containing approved "setuid" and "setguid" files. Executing files from untrusted file systems increases the opportunity for nonprivileged users to attain unauthorized administrative access. diff --git a/linux_os/guide/services/nfs_and_rpc/package_nfs-utils_removed/policy/stig/shared.yml b/linux_os/guide/services/nfs_and_rpc/package_nfs-utils_removed/policy/stig/shared.yml index e01a8bc33095..78a99edd9316 100644 --- a/linux_os/guide/services/nfs_and_rpc/package_nfs-utils_removed/policy/stig/shared.yml +++ b/linux_os/guide/services/nfs_and_rpc/package_nfs-utils_removed/policy/stig/shared.yml @@ -2,11 +2,7 @@ srg_requirement: |- {{{ full_name }}} must not have the nfs-utils package installed. vuldiscussion: |- - "nfs-utils" provides a daemon for the kernel NFS server and related tools. This - package also contains the "showmount" program. "showmount" queries the mount - daemon on a remote host for information about the Network File System (NFS) server on the - remote host. For example, "showmount" can display the clients which are mounted on - that host. + "nfs-utils" provides a daemon for the kernel NFS server and related tools. This package also contains the "showmount" program. "showmount" queries the mount daemon on a remote host for information about the Network File System (NFS) server on the remote host. For example, "showmount" can display the clients that are mounted on that host. checktext: |- Verify that the nfs-utils package is not installed with the following command: @@ -22,5 +18,3 @@ fixtext: |- $ sudo dnf remove nfs-utils -vuln_discussion: |- - "nfs-utils" provides a daemon for the kernel NFS server and related tools. This package also contains the "showmount" program. "showmount" queries the mount daemon on a remote host for information about the Network File System (NFS) server on the remote host. For example, "showmount" can display the clients that are mounted on that host. diff --git a/linux_os/guide/services/ntp/chronyd_client_only/policy/stig/shared.yml b/linux_os/guide/services/ntp/chronyd_client_only/policy/stig/shared.yml index 74be36c50417..194865b926e4 100644 --- a/linux_os/guide/services/ntp/chronyd_client_only/policy/stig/shared.yml +++ b/linux_os/guide/services/ntp/chronyd_client_only/policy/stig/shared.yml @@ -2,8 +2,7 @@ srg_requirement: |- {{{ full_name }}} must disable the chrony daemon from acting as a server. vuldiscussion: |- - Minimizing the exposure of the server functionality of the chrony - daemon diminishes the attack surface. + Minimizing the exposure of the server functionality of the chrony daemon diminishes the attack surface. checktext: |- Verify {{{ full_name }}} disables the chrony daemon from acting as a server with the following command: @@ -19,5 +18,3 @@ fixtext: |- port 0 -vuln_discussion: |- - Minimizing the exposure of the server functionality of the chrony daemon diminishes the attack surface. diff --git a/linux_os/guide/services/ntp/chronyd_no_chronyc_network/policy/stig/shared.yml b/linux_os/guide/services/ntp/chronyd_no_chronyc_network/policy/stig/shared.yml index ee6f5d676e10..c8829323a9c2 100644 --- a/linux_os/guide/services/ntp/chronyd_no_chronyc_network/policy/stig/shared.yml +++ b/linux_os/guide/services/ntp/chronyd_no_chronyc_network/policy/stig/shared.yml @@ -2,8 +2,7 @@ srg_requirement: |- {{{ full_name }}} must disable network management of the chrony daemon. vuldiscussion: |- - Not exposing the management interface of the chrony daemon on - the network diminishes the attack space. + Not exposing the management interface of the chrony daemon on the network diminishes the attack space. checktext: |- Verify {{{ full_name }}} disables network management of the chrony daemon with the following command: @@ -19,5 +18,3 @@ fixtext: |- cmdport 0 -vuln_discussion: |- - Not exposing the management interface of the chrony daemon on the network diminishes the attack space. diff --git a/linux_os/guide/services/ntp/package_chrony_installed/policy/stig/shared.yml b/linux_os/guide/services/ntp/package_chrony_installed/policy/stig/shared.yml index 52ec145348f3..39bc0298f7f4 100644 --- a/linux_os/guide/services/ntp/package_chrony_installed/policy/stig/shared.yml +++ b/linux_os/guide/services/ntp/package_chrony_installed/policy/stig/shared.yml @@ -2,11 +2,7 @@ srg_requirement: |- {{{ full_name }}} must have the chrony package installed. vuldiscussion: |- - Inaccurate time stamps make it more difficult to correlate - events and can lead to an inaccurate analysis. Determining the correct - time a particular event occurred on a system is critical when conducting - forensic analysis and investigating system events. Sources outside the - configured acceptable allowance (drift) may be inaccurate. + Inaccurate time stamps make it more difficult to correlate events and can lead to an inaccurate analysis. Determining the correct time a particular event occurred on a system is critical when conducting forensic analysis and investigating system events. Sources outside the configured acceptable allowance (drift) may be inaccurate. checktext: |- Verify that {{{ full_name }}} has the chrony package installed with the following command: @@ -24,5 +20,3 @@ fixtext: |- $ sudo dnf install chrony -vuln_discussion: |- - Inaccurate time stamps make it more difficult to correlate events and can lead to an inaccurate analysis. Determining the correct time a particular event occurred on a system is critical when conducting forensic analysis and investigating system events. Sources outside the configured acceptable allowance (drift) may be inaccurate. diff --git a/linux_os/guide/services/ntp/service_chronyd_enabled/policy/stig/shared.yml b/linux_os/guide/services/ntp/service_chronyd_enabled/policy/stig/shared.yml index bfe3c6a1b8ae..65b7cc84efaf 100644 --- a/linux_os/guide/services/ntp/service_chronyd_enabled/policy/stig/shared.yml +++ b/linux_os/guide/services/ntp/service_chronyd_enabled/policy/stig/shared.yml @@ -20,7 +20,3 @@ fixtext: |- $ sudo systemctl enable --now chronyd -vuln_discussion: |- - Inaccurate time stamps make it more difficult to correlate events and can lead to an inaccurate analysis. Determining the correct time a particular event occurred on a system is critical when conducting forensic analysis and investigating system events. Sources outside the configured acceptable allowance (drift) may be inaccurate. - - Synchronizing internal information system clocks provides uniformity of time stamps for information systems with multiple system clocks and systems connected over a network. diff --git a/linux_os/guide/services/obsolete/nis/package_ypserv_removed/policy/stig/shared.yml b/linux_os/guide/services/obsolete/nis/package_ypserv_removed/policy/stig/shared.yml index 277e1c7ad057..e1adab8b8f67 100644 --- a/linux_os/guide/services/obsolete/nis/package_ypserv_removed/policy/stig/shared.yml +++ b/linux_os/guide/services/obsolete/nis/package_ypserv_removed/policy/stig/shared.yml @@ -15,7 +15,3 @@ checktext: |- If the "ypserv" package is installed, this is a finding. -vuln_discussion: |- - The NIS service provides an unencrypted authentication service, which does not provide for the confidentiality and integrity of user passwords or the remote session. - - Removing the "ypserv" package decreases the risk of the accidental (or intentional) activation of NIS or NIS+ services. diff --git a/linux_os/guide/services/obsolete/r_services/no_host_based_files/policy/stig/shared.yml b/linux_os/guide/services/obsolete/r_services/no_host_based_files/policy/stig/shared.yml index ebaf4e4a0dfa..a3cb5635cf46 100644 --- a/linux_os/guide/services/obsolete/r_services/no_host_based_files/policy/stig/shared.yml +++ b/linux_os/guide/services/obsolete/r_services/no_host_based_files/policy/stig/shared.yml @@ -2,11 +2,7 @@ srg_requirement: |- There must be no shosts.equiv files on {{{ full_name }}}. vuldiscussion: |- - The shosts.equiv files are used to configure host-based authentication for the - system via SSH. Host-based authentication is not sufficient for preventing - unauthorized access to the system, as it does not require interactive - identification and authentication of a connection request, or for the use of - two-factor authentication. + The shosts.equiv files are used to configure host-based authentication for the system via SSH. Host-based authentication is not sufficient for preventing unauthorized access to the system, as it does not require interactive identification and authentication of a connection request, or for the use of two-factor authentication. checktext: |- Verify there are no "shosts.equiv" files on {{{ full_name }}} with the following command: @@ -20,5 +16,3 @@ fixtext: |- $ sudo rm /[path]/[to]/[file]/shosts.equiv -vuln_discussion: |- - The shosts.equiv files are used to configure host-based authentication for the system via SSH. Host-based authentication is not sufficient for preventing unauthorized access to the system, as it does not require interactive identification and authentication of a connection request, or for the use of two-factor authentication. diff --git a/linux_os/guide/services/obsolete/r_services/no_user_host_based_files/policy/stig/shared.yml b/linux_os/guide/services/obsolete/r_services/no_user_host_based_files/policy/stig/shared.yml index 4750d5a9f5a5..ba908a0ce2f3 100644 --- a/linux_os/guide/services/obsolete/r_services/no_user_host_based_files/policy/stig/shared.yml +++ b/linux_os/guide/services/obsolete/r_services/no_user_host_based_files/policy/stig/shared.yml @@ -2,11 +2,7 @@ srg_requirement: |- There must be no .shosts files on {{{ full_name }}}. vuldiscussion: |- - The .shosts files are used to configure host-based authentication for - individual users or the system via SSH. Host-based authentication is not - sufficient for preventing unauthorized access to the system, as it does not - require interactive identification and authentication of a connection request, - or for the use of two-factor authentication. + The .shosts 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. checktext: |- Verify there are no ".shosts" files on {{{ full_name }}} with the following command: @@ -20,5 +16,3 @@ fixtext: |- $ sudo rm /[path]/[to]/[file]/.shosts -vuln_discussion: |- - 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. diff --git a/linux_os/guide/services/obsolete/r_services/package_rsh-server_removed/policy/stig/shared.yml b/linux_os/guide/services/obsolete/r_services/package_rsh-server_removed/policy/stig/shared.yml index 0519757b8d12..a9a0e2fa41bf 100644 --- a/linux_os/guide/services/obsolete/r_services/package_rsh-server_removed/policy/stig/shared.yml +++ b/linux_os/guide/services/obsolete/r_services/package_rsh-server_removed/policy/stig/shared.yml @@ -15,5 +15,3 @@ checktext: |- If the "rsh-server" package is installed, this is a finding. -vuln_discussion: |- - The "rsh-server" service provides unencrypted remote access service, which does not provide for the confidentiality and integrity of user passwords or the remote session and has very weak authentication. If a privileged user were to login using this service, the privileged user password could be compromised. The "rsh-server" package provides several obsolete and insecure network services. Removing it decreases the risk of accidental (or intentional) activation of those services. diff --git a/linux_os/guide/services/obsolete/telnet/package_telnet-server_removed/policy/stig/shared.yml b/linux_os/guide/services/obsolete/telnet/package_telnet-server_removed/policy/stig/shared.yml index 0864dbab67f4..e9ef522c32ac 100644 --- a/linux_os/guide/services/obsolete/telnet/package_telnet-server_removed/policy/stig/shared.yml +++ b/linux_os/guide/services/obsolete/telnet/package_telnet-server_removed/policy/stig/shared.yml @@ -2,21 +2,11 @@ srg_requirement: |- {{{ full_name }}} must not have the telnet-server package installed. vuldiscussion: |- - It is detrimental for operating systems to provide, or install by default, - functionality exceeding requirements or mission objectives. These - unnecessary capabilities are often overlooked and therefore may remain - unsecure. They increase the risk to the platform by providing additional - attack vectors. - - - The telnet service provides an unencrypted remote access service which does - not provide for the confidentiality and integrity of user passwords or the - remote session. If a privileged user were to login using this service, the - privileged user password could be compromised. + It is detrimental for operating systems to provide, or install by default, functionality exceeding requirements or mission objectives. These unnecessary capabilities are often overlooked and therefore, may remain unsecure. They increase the risk to the platform by providing additional attack vectors. + The telnet service provides an unencrypted remote access service, which does not provide for the confidentiality and integrity of user passwords or the remote session. If a privileged user were to login using this service, the privileged user password could be compromised. - Removing the "telnet-server" package decreases the risk of the - telnet service's accidental (or intentional) activation. + Removing the "telnet-server" package decreases the risk of accidental (or intentional) activation of the telnet service. checktext: |- Verify that the telnet-server package is not installed with the following command: @@ -32,9 +22,3 @@ fixtext: |- $ sudo dnf remove telnet-server -vuln_discussion: |- - It is detrimental for operating systems to provide, or install by default, functionality exceeding requirements or mission objectives. These unnecessary capabilities are often overlooked and therefore, may remain unsecure. They increase the risk to the platform by providing additional attack vectors. - - The telnet service provides an unencrypted remote access service, which does not provide for the confidentiality and integrity of user passwords or the remote session. If a privileged user were to login using this service, the privileged user password could be compromised. - - Removing the "telnet-server" package decreases the risk of accidental (or intentional) activation of the telnet service. diff --git a/linux_os/guide/services/obsolete/tftp/package_tftp-server_removed/policy/stig/shared.yml b/linux_os/guide/services/obsolete/tftp/package_tftp-server_removed/policy/stig/shared.yml index 80d91f31a710..9ee23cf9e556 100644 --- a/linux_os/guide/services/obsolete/tftp/package_tftp-server_removed/policy/stig/shared.yml +++ b/linux_os/guide/services/obsolete/tftp/package_tftp-server_removed/policy/stig/shared.yml @@ -2,13 +2,9 @@ srg_requirement: |- {{{ full_name }}} must not have a Trivial File Transfer Protocol (TFTP) server package installed. vuldiscussion: |- - Removing the "tftp-server" package decreases the risk of the accidental - (or intentional) activation of tftp services. + Removing the "tftp-server" package decreases the risk of the accidental (or intentional) activation of tftp services. - If TFTP is required for operational support (such as transmission of router - configurations), its use must be documented with the Information Systems - Securty Manager (ISSM), restricted to only authorized personnel, and have - access control rules established. + If TFTP is required for operational support (such as transmission of router configurations), its use must be documented with the information systems security manager (ISSM), restricted to only authorized personnel, and have access control rules established. checktext: |- Verify that {{{ full_name }}} does not have a tftp server package installed with the following command: @@ -22,7 +18,3 @@ fixtext: |- $ sudo dnf remove tftp -vuln_discussion: |- - Removing the "tftp-server" package decreases the risk of the accidental (or intentional) activation of tftp services. - - If TFTP is required for operational support (such as transmission of router configurations), its use must be documented with the information systems security manager (ISSM), restricted to only authorized personnel, and have access control rules established. diff --git a/linux_os/guide/services/obsolete/tftp/tftpd_uses_secure_mode/policy/stig/shared.yml b/linux_os/guide/services/obsolete/tftp/tftpd_uses_secure_mode/policy/stig/shared.yml index 0e68aab749fd..c330a80fa745 100644 --- a/linux_os/guide/services/obsolete/tftp/tftpd_uses_secure_mode/policy/stig/shared.yml +++ b/linux_os/guide/services/obsolete/tftp/tftpd_uses_secure_mode/policy/stig/shared.yml @@ -2,8 +2,7 @@ srg_requirement: |- If the Trivial File Transfer Protocol (TFTP) server is required, {{{ full_name }}} TFTP daemon must be configured to operate in secure mode. vuldiscussion: |- - Restricting TFTP to a specific directory prevents remote users from copying, transferring, or overwriting system files. Using the "-s" option causes the TFTP service to only serve files from the - given directory. + Restricting TFTP to a specific directory prevents remote users from copying, transferring, or overwriting system files. Using the "-s" option causes the TFTP service to only serve files from the given directory. checktext: |- Verify the TFTP daemon is configured to operate in secure mode. @@ -37,5 +36,3 @@ fixtext: |- ExecStart=/usr/sbin/in.tftpd -s /var/lib/tftpboot -vuln_discussion: |- - Restricting TFTP to a specific directory prevents remote users from copying, transferring, or overwriting system files. Using the "-s" option causes the TFTP service to only serve files from the given directory. diff --git a/linux_os/guide/services/routing/disabling_quagga/package_quagga_removed/policy/stig/shared.yml b/linux_os/guide/services/routing/disabling_quagga/package_quagga_removed/policy/stig/shared.yml index 8ea72cf4379d..54ebf78fb553 100644 --- a/linux_os/guide/services/routing/disabling_quagga/package_quagga_removed/policy/stig/shared.yml +++ b/linux_os/guide/services/routing/disabling_quagga/package_quagga_removed/policy/stig/shared.yml @@ -2,7 +2,7 @@ srg_requirement: |- {{{ full_name }}} must not have the quagga package installed. vuldiscussion: |- - Quagga is a network routing software suite providing implementations of Open Shortest Path First (OSPF), Routing Information Protocol (RIP), Border Gateway Protocol (BGP) for UNIX and linux platforms. + Quagga is a network routing software suite providing implementations of Open Shortest Path First (OSPF), Routing Information Protocol (RIP), Border Gateway Protocol (BGP) for Unix and Linux platforms. If there is no need to make the router software available, removing it provides a safeguard against its activation. @@ -20,7 +20,3 @@ fixtext: |- $ sudo dnf remove quagga -vuln_discussion: |- - Quagga is a network routing software suite providing implementations of Open Shortest Path First (OSPF), Routing Information Protocol (RIP), Border Gateway Protocol (BGP) for Unix and Linux platforms. - - If there is no need to make the router software available, removing it provides a safeguard against its activation. diff --git a/linux_os/guide/services/ssh/file_groupowner_sshd_config/policy/stig/shared.yml b/linux_os/guide/services/ssh/file_groupowner_sshd_config/policy/stig/shared.yml index 4f1b35146490..fcd0127c4435 100644 --- a/linux_os/guide/services/ssh/file_groupowner_sshd_config/policy/stig/shared.yml +++ b/linux_os/guide/services/ssh/file_groupowner_sshd_config/policy/stig/shared.yml @@ -2,10 +2,7 @@ srg_requirement: |- {{{ full_name }}} SSH server configuration file must be group-owned by root. vuldiscussion: |- - Service configuration files enable or disable features of their respective - services that if configured incorrectly can lead to insecure and vulnerable - configurations. Therefore, service configuration files should be owned by the - correct group to prevent unauthorized changes. + Service configuration files enable or disable features of their respective services, which if configured incorrectly, can lead to insecure and vulnerable configurations. Therefore, service configuration files must be owned by the correct group to prevent unauthorized changes. checktext: |- Verify the group ownership of the "/etc/ssh/sshd_config" file with the following command: @@ -21,5 +18,3 @@ fixtext: |- $ sudo chgrp root /etc/ssh/sshd_config -vuln_discussion: |- - Service configuration files enable or disable features of their respective services, which if configured incorrectly, can lead to insecure and vulnerable configurations. Therefore, service configuration files must be owned by the correct group to prevent unauthorized changes. diff --git a/linux_os/guide/services/ssh/file_owner_sshd_config/policy/stig/shared.yml b/linux_os/guide/services/ssh/file_owner_sshd_config/policy/stig/shared.yml index 9e1e384e3621..b35654ff9e44 100644 --- a/linux_os/guide/services/ssh/file_owner_sshd_config/policy/stig/shared.yml +++ b/linux_os/guide/services/ssh/file_owner_sshd_config/policy/stig/shared.yml @@ -2,10 +2,7 @@ srg_requirement: |- {{{ full_name }}} SSH server configuration file must be owned by root. vuldiscussion: |- - Service configuration files enable or disable features of their respective - services that if configured incorrectly can lead to insecure and vulnerable - configurations. Therefore, service configuration files should be owned by the - correct group to prevent unauthorized changes. + Service configuration files enable or disable features of their respective services, which if configured incorrectly, can lead to insecure and vulnerable configurations. Therefore, service configuration files must be owned by the correct group to prevent unauthorized changes. checktext: |- Verify the ownership of the "/etc/ssh/sshd_config" file with the following command: @@ -21,5 +18,3 @@ fixtext: |- $ sudo chown root /etc/ssh/sshd_config -vuln_discussion: |- - Service configuration files enable or disable features of their respective services, which if configured incorrectly, can lead to insecure and vulnerable configurations. Therefore, service configuration files must be owned by the correct group to prevent unauthorized changes. diff --git a/linux_os/guide/services/ssh/file_permissions_sshd_config/policy/stig/shared.yml b/linux_os/guide/services/ssh/file_permissions_sshd_config/policy/stig/shared.yml index 8127aea4c65f..556ac79953d2 100644 --- a/linux_os/guide/services/ssh/file_permissions_sshd_config/policy/stig/shared.yml +++ b/linux_os/guide/services/ssh/file_permissions_sshd_config/policy/stig/shared.yml @@ -2,10 +2,7 @@ srg_requirement: |- {{{ full_name }}} SSH server configuration file must have mode 0600 or less permissive. vuldiscussion: |- - Service configuration files enable or disable features of their respective - services that if configured incorrectly can lead to insecure and vulnerable - configurations. Therefore, service configuration files should be owned by the - correct group to prevent unauthorized changes. + Service configuration files enable or disable features of their respective services that if configured incorrectly can lead to insecure and vulnerable configurations. Therefore, service configuration files should be owned by the correct group to prevent unauthorized changes. checktext: |- Verify the permissions of the "/etc/ssh/sshd_config" file with the following command: @@ -21,5 +18,3 @@ fixtext: |- $ sudo chmod 0600 /etc/ssh/sshd_config -vuln_discussion: |- - Service configuration files enable or disable features of their respective services that if configured incorrectly can lead to insecure and vulnerable configurations. Therefore, service configuration files should be owned by the correct group to prevent unauthorized changes. diff --git a/linux_os/guide/services/ssh/file_permissions_sshd_private_key/policy/stig/shared.yml b/linux_os/guide/services/ssh/file_permissions_sshd_private_key/policy/stig/shared.yml index d996c9324bdf..009a65237d9c 100644 --- a/linux_os/guide/services/ssh/file_permissions_sshd_private_key/policy/stig/shared.yml +++ b/linux_os/guide/services/ssh/file_permissions_sshd_private_key/policy/stig/shared.yml @@ -2,8 +2,7 @@ srg_requirement: |- {{{ full_name }}} SSH private host key files must have mode 0640 or less permissive. vuldiscussion: |- - If an unauthorized user obtains the private SSH host key file, the host could be - impersonated. + If an unauthorized user obtains the private SSH host key file, the host could be impersonated. checktext: |- Verify the SSH private host key files have a mode of "0640" or less permissive with the following command: @@ -26,5 +25,3 @@ fixtext: |- $ sudo systemctl restart sshd.service -vuln_discussion: |- - If an unauthorized user obtains the private SSH host key file, the host could be impersonated. diff --git a/linux_os/guide/services/ssh/file_permissions_sshd_pub_key/policy/stig/shared.yml b/linux_os/guide/services/ssh/file_permissions_sshd_pub_key/policy/stig/shared.yml index 5d81aa362a0e..b339d3fc71ad 100644 --- a/linux_os/guide/services/ssh/file_permissions_sshd_pub_key/policy/stig/shared.yml +++ b/linux_os/guide/services/ssh/file_permissions_sshd_pub_key/policy/stig/shared.yml @@ -2,8 +2,7 @@ srg_requirement: |- {{{ full_name }}} SSH public host key files must have mode 0644 or less permissive. vuldiscussion: |- - If a public host key file is modified by an unauthorized user, the SSH service - may be compromised. + If a public host key file is modified by an unauthorized user, the SSH service may be compromised. checktext: |- Verify the SSH public host key files have a mode of "0644" or less permissive with the following command: @@ -28,5 +27,3 @@ fixtext: |- $ sudo systemctl restart sshd.service -vuln_discussion: |- - If a public host key file is modified by an unauthorized user, the SSH service may be compromised. diff --git a/linux_os/guide/services/ssh/package_openssh-clients_installed/policy/stig/shared.yml b/linux_os/guide/services/ssh/package_openssh-clients_installed/policy/stig/shared.yml index 8787815aa86c..5ce6eda8ac84 100644 --- a/linux_os/guide/services/ssh/package_openssh-clients_installed/policy/stig/shared.yml +++ b/linux_os/guide/services/ssh/package_openssh-clients_installed/policy/stig/shared.yml @@ -20,5 +20,3 @@ fixtext: |- $ sudo dnf install openssh-clients -vuln_discussion: |- - This package includes utilities to make encrypted connections and transfer files securely to SSH servers. diff --git a/linux_os/guide/services/ssh/package_openssh-server_installed/policy/stig/shared.yml b/linux_os/guide/services/ssh/package_openssh-server_installed/policy/stig/shared.yml index 3d4fedef446e..bcfb36a075da 100644 --- a/linux_os/guide/services/ssh/package_openssh-server_installed/policy/stig/shared.yml +++ b/linux_os/guide/services/ssh/package_openssh-server_installed/policy/stig/shared.yml @@ -24,9 +24,3 @@ fixtext: |- $ sudo dnf install openssh-server -vuln_discussion: |- - 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. diff --git a/linux_os/guide/services/ssh/service_sshd_enabled/policy/stig/shared.yml b/linux_os/guide/services/ssh/service_sshd_enabled/policy/stig/shared.yml index 6ce87178de9e..482161fa795b 100644 --- a/linux_os/guide/services/ssh/service_sshd_enabled/policy/stig/shared.yml +++ b/linux_os/guide/services/ssh/service_sshd_enabled/policy/stig/shared.yml @@ -22,9 +22,3 @@ fixtext: |- $ systemctl enable --now sshd -vuln_discussion: |- - 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. diff --git a/linux_os/guide/services/ssh/ssh_client/ssh_keys_passphrase_protected/policy/stig/shared.yml b/linux_os/guide/services/ssh/ssh_client/ssh_keys_passphrase_protected/policy/stig/shared.yml index 66606a2cfcb6..b2850c70d9c8 100644 --- a/linux_os/guide/services/ssh/ssh_client/ssh_keys_passphrase_protected/policy/stig/shared.yml +++ b/linux_os/guide/services/ssh/ssh_client/ssh_keys_passphrase_protected/policy/stig/shared.yml @@ -17,18 +17,10 @@ vuldiscussion: |- The cornerstone of the PKI is the private key used to encrypt or digitally sign information. - If the private key is stolen, this will lead to the compromise of the authentication and non-repudiation gained through PKI because the attacker can use the private key to digitally sign documents and pretend to be the authorized user. + If the private key is stolen, this will lead to the compromise of the authentication and nonrepudiation gained through PKI because the attacker can use the private key to digitally sign documents and pretend to be the authorized user. Both the holders of a digital certificate and the issuing authority must protect the computers, storage devices, or whatever they use to keep the private keys. srg_requirement: |- {{{ full_name }}}, for PKI-based authentication, must enforce authorized access to the corresponding private key. -vuln_discussion: |- - If the private key is discovered, an attacker can use the key to authenticate as an authorized user and gain access to the network infrastructure. - - The cornerstone of the PKI is the private key used to encrypt or digitally sign information. - - If the private key is stolen, this will lead to the compromise of the authentication and nonrepudiation gained through PKI because the attacker can use the private key to digitally sign documents and pretend to be the authorized user. - - Both the holders of a digital certificate and the issuing authority must protect the computers, storage devices, or whatever they use to keep the private keys. diff --git a/linux_os/guide/services/ssh/ssh_server/disable_host_auth/policy/stig/shared.yml b/linux_os/guide/services/ssh/ssh_server/disable_host_auth/policy/stig/shared.yml index c3eff91fad06..77e2743878e5 100644 --- a/linux_os/guide/services/ssh/ssh_server/disable_host_auth/policy/stig/shared.yml +++ b/linux_os/guide/services/ssh/ssh_server/disable_host_auth/policy/stig/shared.yml @@ -2,8 +2,7 @@ srg_requirement: |- {{{ full_name }}} must not allow a noncertificate trusted host SSH logon to the system. vuldiscussion: |- - SSH trust relationships mean a compromise on one host - can allow an attacker to move trivially to other hosts. + SSH trust relationships mean a compromise on one host can allow an attacker to move trivially to other hosts. checktext: |- Verify the operating system does not allow a noncertificate trusted host SSH logon to the system with the following command: @@ -25,5 +24,3 @@ fixtext: |- $ sudo systemctl restart sshd.service -vuln_discussion: |- - SSH trust relationships mean a compromise on one host can allow an attacker to move trivially to other hosts. diff --git a/linux_os/guide/services/ssh/ssh_server/firewalld_sshd_port_enabled/policy/stig/shared.yml b/linux_os/guide/services/ssh/ssh_server/firewalld_sshd_port_enabled/policy/stig/shared.yml index 58c0f32c7d38..27b89fe64459 100644 --- a/linux_os/guide/services/ssh/ssh_server/firewalld_sshd_port_enabled/policy/stig/shared.yml +++ b/linux_os/guide/services/ssh/ssh_server/firewalld_sshd_port_enabled/policy/stig/shared.yml @@ -2,7 +2,7 @@ srg_requirement: |- {{{ full_name }}} must be configured to prohibit or restrict the use of functions, ports, protocols, and/or services, as defined in the Ports, Protocols, and Services Management (PPSM) Category Assignments List (CAL) and vulnerability assessments. vuldiscussion: |- - To prevent unauthorized connection of devices, unauthorized transfer of information, or unauthorized tunneling (i.e., embedding of data types within data types), organizations must disable or restrict unused or unnecessary ports, protocols,and services on information systems. + To prevent unauthorized connection of devices, unauthorized transfer of information, or unauthorized tunneling (i.e., embedding of data types within data types), organizations must disable or restrict unused or unnecessary ports, protocols, and services on information systems. checktext: |- Inspect the firewall configuration and running services to verify it is configured to prohibit or restrict the use of functions, ports, protocols, and/or services that are unnecessary or prohibited. @@ -34,5 +34,3 @@ fixtext: |- $ sudo firewall-cmd --reload -vuln_discussion: |- - To prevent unauthorized connection of devices, unauthorized transfer of information, or unauthorized tunneling (i.e., embedding of data types within data types), organizations must disable or restrict unused or unnecessary ports, protocols, and services on information systems. diff --git a/linux_os/guide/services/ssh/ssh_server/sshd_disable_empty_passwords/policy/stig/shared.yml b/linux_os/guide/services/ssh/ssh_server/sshd_disable_empty_passwords/policy/stig/shared.yml index 3c586948ad9e..5f870c708432 100644 --- a/linux_os/guide/services/ssh/ssh_server/sshd_disable_empty_passwords/policy/stig/shared.yml +++ b/linux_os/guide/services/ssh/ssh_server/sshd_disable_empty_passwords/policy/stig/shared.yml @@ -22,5 +22,3 @@ fixtext: |- $ sudo systemctl restart sshd.service -vuln_discussion: |- - 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. diff --git a/linux_os/guide/services/ssh/ssh_server/sshd_disable_gssapi_auth/policy/stig/shared.yml b/linux_os/guide/services/ssh/ssh_server/sshd_disable_gssapi_auth/policy/stig/shared.yml index a2ca481ae99b..50d7bcd77035 100644 --- a/linux_os/guide/services/ssh/ssh_server/sshd_disable_gssapi_auth/policy/stig/shared.yml +++ b/linux_os/guide/services/ssh/ssh_server/sshd_disable_gssapi_auth/policy/stig/shared.yml @@ -2,8 +2,7 @@ srg_requirement: |- {{{ full_name }}} SSH daemon must not allow GSSAPI authentication. vuldiscussion: |- - GSSAPI authentication is used to provide additional authentication mechanisms to applications. Allowing GSSAPI authentication through SSH exposes the system's - GSSAPI to remote hosts, increasing the attack surface of the system. + Generic Security Service Application Program Interface (GSSAPI) authentication is used to provide additional authentication mechanisms to applications. Allowing GSSAPI authentication through SSH exposes the system's GSSAPI to remote hosts, increasing the attack surface of the system. checktext: |- Verify the SSH daemon does not allow GSSAPI authentication with the following command: @@ -27,5 +26,3 @@ fixtext: |- $ sudo systemctl restart sshd.service -vuln_discussion: |- - Generic Security Service Application Program Interface (GSSAPI) authentication is used to provide additional authentication mechanisms to applications. Allowing GSSAPI authentication through SSH exposes the system's GSSAPI to remote hosts, increasing the attack surface of the system. diff --git a/linux_os/guide/services/ssh/ssh_server/sshd_disable_kerb_auth/policy/stig/shared.yml b/linux_os/guide/services/ssh/ssh_server/sshd_disable_kerb_auth/policy/stig/shared.yml index 98bb5837ffee..f830830ada6d 100644 --- a/linux_os/guide/services/ssh/ssh_server/sshd_disable_kerb_auth/policy/stig/shared.yml +++ b/linux_os/guide/services/ssh/ssh_server/sshd_disable_kerb_auth/policy/stig/shared.yml @@ -2,10 +2,7 @@ srg_requirement: |- {{{ full_name }}} SSH daemon must not allow Kerberos authentication. vuldiscussion: |- - Kerberos authentication for SSH is often implemented using GSSAPI. If Kerberos - is enabled through SSH, the SSH daemon provides a means of access to the - system's Kerberos implementation. Vulnerabilities in the system's Kerberos - implementations may be subject to exploitation. + Kerberos authentication for SSH is often implemented using Generic Security Service Application Program Interface (GSSAPI). If Kerberos is enabled through SSH, the SSH daemon provides a means of access to the system's Kerberos implementation. Vulnerabilities in the system's Kerberos implementations may be subject to exploitation. checktext: |- Verify the SSH daemon does not allow Kerberos authentication with the following command: @@ -27,5 +24,3 @@ fixtext: |- $ sudo systemctl restart sshd.service -vuln_discussion: |- - Kerberos authentication for SSH is often implemented using Generic Security Service Application Program Interface (GSSAPI). If Kerberos is enabled through SSH, the SSH daemon provides a means of access to the system's Kerberos implementation. Vulnerabilities in the system's Kerberos implementations may be subject to exploitation. diff --git a/linux_os/guide/services/ssh/ssh_server/sshd_disable_rhosts/policy/stig/shared.yml b/linux_os/guide/services/ssh/ssh_server/sshd_disable_rhosts/policy/stig/shared.yml index 5fdc622e151f..3b19409cc3cc 100644 --- a/linux_os/guide/services/ssh/ssh_server/sshd_disable_rhosts/policy/stig/shared.yml +++ b/linux_os/guide/services/ssh/ssh_server/sshd_disable_rhosts/policy/stig/shared.yml @@ -2,8 +2,7 @@ srg_requirement: |- {{{ full_name }}} SSH daemon must not allow rhosts authentication. vuldiscussion: |- - SSH trust relationships mean a compromise on one host - can allow an attacker to move trivially to other hosts. + SSH trust relationships mean a compromise on one host can allow an attacker to move trivially to other hosts. checktext: |- Verify the SSH daemon does not allow rhosts authentication with the following command: @@ -25,5 +24,3 @@ fixtext: |- $ sudo systemctl restart sshd.service -vuln_discussion: |- - SSH trust relationships mean a compromise on one host can allow an attacker to move trivially to other hosts. diff --git a/linux_os/guide/services/ssh/ssh_server/sshd_disable_root_login/policy/stig/shared.yml b/linux_os/guide/services/ssh/ssh_server/sshd_disable_root_login/policy/stig/shared.yml index fa838267202f..4d20ae383528 100644 --- a/linux_os/guide/services/ssh/ssh_server/sshd_disable_root_login/policy/stig/shared.yml +++ b/linux_os/guide/services/ssh/ssh_server/sshd_disable_root_login/policy/stig/shared.yml @@ -2,11 +2,7 @@ srg_requirement: |- {{{ full_name }}} must not permit direct logons to the root account using remote access via SSH. vuldiscussion: |- - Even though the communications channel may be encrypted, an additional layer of - security is gained by extending the policy of not logging directly on as root. - In addition, logging in with a user-specific account provides individual - accountability of actions performed on the system and also helps to minimize - direct attack attempts on root's password. + Even though the communications channel may be encrypted, an additional layer of security is gained by extending the policy of not logging directly on as root. In addition, logging in with a user-specific account provides individual accountability of actions performed on the system and also helps to minimize direct attack attempts on root's password. checktext: |- Verify {{{ full_name }}} remote access using SSH prevents users from logging on directly as "root" with the following command: @@ -26,5 +22,3 @@ fixtext: |- $ sudo systemctl restart sshd.service -vuln_discussion: |- - Even though the communications channel may be encrypted, an additional layer of security is gained by extending the policy of not logging directly on as root. In addition, logging in with a user-specific account provides individual accountability of actions performed on the system and also helps to minimize direct attack attempts on root's password. diff --git a/linux_os/guide/services/ssh/ssh_server/sshd_disable_user_known_hosts/policy/stig/shared.yml b/linux_os/guide/services/ssh/ssh_server/sshd_disable_user_known_hosts/policy/stig/shared.yml index 751cd35c27b3..814a0ae327a9 100644 --- a/linux_os/guide/services/ssh/ssh_server/sshd_disable_user_known_hosts/policy/stig/shared.yml +++ b/linux_os/guide/services/ssh/ssh_server/sshd_disable_user_known_hosts/policy/stig/shared.yml @@ -2,9 +2,7 @@ srg_requirement: |- {{{ full_name }}} SSH daemon must not allow known hosts authentication. vuldiscussion: |- - Configuring the IgnoreUserKnownHosts setting for the SSH daemon provides additional - assurance that remote login via SSH will require a password, even - in the event of misconfiguration elsewhere. + Configuring the IgnoreUserKnownHosts setting for the SSH daemon provides additional assurance that remote login via SSH will require a password, even in the event of misconfiguration elsewhere. checktext: |- Verify the SSH daemon does not allow known hosts authentication with the following command: @@ -26,5 +24,3 @@ fixtext: |- $ sudo systemctl restart sshd.service -vuln_discussion: |- - Configuring the IgnoreUserKnownHosts setting for the SSH daemon provides additional assurance that remote login via SSH will require a password, even in the event of misconfiguration elsewhere. diff --git a/linux_os/guide/services/ssh/ssh_server/sshd_disable_x11_forwarding/policy/stig/shared.yml b/linux_os/guide/services/ssh/ssh_server/sshd_disable_x11_forwarding/policy/stig/shared.yml index d392994931ee..e4e96c835691 100644 --- a/linux_os/guide/services/ssh/ssh_server/sshd_disable_x11_forwarding/policy/stig/shared.yml +++ b/linux_os/guide/services/ssh/ssh_server/sshd_disable_x11_forwarding/policy/stig/shared.yml @@ -2,7 +2,7 @@ srg_requirement: |- {{{ full_name }}} SSH daemon must disable remote X connections for interactive users. vuldiscussion: |- - When X11 forwarding is enabled, there may be additional exposure to the server and client displays if the sshd proxy display is configured to listen on the wildcard address. By default, sshd binds the forwarding server to the loopback address and sets the hostname part of the DIPSLAY environment variable to localhost. This prevents remote hosts from connecting to the proxy display. + When X11 forwarding is enabled, there may be additional exposure to the server and client displays if the sshd proxy display is configured to listen on the wildcard address. By default, sshd binds the forwarding server to the loopback address and sets the hostname part of the DISPLAY environment variable to localhost. This prevents remote hosts from connecting to the proxy display. checktext: |- Verify the SSH daemon does not allow X11Forwarding with the following command: @@ -24,5 +24,3 @@ fixtext: |- $ sudo systemctl restart sshd.service -vuln_discussion: |- - When X11 forwarding is enabled, there may be additional exposure to the server and client displays if the sshd proxy display is configured to listen on the wildcard address. By default, sshd binds the forwarding server to the loopback address and sets the hostname part of the DISPLAY environment variable to localhost. This prevents remote hosts from connecting to the proxy display. diff --git a/linux_os/guide/services/ssh/ssh_server/sshd_do_not_permit_user_env/policy/stig/shared.yml b/linux_os/guide/services/ssh/ssh_server/sshd_do_not_permit_user_env/policy/stig/shared.yml index 4bf1b93a03db..ab780492362f 100644 --- a/linux_os/guide/services/ssh/ssh_server/sshd_do_not_permit_user_env/policy/stig/shared.yml +++ b/linux_os/guide/services/ssh/ssh_server/sshd_do_not_permit_user_env/policy/stig/shared.yml @@ -2,8 +2,7 @@ srg_requirement: |- {{{ full_name }}} must not allow users to override SSH environment variables. vuldiscussion: |- - SSH environment options potentially allow users to bypass - access restriction in some configurations. + SSH environment options potentially allow users to bypass access restriction in some configurations. checktext: |- Verify that unattended or automatic logon via SSH is disabled with the following command: @@ -27,5 +26,3 @@ fixtext: |- $ sudo systemctl restart sshd.service -vuln_discussion: |- - SSH environment options potentially allow users to bypass access restriction in some configurations. diff --git a/linux_os/guide/services/ssh/ssh_server/sshd_enable_pam/policy/stig/shared.yml b/linux_os/guide/services/ssh/ssh_server/sshd_enable_pam/policy/stig/shared.yml index 5825e551ebf2..bcc9dfe51f3d 100644 --- a/linux_os/guide/services/ssh/ssh_server/sshd_enable_pam/policy/stig/shared.yml +++ b/linux_os/guide/services/ssh/ssh_server/sshd_enable_pam/policy/stig/shared.yml @@ -2,10 +2,7 @@ srg_requirement: |- {{{ full_name }}} must enable the Pluggable Authentication Module (PAM) interface for SSHD. vuldiscussion: |- - When UsePAM is set to yes, PAM runs through account and session types properly. This is - important if you want to restrict access to services based off of IP, time or other factors of - the account. Additionally, you can make sure users inherit certain environment variables - on login or disallow access to the server. + When UsePAM is set to "yes", PAM runs through account and session types properly. This is important when restricted access to services based off of IP, time, or other factors of the account is needed. Additionally, this ensures users can inherit certain environment variables on login or disallow access to the server. checktext: |- Verify the {{{ full_name }}} SSHD is configured to allow for the UsePAM interface with the following command: @@ -25,5 +22,3 @@ fixtext: |- $ sudo systemctl restart sshd.service -vuln_discussion: |- - When UsePAM is set to "yes", PAM runs through account and session types properly. This is important when restricted access to services based off of IP, time, or other factors of the account is needed. Additionally, this ensures users can inherit certain environment variables on login or disallow access to the server. diff --git a/linux_os/guide/services/ssh/ssh_server/sshd_enable_pubkey_auth/policy/stig/shared.yml b/linux_os/guide/services/ssh/ssh_server/sshd_enable_pubkey_auth/policy/stig/shared.yml index b5fea4a3ba92..8a99fe7c36a4 100644 --- a/linux_os/guide/services/ssh/ssh_server/sshd_enable_pubkey_auth/policy/stig/shared.yml +++ b/linux_os/guide/services/ssh/ssh_server/sshd_enable_pubkey_auth/policy/stig/shared.yml @@ -2,13 +2,7 @@ srg_requirement: |- {{{ full_name }}} SSHD must accept public key authentication. vuldiscussion: |- - Without the use of multifactor authentication, the ease of access to - privileged functions is greatly increased. Multifactor authentication - requires using two or more factors to achieve authentication. - A privileged account is defined as an information system account with - authorizations of a privileged user. - The DoD CAC with DoD-approved PKI is an example of multifactor - authentication. + Without the use of multifactor authentication, the ease of access to privileged functions is greatly increased. Multifactor authentication requires using two or more factors to achieve authentication. A privileged account is defined as an information system account with authorizations of a privileged user. A DOD CAC with DOD-approved PKI is an example of multifactor authentication. checktext: |- Verify that {{{ full_name }}} SSH daemon accepts public key encryption with the following command: @@ -28,5 +22,3 @@ fixtext: |- $ sudo systemctl restart sshd.service -vuln_discussion: |- - Without the use of multifactor authentication, the ease of access to privileged functions is greatly increased. Multifactor authentication requires using two or more factors to achieve authentication. A privileged account is defined as an information system account with authorizations of a privileged user. A DOD CAC with DOD-approved PKI is an example of multifactor authentication. diff --git a/linux_os/guide/services/ssh/ssh_server/sshd_enable_strictmodes/policy/stig/shared.yml b/linux_os/guide/services/ssh/ssh_server/sshd_enable_strictmodes/policy/stig/shared.yml index 0390d30bf5ea..6f799d65a020 100644 --- a/linux_os/guide/services/ssh/ssh_server/sshd_enable_strictmodes/policy/stig/shared.yml +++ b/linux_os/guide/services/ssh/ssh_server/sshd_enable_strictmodes/policy/stig/shared.yml @@ -24,5 +24,3 @@ fixtext: |- $ sudo systemctl restart sshd.service -vuln_discussion: |- - If other users have access to modify user-specific SSH configuration files, they may be able to log into the system as another user. diff --git a/linux_os/guide/services/ssh/ssh_server/sshd_enable_warning_banner/policy/stig/shared.yml b/linux_os/guide/services/ssh/ssh_server/sshd_enable_warning_banner/policy/stig/shared.yml index 215fa0fc498a..ccd7de60d87b 100644 --- a/linux_os/guide/services/ssh/ssh_server/sshd_enable_warning_banner/policy/stig/shared.yml +++ b/linux_os/guide/services/ssh/ssh_server/sshd_enable_warning_banner/policy/stig/shared.yml @@ -2,10 +2,7 @@ srg_requirement: |- {{{ full_name }}} must display the Standard Mandatory DOD Notice and Consent Banner before granting local or remote access to the system via a SSH logon. vuldiscussion: |- - The warning message reinforces policy awareness during the logon process and - facilitates possible legal action against attackers. Alternatively, systems - whose ownership should not be obvious should ensure usage of a banner that does - not provide easy attribution. + The warning message reinforces policy awareness during the logon process and facilitates possible legal action against attackers. Alternatively, systems whose ownership should not be obvious should ensure usage of a banner that does not provide easy attribution. checktext: |- Verify any SSH connection to the operating system displays the Standard Mandatory DOD Notice and Consent Banner before granting access to the system. @@ -29,5 +26,3 @@ fixtext: |- Banner /etc/issue -vuln_discussion: |- - The warning message reinforces policy awareness during the logon process and facilitates possible legal action against attackers. Alternatively, systems whose ownership should not be obvious should ensure usage of a banner that does not provide easy attribution. diff --git a/linux_os/guide/services/ssh/ssh_server/sshd_print_last_log/policy/stig/shared.yml b/linux_os/guide/services/ssh/ssh_server/sshd_print_last_log/policy/stig/shared.yml index 198ff8b7b6e7..65eb44118b80 100644 --- a/linux_os/guide/services/ssh/ssh_server/sshd_print_last_log/policy/stig/shared.yml +++ b/linux_os/guide/services/ssh/ssh_server/sshd_print_last_log/policy/stig/shared.yml @@ -24,5 +24,3 @@ fixtext: |- $ sudo systemctl restart sshd.service -vuln_discussion: |- - Providing users feedback on when account accesses last occurred facilitates user recognition and reporting of unauthorized account use. diff --git a/linux_os/guide/services/ssh/ssh_server/sshd_set_loglevel_verbose/policy/stig/shared.yml b/linux_os/guide/services/ssh/ssh_server/sshd_set_loglevel_verbose/policy/stig/shared.yml index 252ec018c981..2a4f64c6edf0 100644 --- a/linux_os/guide/services/ssh/ssh_server/sshd_set_loglevel_verbose/policy/stig/shared.yml +++ b/linux_os/guide/services/ssh/ssh_server/sshd_set_loglevel_verbose/policy/stig/shared.yml @@ -2,13 +2,7 @@ srg_requirement: |- {{{ full_name }}} must log SSH connection attempts and failures to the server. vuldiscussion: |- - SSH provides several logging levels with varying amounts of verbosity. "DEBUG" is specifically - not recommended other than strictly for debugging SSH communications since it provides - so much data that it is difficult to identify important security information. "INFO" or - "VERBOSE" level is the basic level that only records login activity of SSH users. In many - situations, such as Incident Response, it is important to determine when a particular user was active - on a system. The logout record can eliminate those users who disconnected, which helps narrow the - field. + SSH provides several logging levels with varying amounts of verbosity. "DEBUG" is specifically not recommended other than strictly for debugging SSH communications since it provides so much data that it is difficult to identify important security information. "INFO" or "VERBOSE" level is the basic level that only records login activity of SSH users. In many situations, such as Incident Response, it is important to determine when a particular user was active on a system. The logout record can eliminate those users who disconnected, which helps narrow the field. checktext: |- Verify {{{ full_name }}} logs SSH connection attempts and failures to the server. @@ -30,5 +24,3 @@ fixtext: |- $ sudo systemctl restart sshd.service -vuln_discussion: |- - SSH provides several logging levels with varying amounts of verbosity. "DEBUG" is specifically not recommended other than strictly for debugging SSH communications since it provides so much data that it is difficult to identify important security information. "INFO" or "VERBOSE" level is the basic level that only records login activity of SSH users. In many situations, such as Incident Response, it is important to determine when a particular user was active on a system. The logout record can eliminate those users who disconnected, which helps narrow the field. diff --git a/linux_os/guide/services/ssh/ssh_server/sshd_use_priv_separation/policy/stig/shared.yml b/linux_os/guide/services/ssh/ssh_server/sshd_use_priv_separation/policy/stig/shared.yml index 84e416090a15..05cf76e940b1 100644 --- a/linux_os/guide/services/ssh/ssh_server/sshd_use_priv_separation/policy/stig/shared.yml +++ b/linux_os/guide/services/ssh/ssh_server/sshd_use_priv_separation/policy/stig/shared.yml @@ -21,5 +21,3 @@ checktext: |- If the "UsePrivilegeSeparation" keyword is set to "no", the returned line is commented out, or no output is returned, this is a finding. -vuln_discussion: |- - SSH daemon privilege separation causes the SSH process to drop root privileges when not needed, which would decrease the impact of software vulnerabilities in the nonprivileged section. diff --git a/linux_os/guide/services/ssh/ssh_server/sshd_x11_use_localhost/policy/stig/shared.yml b/linux_os/guide/services/ssh/ssh_server/sshd_x11_use_localhost/policy/stig/shared.yml index 3af626d16f59..e3edfe8017c0 100644 --- a/linux_os/guide/services/ssh/ssh_server/sshd_x11_use_localhost/policy/stig/shared.yml +++ b/linux_os/guide/services/ssh/ssh_server/sshd_x11_use_localhost/policy/stig/shared.yml @@ -2,12 +2,7 @@ srg_requirement: |- {{{ full_name }}} SSH daemon must prevent remote hosts from connecting to the proxy display. vuldiscussion: |- - When X11 forwarding is enabled, there may be additional exposure to the - server and client displays if the sshd proxy display is configured to listen - on the wildcard address. By default, sshd binds the forwarding server to the - loopback address and sets the hostname part of the "DISPLAY" - environment variable to localhost. This prevents remote hosts from - connecting to the proxy display. + When X11 forwarding is enabled, there may be additional exposure to the server and client displays if the sshd proxy display is configured to listen on the wildcard address. By default, sshd binds the forwarding server to the loopback address and sets the hostname part of the "DISPLAY" environment variable to localhost. This prevents remote hosts from connecting to the proxy display. checktext: |- Verify the SSH daemon prevents remote hosts from connecting to the proxy display with the following command: @@ -29,5 +24,3 @@ fixtext: |- $ sudo systemctl restart sshd.service -vuln_discussion: |- - When X11 forwarding is enabled, there may be additional exposure to the server and client displays if the sshd proxy display is configured to listen on the wildcard address. By default, sshd binds the forwarding server to the loopback address and sets the hostname part of the "DISPLAY" environment variable to localhost. This prevents remote hosts from connecting to the proxy display. diff --git a/linux_os/guide/services/sssd/sssd_enable_certmap/policy/stig/shared.yml b/linux_os/guide/services/sssd/sssd_enable_certmap/policy/stig/shared.yml index 2ae072232ffa..b5094a9ba391 100644 --- a/linux_os/guide/services/sssd/sssd_enable_certmap/policy/stig/shared.yml +++ b/linux_os/guide/services/sssd/sssd_enable_certmap/policy/stig/shared.yml @@ -28,5 +28,3 @@ fixtext: |- $ sudo systemctl restart sssd.service -vuln_discussion: |- - Without mapping the certificate used to authenticate to the user account, the ability to determine the identity of the individual user or group will not be available for forensic analysis. diff --git a/linux_os/guide/services/sssd/sssd_enable_smartcards/policy/stig/shared.yml b/linux_os/guide/services/sssd/sssd_enable_smartcards/policy/stig/shared.yml index 1c492b915535..4060e6dad6c2 100644 --- a/linux_os/guide/services/sssd/sssd_enable_smartcards/policy/stig/shared.yml +++ b/linux_os/guide/services/sssd/sssd_enable_smartcards/policy/stig/shared.yml @@ -2,13 +2,7 @@ srg_requirement: |- {{{ full_name }}} must enable certificate based smart card authentication. vuldiscussion: |- - Without the use of multifactor authentication, the ease of access to - privileged functions is greatly increased. Multifactor authentication - requires using two or more factors to achieve authentication. - A privileged account is defined as an information system account with - authorizations of a privileged user. - The DoD CAC with DoD-approved PKI is an example of multifactor - authentication. + Without the use of multifactor authentication, the ease of access to privileged functions is greatly increased. Multifactor authentication requires using two or more factors to achieve authentication. A privileged account is defined as an information system account with authorizations of a privileged user. The DOD Common Access Card (CAC) with DOD-approved PKI is an example of multifactor authentication. checktext: |- Verify that {{{ full_name }}} has smart cards are enabled in System Security Services Daemon (SSSD), run the following command: @@ -24,5 +18,3 @@ fixtext: |- pam_cert_auth = True -vuln_discussion: |- - Without the use of multifactor authentication, the ease of access to privileged functions is greatly increased. Multifactor authentication requires using two or more factors to achieve authentication. A privileged account is defined as an information system account with authorizations of a privileged user. The DOD Common Access Card (CAC) with DOD-approved PKI is an example of multifactor authentication. diff --git a/linux_os/guide/services/sssd/sssd_has_trust_anchor/policy/stig/shared.yml b/linux_os/guide/services/sssd/sssd_has_trust_anchor/policy/stig/shared.yml index 702f7cf91dda..813eb5c96daf 100644 --- a/linux_os/guide/services/sssd/sssd_has_trust_anchor/policy/stig/shared.yml +++ b/linux_os/guide/services/sssd/sssd_has_trust_anchor/policy/stig/shared.yml @@ -40,11 +40,3 @@ fixtext: |- Obtain a valid copy of the DoD root CA file from the PKI CA certificate bundle from cyber.mil and copy the DoD_PKE_CA_chain.pem into the following file: /etc/sssd/pki/sssd_auth_ca_db.pem -vuln_discussion: |- - Without path validation, an informed trust decision by the relying party cannot be made when presented with any certificate not already explicitly trusted. - - A trust anchor is an authoritative entity represented via a public key and associated data. It is used in the context of public key infrastructures, X.509 digital certificates, and DNSSEC. - - When there is a chain of trust, usually the top entity to be trusted becomes the trust anchor; it can be, for example, a Certification Authority (CA). A certification path starts with the subject certificate and proceeds through a number of intermediate certificates up to a trusted root certificate, typically issued by a trusted CA. - - This requirement verifies that a certification path to an accepted trust anchor is used for certificate validation and that the path includes status information. Path validation is necessary for a relying party to make an informed trust decision when presented with any certificate not already explicitly trusted. Status information for certification paths includes certificate revocation lists or online certificate status protocol responses. Validation of the certificate status information is out of scope for this requirement. diff --git a/linux_os/guide/services/sssd/sssd_offline_cred_expiration/policy/stig/shared.yml b/linux_os/guide/services/sssd/sssd_offline_cred_expiration/policy/stig/shared.yml index 4323ab6b82da..89b4236013ab 100644 --- a/linux_os/guide/services/sssd/sssd_offline_cred_expiration/policy/stig/shared.yml +++ b/linux_os/guide/services/sssd/sssd_offline_cred_expiration/policy/stig/shared.yml @@ -32,5 +32,3 @@ fixtext: |- offline_credentials_expiration = 1 -vuln_discussion: |- - If cached authentication information is out-of-date, the validity of the authentication information may be questionable. diff --git a/linux_os/guide/services/usbguard/configure_usbguard_auditbackend/policy/stig/shared.yml b/linux_os/guide/services/usbguard/configure_usbguard_auditbackend/policy/stig/shared.yml index 5e2630189986..f3003690583f 100644 --- a/linux_os/guide/services/usbguard/configure_usbguard_auditbackend/policy/stig/shared.yml +++ b/linux_os/guide/services/usbguard/configure_usbguard_auditbackend/policy/stig/shared.yml @@ -10,7 +10,7 @@ vuldiscussion: |- The list of audited events is the set of events for which audits are to be generated. This set of events is typically a subset of the list of all events for which the system is capable of generating audit records. - DoD has defined the list of events for which {{{ full_name }}} will provide an audit record generation capability as the following: + DOD has defined the list of events for which {{{ full_name }}} will provide an audit record generation capability as the following: 1) Successful and unsuccessful attempts to access, modify, or delete privileges, security objects, security levels, or categories of information (e.g., classification levels); @@ -36,21 +36,3 @@ fixtext: |- AuditBackend=LinuxAudit -vuln_discussion: |- - Without the capability to generate audit records, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. - - If auditing is enabled late in the startup process, the actions of some startup processes may not be audited. Some audit systems also maintain state information only available if auditing is enabled before a given process is created. - - Audit records can be generated from various components within the information system (e.g., module or policy filter). - - The list of audited events is the set of events for which audits are to be generated. This set of events is typically a subset of the list of all events for which the system is capable of generating audit records. - - DOD has defined the list of events for which {{{ full_name }}} will provide an audit record generation capability as the following: - - 1) Successful and unsuccessful attempts to access, modify, or delete privileges, security objects, security levels, or categories of information (e.g., classification levels); - - 2) Access actions, such as successful and unsuccessful logon attempts, privileged activities or other system-level access, starting and ending time for user access to the system, concurrent logons from different workstations, successful and unsuccessful accesses to objects, all program initiations, and all direct access to the information system; - - 3) All account creations, modifications, disabling, and terminations; and - - 4) All kernel module load, unload, and restart actions. diff --git a/linux_os/guide/services/usbguard/package_usbguard_installed/policy/stig/shared.yml b/linux_os/guide/services/usbguard/package_usbguard_installed/policy/stig/shared.yml index ffe242c471bb..0cc9bfb5dca2 100644 --- a/linux_os/guide/services/usbguard/package_usbguard_installed/policy/stig/shared.yml +++ b/linux_os/guide/services/usbguard/package_usbguard_installed/policy/stig/shared.yml @@ -4,7 +4,7 @@ srg_requirement: |- vuldiscussion: |- The USBguard-daemon is the main component of the USBGuard software framework. It runs as a service in the background and enforces the USB device authorization policy for all USB devices. The policy is defined by a set of rules using a rule language described in the usbguard-rules.conf file. The policy and the authorization state of USB devices can be modified during runtime using the usbguard tool. - The System Administrator (SA) must work with the site Information System Security Officer (ISSO) to determine a list of authorized peripherals and establish rules within the USBGuard software framework to allow only authorized devices. + The system administrator (SA) must work with the site information system security officer (ISSO) to determine a list of authorized peripherals and establish rules within the USBGuard software framework to allow only authorized devices. checktext: |- Verify USBGuard is installed on the operating system with the following command: @@ -25,7 +25,3 @@ fixtext: |- $ sudo dnf install usbguard -vuln_discussion: |- - The USBguard-daemon is the main component of the USBGuard software framework. It runs as a service in the background and enforces the USB device authorization policy for all USB devices. The policy is defined by a set of rules using a rule language described in the usbguard-rules.conf file. The policy and the authorization state of USB devices can be modified during runtime using the usbguard tool. - - The system administrator (SA) must work with the site information system security officer (ISSO) to determine a list of authorized peripherals and establish rules within the USBGuard software framework to allow only authorized devices. diff --git a/linux_os/guide/services/usbguard/service_usbguard_enabled/policy/stig/shared.yml b/linux_os/guide/services/usbguard/service_usbguard_enabled/policy/stig/shared.yml index 39fd2351d9bf..fab3a25c2416 100644 --- a/linux_os/guide/services/usbguard/service_usbguard_enabled/policy/stig/shared.yml +++ b/linux_os/guide/services/usbguard/service_usbguard_enabled/policy/stig/shared.yml @@ -4,7 +4,7 @@ srg_requirement: |- vuldiscussion: |- The USBguard-daemon is the main component of the USBGuard software framework. It runs as a service in the background and enforces the USB device authorization policy for all USB devices. The policy is defined by a set of rules using a rule language described in the usbguard-rules.conf file. The policy and the authorization state of USB devices can be modified during runtime using the usbguard tool. - The System Administrator (SA) must work with the site Information System Security Officer (ISSO) to determine a list of authorized peripherals and establish rules within the USBGuard software framework to allow only authorized devices. + The system administrator (SA) must work with the site information system security officer (ISSO) to determine a list of authorized peripherals and establish rules within the USBGuard software framework to allow only authorized devices. checktext: |- Verify {{{ full_name }}} has USBGuard enabled with the following command: @@ -22,7 +22,3 @@ fixtext: |- $ sudo systemctl enable --now usbguard -vuln_discussion: |- - The USBguard-daemon is the main component of the USBGuard software framework. It runs as a service in the background and enforces the USB device authorization policy for all USB devices. The policy is defined by a set of rules using a rule language described in the usbguard-rules.conf file. The policy and the authorization state of USB devices can be modified during runtime using the usbguard tool. - - The system administrator (SA) must work with the site information system security officer (ISSO) to determine a list of authorized peripherals and establish rules within the USBGuard software framework to allow only authorized devices. diff --git a/linux_os/guide/services/usbguard/usbguard_generate_policy/policy/stig/shared.yml b/linux_os/guide/services/usbguard/usbguard_generate_policy/policy/stig/shared.yml index bcef45e9a961..209bab3bed81 100644 --- a/linux_os/guide/services/usbguard/usbguard_generate_policy/policy/stig/shared.yml +++ b/linux_os/guide/services/usbguard/usbguard_generate_policy/policy/stig/shared.yml @@ -4,7 +4,7 @@ srg_requirement: |- vuldiscussion: |- The USBguard-daemon is the main component of the USBGuard software framework. It runs as a service in the background and enforces the USB device authorization policy for all USB devices. The policy is defined by a set of rules using a rule language described in the usbguard-rules.conf file. The policy and the authorization state of USB devices can be modified during runtime using the usbguard tool. - The System Administrator (SA) must work with the site Information System Security Officer (ISSO) to determine a list of authorized peripherals and establish rules within the USBGuard software framework to allow only authorized devices. + The system administrator (SA) must work with the site information system security officer (ISSO) to determine a list of authorized peripherals and establish rules within the USBGuard software framework to allow only authorized devices. checktext: |- Verify the USBGuard has a policy configured with the following command: @@ -28,7 +28,3 @@ fixtext: |- Note: Enabling and starting usbguard without properly configuring it for an individual system will immediately prevent any access over a usb device such as a keyboard or mouse. -vuln_discussion: |- - The USBguard-daemon is the main component of the USBGuard software framework. It runs as a service in the background and enforces the USB device authorization policy for all USB devices. The policy is defined by a set of rules using a rule language described in the usbguard-rules.conf file. The policy and the authorization state of USB devices can be modified during runtime using the usbguard tool. - - The system administrator (SA) must work with the site information system security officer (ISSO) to determine a list of authorized peripherals and establish rules within the USBGuard software framework to allow only authorized devices. diff --git a/linux_os/guide/services/xwindows/disabling_xwindows/xwindows_remove_packages/policy/stig/shared.yml b/linux_os/guide/services/xwindows/disabling_xwindows/xwindows_remove_packages/policy/stig/shared.yml index 896a7ab36f2c..f9a4e0b126b6 100644 --- a/linux_os/guide/services/xwindows/disabling_xwindows/xwindows_remove_packages/policy/stig/shared.yml +++ b/linux_os/guide/services/xwindows/disabling_xwindows/xwindows_remove_packages/policy/stig/shared.yml @@ -2,8 +2,8 @@ srg_requirement: |- A graphical display manager must not be installed on {{{ full_name }}} unless approved. vuldiscussion: |- - Unnecessary service packages must not be installed to decrease the attack surface of the system. X windows has a long history of security - vulnerabilities and should not be installed unless approved and documented. + Unnecessary service packages must not be installed to decrease the attack surface of the system. + Graphical display managers have a long history of security vulnerabilities and must not be used, unless approved and documented. checktext: |- Verify that a graphical user interface is not installed with the following command: @@ -26,6 +26,3 @@ fixtext: |- $ sudo dnf remove "xorg*" $ sudo systemctl set-default multi-user.target -vuln_discussion: |- - Unnecessary service packages must not be installed to decrease the attack surface of the system. - Graphical display managers have a long history of security vulnerabilities and must not be used, unless approved and documented. diff --git a/linux_os/guide/services/xwindows/disabling_xwindows/xwindows_runlevel_target/policy/stig/shared.yml b/linux_os/guide/services/xwindows/disabling_xwindows/xwindows_runlevel_target/policy/stig/shared.yml index 16aa14e2e6ff..41219bcd9124 100644 --- a/linux_os/guide/services/xwindows/disabling_xwindows/xwindows_runlevel_target/policy/stig/shared.yml +++ b/linux_os/guide/services/xwindows/disabling_xwindows/xwindows_runlevel_target/policy/stig/shared.yml @@ -2,8 +2,7 @@ srg_requirement: |- The graphical display manager must not be the default target on {{{ full_name }}} unless approved. vuldiscussion: |- - Unnecessary service packages must not be installed to decrease the attack surface of the system. - Graphical display managers have a long history of security vulnerabilities and must not be used, unless approved and documented. + Unnecessary service packages must not be installed to decrease the attack surface of the system. Graphical display managers have a long history of security vulnerabilities and must not be used, unless approved and documented. checktext: |- Verify that {{{ full_name }}} is configured to boot to the command line: @@ -19,5 +18,3 @@ fixtext: |- $ sudo systemctl set-default multi-user.target -vuln_discussion: |- - Unnecessary service packages must not be installed to decrease the attack surface of the system. Graphical display managers have a long history of security vulnerabilities and must not be used, unless approved and documented. diff --git a/linux_os/guide/system/accounts/accounts-banners/gui_login_banner/dconf_gnome_banner_enabled/policy/stig/shared.yml b/linux_os/guide/system/accounts/accounts-banners/gui_login_banner/dconf_gnome_banner_enabled/policy/stig/shared.yml index 6741da9a8fea..a25b75fa04e2 100644 --- a/linux_os/guide/system/accounts/accounts-banners/gui_login_banner/dconf_gnome_banner_enabled/policy/stig/shared.yml +++ b/linux_os/guide/system/accounts/accounts-banners/gui_login_banner/dconf_gnome_banner_enabled/policy/stig/shared.yml @@ -2,14 +2,9 @@ srg_requirement: |- {{{ full_name }}} must prevent a user from overriding the banner-message-enable setting for the graphical user interface. vuldiscussion: |- - Display of a standardized and approved use notification before granting access to the operating system - ensures privacy and security notification verbiage used is consistent with applicable federal laws, - Executive Orders, directives, policies, regulations, standards, and guidance. - - + Display of a standardized and approved use notification before granting access to the operating system ensures privacy and security notification verbiage used is consistent with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance. - For U.S. Government systems, system use notifications are required only for access via login interfaces - with human users and are not required when such human interfaces do not exist. + For U.S. Government systems, system use notifications are required only for access via login interfaces with human users and are not required when such human interfaces do not exist. checktext: |- Verify {{{ full_name }}} prevents a user from overriding settings for graphical user interfaces. @@ -47,9 +42,3 @@ fixtext: |- $ sudo dconf update -vuln_discussion: |- - Display of a standardized and approved use notification before granting access to the operating system ensures privacy and security notification verbiage used is consistent with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance. - - For U.S. Government systems, system use notifications are required only for access via login interfaces with human users and are not required when such human interfaces do not exist. - - diff --git a/linux_os/guide/system/accounts/accounts-pam/disallow_bypass_password_sudo/policy/stig/shared.yml b/linux_os/guide/system/accounts/accounts-pam/disallow_bypass_password_sudo/policy/stig/shared.yml index f21af7d709e5..cb851054f3f2 100644 --- a/linux_os/guide/system/accounts/accounts-pam/disallow_bypass_password_sudo/policy/stig/shared.yml +++ b/linux_os/guide/system/accounts/accounts-pam/disallow_bypass_password_sudo/policy/stig/shared.yml @@ -2,9 +2,7 @@ srg_requirement: |- {{{ full_name }}} must not be configured to bypass password requirements for privilege escalation. vuldiscussion: |- - Without re-authentication, users may access resources or perform tasks for which they do not - have authorization. When operating systems provide the capability to escalate a functional - capability, it is critical the user re-authenticate. + 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. checktext: |- Verify the operating system is not configured to bypass password requirements for privilege escalation with the following command: @@ -18,5 +16,3 @@ fixtext: |- Remove any occurrences of " pam_succeed_if " in the "/etc/pam.d/sudo" file. -vuln_discussion: |- - 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. diff --git a/linux_os/guide/system/accounts/accounts-pam/display_login_attempts/policy/stig/shared.yml b/linux_os/guide/system/accounts/accounts-pam/display_login_attempts/policy/stig/shared.yml index dc41c9b019a4..3c7314bef9f5 100644 --- a/linux_os/guide/system/accounts/accounts-pam/display_login_attempts/policy/stig/shared.yml +++ b/linux_os/guide/system/accounts/accounts-pam/display_login_attempts/policy/stig/shared.yml @@ -2,11 +2,7 @@ srg_requirement: |- {{{ full_name }}} must display the date and time of the last successful account logon upon logon. vuldiscussion: |- - Users need to be aware of activity that occurs regarding - their account. Providing users with information regarding the number - of unsuccessful attempts that were made to login to their account - allows the user to determine if any unauthorized activity has occurred - and gives them an opportunity to notify administrators. + Users need to be aware of activity that occurs regarding their account. Providing users with information regarding the number of unsuccessful attempts that were made to login to their account allows the user to determine if any unauthorized activity has occurred and gives them an opportunity to notify administrators. checktext: |- Verify users are provided with feedback on when account accesses last occurred with the following command: @@ -24,5 +20,3 @@ fixtext: |- session required pam_lastlog.so showfailed -vuln_discussion: |- - Users need to be aware of activity that occurs regarding their account. Providing users with information regarding the number of unsuccessful attempts that were made to login to their account allows the user to determine if any unauthorized activity has occurred and gives them an opportunity to notify administrators. diff --git a/linux_os/guide/system/accounts/accounts-pam/locking_out_password_attempts/account_password_pam_faillock_password_auth/policy/stig/shared.yml b/linux_os/guide/system/accounts/accounts-pam/locking_out_password_attempts/account_password_pam_faillock_password_auth/policy/stig/shared.yml index 317557a5d54e..0d0107471c62 100644 --- a/linux_os/guide/system/accounts/accounts-pam/locking_out_password_attempts/account_password_pam_faillock_password_auth/policy/stig/shared.yml +++ b/linux_os/guide/system/accounts/accounts-pam/locking_out_password_attempts/account_password_pam_faillock_password_auth/policy/stig/shared.yml @@ -2,8 +2,7 @@ srg_requirement: |- {{{ full_name }}} must configure the use of the pam_faillock.so module in the /etc/pam.d/password-auth file. vuldiscussion: |- - If the pam_faillock.so module is not loaded the system will not correctly lockout accounts to prevent - password guessing attacks. + If the pam_faillock.so module is not loaded, the system will not correctly lockout accounts to prevent password guessing attacks. checktext: |- Verify the pam_faillock.so module is present in the "/etc/pam.d/password-auth" file: @@ -26,5 +25,3 @@ fixtext: |- auth required pam_faillock.so authfail account required pam_faillock.so -vuln_discussion: |- - If the pam_faillock.so module is not loaded, the system will not correctly lockout accounts to prevent password guessing attacks. diff --git a/linux_os/guide/system/accounts/accounts-pam/locking_out_password_attempts/account_password_pam_faillock_system_auth/policy/stig/shared.yml b/linux_os/guide/system/accounts/accounts-pam/locking_out_password_attempts/account_password_pam_faillock_system_auth/policy/stig/shared.yml index 81c2afe4945d..9fe41b0e818e 100644 --- a/linux_os/guide/system/accounts/accounts-pam/locking_out_password_attempts/account_password_pam_faillock_system_auth/policy/stig/shared.yml +++ b/linux_os/guide/system/accounts/accounts-pam/locking_out_password_attempts/account_password_pam_faillock_system_auth/policy/stig/shared.yml @@ -2,8 +2,7 @@ srg_requirement: |- {{{ full_name }}} must configure the use of the pam_faillock.so module in the /etc/pam.d/system-auth file. vuldiscussion: |- - If the pam_faillock.so module is not loaded the system will not correctly lockout accounts to prevent - password guessing attacks. + If the pam_faillock.so module is not loaded, the system will not correctly lockout accounts to prevent password guessing attacks. checktext: |- Verify the pam_faillock.so module is present in the "/etc/pam.d/system-auth" file: @@ -26,5 +25,3 @@ fixtext: |- auth required pam_faillock.so authfail account required pam_faillock.so -vuln_discussion: |- - If the pam_faillock.so module is not loaded, the system will not correctly lockout accounts to prevent password guessing attacks. diff --git a/linux_os/guide/system/accounts/accounts-pam/locking_out_password_attempts/account_password_selinux_faillock_dir/policy/stig/shared.yml b/linux_os/guide/system/accounts/accounts-pam/locking_out_password_attempts/account_password_selinux_faillock_dir/policy/stig/shared.yml index 1cad18728fce..69d4ef8cda86 100644 --- a/linux_os/guide/system/accounts/accounts-pam/locking_out_password_attempts/account_password_selinux_faillock_dir/policy/stig/shared.yml +++ b/linux_os/guide/system/accounts/accounts-pam/locking_out_password_attempts/account_password_selinux_faillock_dir/policy/stig/shared.yml @@ -36,5 +36,3 @@ fixtext: |- $ sudo restorecon -R -v /var/log/faillock -vuln_discussion: |- - Not having the correct SELinux context on the faillock directory may lead to unauthorized access to the directory. diff --git a/linux_os/guide/system/accounts/accounts-pam/locking_out_password_attempts/accounts_password_pam_pwhistory_remember_system_auth/policy/stig/shared.yml b/linux_os/guide/system/accounts/accounts-pam/locking_out_password_attempts/accounts_password_pam_pwhistory_remember_system_auth/policy/stig/shared.yml index 0984370585e3..2d56a8370271 100644 --- a/linux_os/guide/system/accounts/accounts-pam/locking_out_password_attempts/accounts_password_pam_pwhistory_remember_system_auth/policy/stig/shared.yml +++ b/linux_os/guide/system/accounts/accounts-pam/locking_out_password_attempts/accounts_password_pam_pwhistory_remember_system_auth/policy/stig/shared.yml @@ -6,7 +6,7 @@ vuldiscussion: |- {{{ full_name }}} uses "pwhistory" consecutively as a mechanism to prohibit password reuse. This is set in both: /etc/pam.d/password-auth - /etc/pam.d/system-auth. + /etc/pam.d/system-auth Note that manual changes to the listed files may be overwritten by the "authselect" program. @@ -26,11 +26,3 @@ fixtext: |- password required pam_pwhistory.so use_authtok remember=5 retry=3 -vuln_discussion: |- - Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. If the information system or application allows the user to reuse their password consecutively when that password has exceeded its defined lifetime, the end result is a password that is not changed per policy requirements. - - {{{ full_name }}} uses "pwhistory" consecutively as a mechanism to prohibit password reuse. This is set in both: - /etc/pam.d/password-auth - /etc/pam.d/system-auth - - Note that manual changes to the listed files may be overwritten by the "authselect" program. diff --git a/linux_os/guide/system/accounts/accounts-pam/locking_out_password_attempts/accounts_passwords_pam_faillock_audit/policy/stig/shared.yml b/linux_os/guide/system/accounts/accounts-pam/locking_out_password_attempts/accounts_passwords_pam_faillock_audit/policy/stig/shared.yml index b9a9c22bb49e..140e9337ebbf 100644 --- a/linux_os/guide/system/accounts/accounts-pam/locking_out_password_attempts/accounts_passwords_pam_faillock_audit/policy/stig/shared.yml +++ b/linux_os/guide/system/accounts/accounts-pam/locking_out_password_attempts/accounts_passwords_pam_faillock_audit/policy/stig/shared.yml @@ -2,7 +2,7 @@ srg_requirement: |- {{{ full_name }}} must log username information when unsuccessful logon attempts occur. vuldiscussion: |- - Without auditing of these events it may be harder or impossible to identify what an attacker did after an attack. + Without auditing of these events, it may be harder or impossible to identify what an attacker did after an attack. checktext: |- Verify the "/etc/security/faillock.conf" file is configured to log username information when unsuccessful logon attempts occur with the following command: @@ -20,5 +20,3 @@ fixtext: |- audit -vuln_discussion: |- - Without auditing of these events, it may be harder or impossible to identify what an attacker did after an attack. diff --git a/linux_os/guide/system/accounts/accounts-pam/locking_out_password_attempts/accounts_passwords_pam_faillock_deny_root/policy/stig/shared.yml b/linux_os/guide/system/accounts/accounts-pam/locking_out_password_attempts/accounts_passwords_pam_faillock_deny_root/policy/stig/shared.yml index da5200fd6521..6cead1021a72 100644 --- a/linux_os/guide/system/accounts/accounts-pam/locking_out_password_attempts/accounts_passwords_pam_faillock_deny_root/policy/stig/shared.yml +++ b/linux_os/guide/system/accounts/accounts-pam/locking_out_password_attempts/accounts_passwords_pam_faillock_deny_root/policy/stig/shared.yml @@ -2,9 +2,7 @@ srg_requirement: |- {{{ full_name }}} must automatically lock the root account until the root account is released by an administrator when three unsuccessful logon attempts occur during a 15-minute time period. vuldiscussion: |- - By limiting the number of failed logon attempts, the risk of unauthorized system access via - user password guessing, also known as brute-forcing, is reduced. Limits are imposed by locking - the account. + By limiting the number of failed logon attempts, the risk of unauthorized system access via user password guessing, also known as brute-forcing, is reduced. Limits are imposed by locking the account. checktext: |- Verify {{{ full_name }}} is configured to lock the root account after three unsuccessful logon attempts with the command: @@ -25,5 +23,3 @@ fixtext: |- add or uncomment the following line: even_deny_root -vuln_discussion: |- - By limiting the number of failed logon attempts, the risk of unauthorized system access via user password guessing, also known as brute-forcing, is reduced. Limits are imposed by locking the account. diff --git a/linux_os/guide/system/accounts/accounts-pam/locking_out_password_attempts/accounts_passwords_pam_faillock_dir/policy/stig/shared.yml b/linux_os/guide/system/accounts/accounts-pam/locking_out_password_attempts/accounts_passwords_pam_faillock_dir/policy/stig/shared.yml index 3432ef641eed..f1ade3ea1e59 100644 --- a/linux_os/guide/system/accounts/accounts-pam/locking_out_password_attempts/accounts_passwords_pam_faillock_dir/policy/stig/shared.yml +++ b/linux_os/guide/system/accounts/accounts-pam/locking_out_password_attempts/accounts_passwords_pam_faillock_dir/policy/stig/shared.yml @@ -2,8 +2,7 @@ srg_requirement: |- {{{ full_name }}} must ensure account lockouts persist. vuldiscussion: |- - Having lockouts persist across reboots ensures that account is only unlocked by an administrator. - If the lockouts did not persist across reboots an attack could simply reboot the system to continue brute force attacks against the accounts on the system. + Having lockouts persist across reboots ensures that account is only unlocked by an administrator. If the lockouts did not persist across reboots, an attacker could simply reboot the system to continue brute force attacks against the accounts on the system. checktext: |- Verify the "/etc/security/faillock.conf" file is configured use a nondefault faillock directory to ensure contents persist after reboot with the following command: @@ -21,5 +20,3 @@ fixtext: |- dir = /var/log/faillock -vuln_discussion: |- - Having lockouts persist across reboots ensures that account is only unlocked by an administrator. If the lockouts did not persist across reboots, an attacker could simply reboot the system to continue brute force attacks against the accounts on the system. diff --git a/linux_os/guide/system/accounts/accounts-pam/password_quality/password_quality_pwquality/accounts_password_pam_enforce_root/policy/stig/shared.yml b/linux_os/guide/system/accounts/accounts-pam/password_quality/password_quality_pwquality/accounts_password_pam_enforce_root/policy/stig/shared.yml index 25bcd7fcadb1..3eb95f8147ee 100644 --- a/linux_os/guide/system/accounts/accounts-pam/password_quality/password_quality_pwquality/accounts_password_pam_enforce_root/policy/stig/shared.yml +++ b/linux_os/guide/system/accounts/accounts-pam/password_quality/password_quality_pwquality/accounts_password_pam_enforce_root/policy/stig/shared.yml @@ -24,7 +24,3 @@ fixtext: |- enforce_for_root -vuln_discussion: |- - 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. diff --git a/linux_os/guide/system/accounts/accounts-pam/password_quality/password_quality_pwquality/accounts_password_pam_pwquality_password_auth/policy/stig/shared.yml b/linux_os/guide/system/accounts/accounts-pam/password_quality/password_quality_pwquality/accounts_password_pam_pwquality_password_auth/policy/stig/shared.yml index 368f2ee7b39b..a4bd70dc5af0 100644 --- a/linux_os/guide/system/accounts/accounts-pam/password_quality/password_quality_pwquality/accounts_password_pam_pwquality_password_auth/policy/stig/shared.yml +++ b/linux_os/guide/system/accounts/accounts-pam/password_quality/password_quality_pwquality/accounts_password_pam_pwquality_password_auth/policy/stig/shared.yml @@ -2,8 +2,7 @@ srg_requirement: |- {{{ full_name }}} must ensure the password complexity module is enabled in the password-auth file. vuldiscussion: |- - Enabling PAM password complexity permits to enforce strong passwords and consequently - makes the system less prone to dictionary attacks. + Enabling PAM password complexity permits enforcement of strong passwords and consequently makes the system less prone to dictionary attacks. checktext: |- Verify {{{ full_name }}} uses "pwquality" to enforce the password complexity rules in the password-auth file with the following command: @@ -21,5 +20,3 @@ fixtext: |- password required pam_pwquality.so -vuln_discussion: |- - Enabling PAM password complexity permits enforcement of strong passwords and consequently makes the system less prone to dictionary attacks. diff --git a/linux_os/guide/system/accounts/accounts-pam/password_quality/password_quality_pwquality/accounts_password_pam_pwquality_system_auth/policy/stig/shared.yml b/linux_os/guide/system/accounts/accounts-pam/password_quality/password_quality_pwquality/accounts_password_pam_pwquality_system_auth/policy/stig/shared.yml index 3c305b7fbd16..b429c3c6ad46 100644 --- a/linux_os/guide/system/accounts/accounts-pam/password_quality/password_quality_pwquality/accounts_password_pam_pwquality_system_auth/policy/stig/shared.yml +++ b/linux_os/guide/system/accounts/accounts-pam/password_quality/password_quality_pwquality/accounts_password_pam_pwquality_system_auth/policy/stig/shared.yml @@ -2,8 +2,7 @@ srg_requirement: |- {{{ full_name }}} must ensure the password complexity module is enabled in the system-auth file. vuldiscussion: |- - Enabling PAM password complexity permits to enforce strong passwords and consequently - makes the system less prone to dictionary attacks. + Enabling PAM password complexity permits enforcement of strong passwords and consequently makes the system less prone to dictionary attacks. checktext: |- Verify {{{ full_name }}} uses "pwquality" to enforce the password complexity rules in the system-auth file with the following command: @@ -21,5 +20,3 @@ fixtext: |- password required pam_pwquality.so -vuln_discussion: |- - Enabling PAM password complexity permits enforcement of strong passwords and consequently makes the system less prone to dictionary attacks. diff --git a/linux_os/guide/system/accounts/accounts-pam/set_password_hashing_algorithm/set_password_hashing_algorithm_libuserconf/policy/stig/shared.yml b/linux_os/guide/system/accounts/accounts-pam/set_password_hashing_algorithm/set_password_hashing_algorithm_libuserconf/policy/stig/shared.yml index 7d707984efb0..b0f5e7dfa2cc 100644 --- a/linux_os/guide/system/accounts/accounts-pam/set_password_hashing_algorithm/set_password_hashing_algorithm_libuserconf/policy/stig/shared.yml +++ b/linux_os/guide/system/accounts/accounts-pam/set_password_hashing_algorithm/set_password_hashing_algorithm_libuserconf/policy/stig/shared.yml @@ -2,19 +2,9 @@ srg_requirement: |- {{{ full_name }}} must be configured so that user and group account administration utilities are configured to store only encrypted representations of passwords. vuldiscussion: |- - Passwords need to be protected at all times, and encryption is the standard - method for protecting passwords. If passwords are not encrypted, they can - be plainly read (i.e., clear text) and easily compromised. Passwords that - are encrypted with a weak algorithm are no more protected than if they are - kepy in plain text. - - + Passwords need to be protected at all times, and encryption is the standard method for protecting passwords. If passwords are not encrypted, they can be plainly read (i.e., clear text) and easily compromised. Passwords that are encrypted with a weak algorithm are no more protected than if they are kept in plain text. - This setting ensures user and group account administration utilities are - configured to store only encrypted representations of passwords. - Additionally, the "crypt_style" configuration option ensures the use - of a strong hashing algorithm that makes password cracking attacks more - difficult. + This setting ensures user and group account administration utilities are configured to store only encrypted representations of passwords. Additionally, the "crypt_style" configuration option ensures the use of a strong hashing algorithm that makes password cracking attacks more difficult. checktext: |- Verify the user and group account administration utilities are configured to store only encrypted representations of passwords with the following command: @@ -32,7 +22,3 @@ fixtext: |- crypt_style = sha512 -vuln_discussion: |- - Passwords need to be protected at all times, and encryption is the standard method for protecting passwords. If passwords are not encrypted, they can be plainly read (i.e., clear text) and easily compromised. Passwords that are encrypted with a weak algorithm are no more protected than if they are kept in plain text. - - This setting ensures user and group account administration utilities are configured to store only encrypted representations of passwords. Additionally, the "crypt_style" configuration option ensures the use of a strong hashing algorithm that makes password cracking attacks more difficult. diff --git a/linux_os/guide/system/accounts/accounts-pam/set_password_hashing_algorithm/set_password_hashing_algorithm_passwordauth/policy/stig/shared.yml b/linux_os/guide/system/accounts/accounts-pam/set_password_hashing_algorithm/set_password_hashing_algorithm_passwordauth/policy/stig/shared.yml index 5f164adbd577..40653fc494b7 100644 --- a/linux_os/guide/system/accounts/accounts-pam/set_password_hashing_algorithm/set_password_hashing_algorithm_passwordauth/policy/stig/shared.yml +++ b/linux_os/guide/system/accounts/accounts-pam/set_password_hashing_algorithm/set_password_hashing_algorithm_passwordauth/policy/stig/shared.yml @@ -17,9 +17,3 @@ checktext: |- If "sha512" is missing, or the line is commented out, this is a finding. -vuln_discussion: |- - 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. - - {{{ full_name }}} systems utilizing encryption are required to use FIPS-compliant mechanisms for authenticating to cryptographic modules. - - FIPS 140-3 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. diff --git a/linux_os/guide/system/accounts/accounts-pam/set_password_hashing_algorithm/set_password_hashing_min_rounds_logindefs/policy/stig/shared.yml b/linux_os/guide/system/accounts/accounts-pam/set_password_hashing_algorithm/set_password_hashing_min_rounds_logindefs/policy/stig/shared.yml index 56183f162fc7..402d49859023 100644 --- a/linux_os/guide/system/accounts/accounts-pam/set_password_hashing_algorithm/set_password_hashing_min_rounds_logindefs/policy/stig/shared.yml +++ b/linux_os/guide/system/accounts/accounts-pam/set_password_hashing_algorithm/set_password_hashing_min_rounds_logindefs/policy/stig/shared.yml @@ -2,13 +2,7 @@ srg_requirement: |- {{{ full_name }}} shadow password suite must be configured to use a sufficient number of hashing rounds. vuldiscussion: |- - Passwords need to be protected at all times, and encryption is the standard - method for protecting passwords. If passwords are not encrypted, they can - be plainly read (i.e., clear text) and easily compromised. Passwords - that are encrypted with a weak algorithm are no more protected than if - they are kept in plain text. - - + Passwords need to be protected at all times, and encryption is the standard method for protecting passwords. If passwords are not encrypted, they can be plainly read (i.e., clear text) and easily compromised. Passwords that are encrypted with a weak algorithm are no more protected than if they are kept in plain text. Using more hashing rounds makes password cracking attacks more difficult. @@ -26,7 +20,3 @@ fixtext: |- SHA_CRYPT_MIN_ROUNDS 5000 -vuln_discussion: |- - Passwords need to be protected at all times, and encryption is the standard method for protecting passwords. If passwords are not encrypted, they can be plainly read (i.e., clear text) and easily compromised. Passwords that are encrypted with a weak algorithm are no more protected than if they are kept in plain text. - - Using more hashing rounds makes password cracking attacks more difficult. diff --git a/linux_os/guide/system/accounts/accounts-physical/disable_ctrlaltdel_burstaction/policy/stig/shared.yml b/linux_os/guide/system/accounts/accounts-physical/disable_ctrlaltdel_burstaction/policy/stig/shared.yml index 90cbe0bd7515..31d43975e5c2 100644 --- a/linux_os/guide/system/accounts/accounts-physical/disable_ctrlaltdel_burstaction/policy/stig/shared.yml +++ b/linux_os/guide/system/accounts/accounts-physical/disable_ctrlaltdel_burstaction/policy/stig/shared.yml @@ -22,5 +22,3 @@ fixtext: |- $ sudo systemctl daemon-reload -vuln_discussion: |- - 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. diff --git a/linux_os/guide/system/accounts/accounts-physical/disable_ctrlaltdel_reboot/policy/stig/shared.yml b/linux_os/guide/system/accounts/accounts-physical/disable_ctrlaltdel_reboot/policy/stig/shared.yml index 27d20dfa3dfd..2da8275a1a81 100644 --- a/linux_os/guide/system/accounts/accounts-physical/disable_ctrlaltdel_reboot/policy/stig/shared.yml +++ b/linux_os/guide/system/accounts/accounts-physical/disable_ctrlaltdel_reboot/policy/stig/shared.yml @@ -21,5 +21,3 @@ fixtext: |- $ sudo systemctl disable --now ctrl-alt-del.target $ sudo systemctl mask --now ctrl-alt-del.target -vuln_discussion: |- - 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. diff --git a/linux_os/guide/system/accounts/accounts-physical/grub2_disable_interactive_boot/policy/stig/shared.yml b/linux_os/guide/system/accounts/accounts-physical/grub2_disable_interactive_boot/policy/stig/shared.yml index 43924209799c..d4a0e3eaccf1 100644 --- a/linux_os/guide/system/accounts/accounts-physical/grub2_disable_interactive_boot/policy/stig/shared.yml +++ b/linux_os/guide/system/accounts/accounts-physical/grub2_disable_interactive_boot/policy/stig/shared.yml @@ -18,5 +18,3 @@ fixtext: |- $ sudo grubby --update-kernel=ALL --remove-args="systemd.confirm_spawn" -vuln_discussion: |- - Using interactive or recovery boot, the console user could disable auditing, firewalls, or other services, weakening system security. diff --git a/linux_os/guide/system/accounts/accounts-physical/require_emergency_target_auth/policy/stig/shared.yml b/linux_os/guide/system/accounts/accounts-physical/require_emergency_target_auth/policy/stig/shared.yml index 46e01b3a807f..50880a4201d4 100644 --- a/linux_os/guide/system/accounts/accounts-physical/require_emergency_target_auth/policy/stig/shared.yml +++ b/linux_os/guide/system/accounts/accounts-physical/require_emergency_target_auth/policy/stig/shared.yml @@ -2,10 +2,9 @@ srg_requirement: |- {{{ full_name }}} must require authentication to access emergency mode. vuldiscussion: |- - 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. + 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. - This requirement prevents attackers with physical access from trivially bypassing security - on the machine and gaining root access. Such accesses are further prevented by configuring the bootloader password. + This requirement prevents attackers with physical access from trivially bypassing security on the machine and gaining root access. Such accesses are further prevented by configuring the bootloader password. checktext: |- Verify that {{{ full_name }}} requires authentication for emergency mode with the following command: @@ -23,7 +22,3 @@ fixtext: |- ExecStart=-/usr/lib/systemd/systemd-sulogin-shell emergency -vuln_discussion: |- - 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. - - This requirement prevents attackers with physical access from trivially bypassing security on the machine and gaining root access. Such accesses are further prevented by configuring the bootloader password. diff --git a/linux_os/guide/system/accounts/accounts-physical/require_singleuser_auth/policy/stig/shared.yml b/linux_os/guide/system/accounts/accounts-physical/require_singleuser_auth/policy/stig/shared.yml index 710d5e947dbc..9ed13f583fda 100644 --- a/linux_os/guide/system/accounts/accounts-physical/require_singleuser_auth/policy/stig/shared.yml +++ b/linux_os/guide/system/accounts/accounts-physical/require_singleuser_auth/policy/stig/shared.yml @@ -2,10 +2,9 @@ srg_requirement: |- {{{ full_name }}} must require authentication to access single-user mode. vuldiscussion: |- - 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. + 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. - This requirement prevents attackers with physical access from trivially bypassing security - on the machine and gaining root access. Such accesses are further prevented by configuring the bootloader password. + This requirement prevents attackers with physical access from trivially bypassing security on the machine and gaining root access. Such accesses are further prevented by configuring the bootloader password. checktext: |- Verify that {{{ full_name }}} requires authentication for single-user mode with the following command: @@ -23,7 +22,3 @@ fixtext: |- ExecStart=-/usr/lib/systemd/systemd-sulogin-shell rescue -vuln_discussion: |- - 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. - - This requirement prevents attackers with physical access from trivially bypassing security on the machine and gaining root access. Such accesses are further prevented by configuring the bootloader password. diff --git a/linux_os/guide/system/accounts/accounts-physical/screen_locking/console_screen_locking/configure_bashrc_tmux/policy/stig/shared.yml b/linux_os/guide/system/accounts/accounts-physical/screen_locking/console_screen_locking/configure_bashrc_tmux/policy/stig/shared.yml index bd3388bdae1f..1e1d0c43972d 100644 --- a/linux_os/guide/system/accounts/accounts-physical/screen_locking/console_screen_locking/configure_bashrc_tmux/policy/stig/shared.yml +++ b/linux_os/guide/system/accounts/accounts-physical/screen_locking/console_screen_locking/configure_bashrc_tmux/policy/stig/shared.yml @@ -37,5 +37,3 @@ checktext: |- If the command does not produce output, this is a finding. -vuln_discussion: |- - Tmux is a terminal multiplexer that enables a number of terminals to be created, accessed, and controlled from a single screen. Red Hat endorses tmux as the recommended session controlling package. diff --git a/linux_os/guide/system/accounts/accounts-physical/screen_locking/console_screen_locking/configure_tmux_lock_after_time/policy/stig/shared.yml b/linux_os/guide/system/accounts/accounts-physical/screen_locking/console_screen_locking/configure_tmux_lock_after_time/policy/stig/shared.yml index b7068e200a8f..bf454b84c2b0 100644 --- a/linux_os/guide/system/accounts/accounts-physical/screen_locking/console_screen_locking/configure_tmux_lock_after_time/policy/stig/shared.yml +++ b/linux_os/guide/system/accounts/accounts-physical/screen_locking/console_screen_locking/configure_tmux_lock_after_time/policy/stig/shared.yml @@ -2,11 +2,7 @@ srg_requirement: |- {{{ full_name }}} must automatically lock command line user sessions after 15 minutes of inactivity. vuldiscussion: |- - A session time-out lock is a temporary action taken when a user stops work and moves away from - the immediate physical vicinity of the information system but does not logout because of the - temporary nature of the absence. Rather than relying on the user to manually lock their operating - system session prior to vacating the vicinity, tmux can be configured to identify when - a user's session has idled and take action to initiate a session lock. + A session time-out lock is a temporary action taken when a user stops work and moves away from the immediate physical vicinity of the information system but does not logout because of the temporary nature of the absence. Rather than relying on the user to manually lock their operating system session prior to vacating the vicinity, tmux can be configured to identify when a user's session has idled and take action to initiate a session lock. checktext: |- Verify {{{ full_name }}} initiates a session lock after 15 minutes of inactivity. @@ -24,5 +20,3 @@ fixtext: |- set -g lock-after-time 900 -vuln_discussion: |- - A session time-out lock is a temporary action taken when a user stops work and moves away from the immediate physical vicinity of the information system but does not logout because of the temporary nature of the absence. Rather than relying on the user to manually lock their operating system session prior to vacating the vicinity, tmux can be configured to identify when a user's session has idled and take action to initiate a session lock. diff --git a/linux_os/guide/system/accounts/accounts-physical/screen_locking/console_screen_locking/no_tmux_in_shells/policy/stig/shared.yml b/linux_os/guide/system/accounts/accounts-physical/screen_locking/console_screen_locking/no_tmux_in_shells/policy/stig/shared.yml index e13d6994e33d..8ca9348dce77 100644 --- a/linux_os/guide/system/accounts/accounts-physical/screen_locking/console_screen_locking/no_tmux_in_shells/policy/stig/shared.yml +++ b/linux_os/guide/system/accounts/accounts-physical/screen_locking/console_screen_locking/no_tmux_in_shells/policy/stig/shared.yml @@ -2,9 +2,7 @@ srg_requirement: |- {{{ full_name }}} must prevent users from disabling session control mechanisms. vuldiscussion: |- - The session lock is implemented at the point where session activity can be determined. Rather than be forced to wait for a period of time to expire before the user session can be locked, {{{ full_name }}} needs to provide users with the ability to manually invoke a session lock so users can secure their session if it is necessary to temporarily vacate the immediate physical vicinity. - - Tmux is a terminal multiplexer that enables a number of terminals to be created, accessed, and controlled from a single screen. Red Hat endorses tmux as the recommended session controlling package. + The session lock is implemented at the point where session activity can be determined. Rather than be forced to wait for a period of time to expire before the user session can be locked, {{{ full_name }}} must provide users with the ability to manually invoke a session lock so users can secure their session if it is necessary to temporarily vacate the immediate physical vicinity. checktext: |- Verify {{{ full_name }}} prevents users from disabling the tmux terminal multiplexer with the following command: @@ -16,5 +14,3 @@ checktext: |- fixtext: |- Configure {{{ full_name }}} to prevent users from disabling the tmux terminal multiplexer by editing the "/etc/shells" configuration file to remove any instances of tmux. -vuln_discussion: |- - The session lock is implemented at the point where session activity can be determined. Rather than be forced to wait for a period of time to expire before the user session can be locked, {{{ full_name }}} must provide users with the ability to manually invoke a session lock so users can secure their session if it is necessary to temporarily vacate the immediate physical vicinity. diff --git a/linux_os/guide/system/accounts/accounts-physical/screen_locking/console_screen_locking/package_tmux_installed/policy/stig/shared.yml b/linux_os/guide/system/accounts/accounts-physical/screen_locking/console_screen_locking/package_tmux_installed/policy/stig/shared.yml index 4856bf36b4d5..066785e84dfa 100644 --- a/linux_os/guide/system/accounts/accounts-physical/screen_locking/console_screen_locking/package_tmux_installed/policy/stig/shared.yml +++ b/linux_os/guide/system/accounts/accounts-physical/screen_locking/console_screen_locking/package_tmux_installed/policy/stig/shared.yml @@ -2,11 +2,7 @@ srg_requirement: |- {{{ full_name }}} must have the tmux package installed. vuldiscussion: |- - A session lock is a temporary action taken when a user stops work and moves away from the immediate physical vicinity of the information system but does not want to log out because of the temporary nature of the absence. - The session lock is implemented at the point where session activity can be determined. Rather than be forced to wait for a period of time to expire before the user session can be locked, {{{ full_name }}} needs to provide users with the ability to manually invoke a session lock so users can secure their session if it is necessary to temporarily vacate the immediate physical vicinity. - Tmux is a terminal multiplexer that enables a number of terminals to be created, accessed, and controlled from a single screen. Red Hat endorses tmux as the recommended session controlling package. - - The "tmux" package allows for a session lock to be implemented and configured. + Tmux is a terminal multiplexer that enables a number of terminals to be created, accessed, and controlled from a single screen. Red Hat endorses tmux as the recommended session controlling package. checktext: |- Verify that {{{ full_name }}} has the tmux package installed with the following command: @@ -24,5 +20,3 @@ fixtext: |- $ sudo dnf install tmux -vuln_discussion: |- - Tmux is a terminal multiplexer that enables a number of terminals to be created, accessed, and controlled from a single screen. Red Hat endorses tmux as the recommended session controlling package. diff --git a/linux_os/guide/system/accounts/accounts-physical/screen_locking/smart_card_login/install_smartcard_packages/policy/stig/shared.yml b/linux_os/guide/system/accounts/accounts-physical/screen_locking/smart_card_login/install_smartcard_packages/policy/stig/shared.yml index 2f5bf7c47f91..24bb4f228bd9 100644 --- a/linux_os/guide/system/accounts/accounts-physical/screen_locking/smart_card_login/install_smartcard_packages/policy/stig/shared.yml +++ b/linux_os/guide/system/accounts/accounts-physical/screen_locking/smart_card_login/install_smartcard_packages/policy/stig/shared.yml @@ -2,13 +2,7 @@ srg_requirement: |- {{{ full_name }}} must have the openssl-pkcs11 package installed. vuldiscussion: |- - Without the use of multifactor authentication, the ease of access to - privileged functions is greatly increased. Multifactor authentication - requires using two or more factors to achieve authentication. - A privileged account is defined as an information system account with - authorizations of a privileged user. - The DoD CAC with DoD-approved PKI is an example of multifactor - authentication. + Without the use of multifactor authentication, the ease of access to privileged functions is greatly increased. Multifactor authentication requires using two or more factors to achieve authentication. A privileged account is defined as an information system account with authorizations of a privileged user. The DOD CAC with DOD-approved PKI is an example of multifactor authentication. checktext: |- Verify that {{{ full_name }}} has the openssl-pkcs11 package installed with the following command: @@ -27,5 +21,3 @@ fixtext: |- $ sudo dnf install openssl-pkcs11 -vuln_discussion: |- - Without the use of multifactor authentication, the ease of access to privileged functions is greatly increased. Multifactor authentication requires using two or more factors to achieve authentication. A privileged account is defined as an information system account with authorizations of a privileged user. The DOD CAC with DOD-approved PKI is an example of multifactor authentication. diff --git a/linux_os/guide/system/accounts/accounts-physical/screen_locking/smart_card_login/package_opensc_installed/policy/stig/shared.yml b/linux_os/guide/system/accounts/accounts-physical/screen_locking/smart_card_login/package_opensc_installed/policy/stig/shared.yml index 3ed3c934e274..016226919911 100644 --- a/linux_os/guide/system/accounts/accounts-physical/screen_locking/smart_card_login/package_opensc_installed/policy/stig/shared.yml +++ b/linux_os/guide/system/accounts/accounts-physical/screen_locking/smart_card_login/package_opensc_installed/policy/stig/shared.yml @@ -4,7 +4,7 @@ srg_requirement: |- vuldiscussion: |- The use of PIV credentials facilitates standardization and reduces the risk of unauthorized access. - The DoD has mandated the use of the Common Access Card (CAC) to support identity management and personal authentication for systems covered under Homeland Security Presidential Directive (HSPD) 12, as well as making the CAC a primary component of layered protection for national security systems. + The DOD has mandated the use of the Common Access Card (CAC) to support identity management and personal authentication for systems covered under Homeland Security Presidential Directive (HSPD) 12, as well as making the CAC a primary component of layered protection for national security systems. checktext: |- Verify that {{{ full_name }}} has the opensc package installed with the following command: @@ -22,7 +22,3 @@ fixtext: |- $ sudo dnf install opensc -vuln_discussion: |- - The use of PIV credentials facilitates standardization and reduces the risk of unauthorized access. - - The DOD has mandated the use of the Common Access Card (CAC) to support identity management and personal authentication for systems covered under Homeland Security Presidential Directive (HSPD) 12, as well as making the CAC a primary component of layered protection for national security systems. diff --git a/linux_os/guide/system/accounts/accounts-physical/screen_locking/smart_card_login/package_pcsc-lite_installed/policy/stig/shared.yml b/linux_os/guide/system/accounts/accounts-physical/screen_locking/smart_card_login/package_pcsc-lite_installed/policy/stig/shared.yml index 61cd108ffd8d..d570e404ce0e 100644 --- a/linux_os/guide/system/accounts/accounts-physical/screen_locking/smart_card_login/package_pcsc-lite_installed/policy/stig/shared.yml +++ b/linux_os/guide/system/accounts/accounts-physical/screen_locking/smart_card_login/package_pcsc-lite_installed/policy/stig/shared.yml @@ -2,8 +2,7 @@ srg_requirement: |- {{{ full_name }}} must have the pcsc-lite package installed. vuldiscussion: |- - The pcsc-lite package must be installed if it is to be available for - multifactor authentication using smartcards. + The pcsc-lite package must be installed if it is to be available for multifactor authentication using smart cards. checktext: |- Verify that {{{ full_name }}} has the pcsc-lite package installed with the following command: @@ -21,5 +20,3 @@ fixtext: |- $ sudo dnf install pcsc-lite -vuln_discussion: |- - The pcsc-lite package must be installed if it is to be available for multifactor authentication using smart cards. diff --git a/linux_os/guide/system/accounts/accounts-physical/screen_locking/smart_card_login/service_pcscd_enabled/policy/stig/shared.yml b/linux_os/guide/system/accounts/accounts-physical/screen_locking/smart_card_login/service_pcscd_enabled/policy/stig/shared.yml index d54541213d9d..1a4ab804cc10 100644 --- a/linux_os/guide/system/accounts/accounts-physical/screen_locking/smart_card_login/service_pcscd_enabled/policy/stig/shared.yml +++ b/linux_os/guide/system/accounts/accounts-physical/screen_locking/smart_card_login/service_pcscd_enabled/policy/stig/shared.yml @@ -2,11 +2,9 @@ srg_requirement: |- The pcscd service on {{{ full_name }}} must be active. vuldiscussion: |- - the information system, ensures that even if the information system is - compromised, that compromise will not affect credentials stored on the - authentication device. + The information system ensures that even if the information system is compromised, that compromise will not affect credentials stored on the authentication device. - pcscd is the daemon program for pcsc-lite and the MuscleCard framework. It is a resource manager that coordinates communications with smart card readers and smart cards and cryptographic tokens that are connected to the system. + The daemon program for pcsc-lite and the MuscleCard framework is pcscd. It is a resource manager that coordinates communications with smart card readers and smart cards and cryptographic tokens that are connected to the system. checktext: |- Verify that the "pcscd" service is active with the following command: @@ -22,7 +20,3 @@ fixtext: |- $ sudo systemctl enable --now pcscd -vuln_discussion: |- - The information system ensures that even if the information system is compromised, that compromise will not affect credentials stored on the authentication device. - - The daemon program for pcsc-lite and the MuscleCard framework is pcscd. It is a resource manager that coordinates communications with smart card readers and smart cards and cryptographic tokens that are connected to the system. diff --git a/linux_os/guide/system/accounts/accounts-physical/service_debug-shell_disabled/policy/stig/shared.yml b/linux_os/guide/system/accounts/accounts-physical/service_debug-shell_disabled/policy/stig/shared.yml index 007cbcab7c9b..8d516ba231d4 100644 --- a/linux_os/guide/system/accounts/accounts-physical/service_debug-shell_disabled/policy/stig/shared.yml +++ b/linux_os/guide/system/accounts/accounts-physical/service_debug-shell_disabled/policy/stig/shared.yml @@ -2,7 +2,7 @@ srg_requirement: |- {{{ full_name }}} debug-shell systemd service must be disabled. vuldiscussion: |- - The debug-shell requires no authentication and provides root privileges to anyone who has physical access to the machine. While this feature is disabled by default, masking it adds an additional layer of assurance that it will not be enabled via a dependency in systemd. This also prevents attackers with physical access from trivially bypassing security on the machine through valid troubleshooting configurations and gaining root access when the system is rebooted. + The debug-shell requires no authentication and provides root privileges to anyone who has physical access to the machine. While this feature is disabled by default, masking it adds an additional layer of assurance that it will not be enabled via a dependency in systemd. This also prevents attackers with physical access from trivially bypassing security on the machine through valid troubleshooting configurations and gaining root access when the system is rebooted. checktext: |- Verify {{{ full_name }}} is configured to mask the debug-shell systemd service with the following command: @@ -21,5 +21,3 @@ fixtext: |- $ sudo systemctl disable --now debug-shell.service $ sudo systemctl mask --now debug-shell.service -vuln_discussion: |- - The debug-shell requires no authentication and provides root privileges to anyone who has physical access to the machine. While this feature is disabled by default, masking it adds an additional layer of assurance that it will not be enabled via a dependency in systemd. This also prevents attackers with physical access from trivially bypassing security on the machine through valid troubleshooting configurations and gaining root access when the system is rebooted. diff --git a/linux_os/guide/system/accounts/accounts-restrictions/account_expiration/account_temp_expire_date/policy/stig/shared.yml b/linux_os/guide/system/accounts/accounts-restrictions/account_expiration/account_temp_expire_date/policy/stig/shared.yml index 7faddb387c95..06ee5fbe9010 100644 --- a/linux_os/guide/system/accounts/accounts-restrictions/account_expiration/account_temp_expire_date/policy/stig/shared.yml +++ b/linux_os/guide/system/accounts/accounts-restrictions/account_expiration/account_temp_expire_date/policy/stig/shared.yml @@ -2,10 +2,11 @@ srg_requirement: |- {{{ full_name }}} must automatically expire temporary accounts within 72 hours. vuldiscussion: |- - If temporary user accounts remain active when no longer needed or for - an excessive period, these accounts may be used to gain unauthorized access. - To mitigate this risk, automated termination of all temporary accounts must be - set upon account creation. + Temporary accounts are privileged or nonprivileged accounts that are established during pressing circumstances, such as new software or hardware configuration or an incident response, where the need for prompt account activation requires bypassing normal account authorization procedures. If any inactive temporary accounts are left enabled on the system and are not either manually removed or automatically expired within 72 hours, the security posture of the system will be degraded and exposed to exploitation by unauthorized users or insider threat actors. + + Temporary accounts are different from emergency accounts. Emergency accounts, also known as "last resort" or "break glass" accounts, are local logon accounts enabled on the system for emergency use by authorized system administrators to manage a system when standard logon methods are failing or not available. Emergency accounts are not subject to manual removal or scheduled expiration requirements. + + The automatic expiration of temporary accounts may be extended as needed by the circumstances but it must not be extended indefinitely. A documented permanent account should be established for privileged users who need long-term maintenance accounts. checktext: |- Verify temporary accounts have been provisioned with an expiration date of 72 hours. @@ -23,9 +24,3 @@ fixtext: |- $ sudo chage -E $(date -d +3days +%Y-%m-%d) <temporary_account_name> -vuln_discussion: |- - Temporary accounts are privileged or nonprivileged accounts that are established during pressing circumstances, such as new software or hardware configuration or an incident response, where the need for prompt account activation requires bypassing normal account authorization procedures. If any inactive temporary accounts are left enabled on the system and are not either manually removed or automatically expired within 72 hours, the security posture of the system will be degraded and exposed to exploitation by unauthorized users or insider threat actors. - - Temporary accounts are different from emergency accounts. Emergency accounts, also known as "last resort" or "break glass" accounts, are local logon accounts enabled on the system for emergency use by authorized system administrators to manage a system when standard logon methods are failing or not available. Emergency accounts are not subject to manual removal or scheduled expiration requirements. - - The automatic expiration of temporary accounts may be extended as needed by the circumstances but it must not be extended indefinitely. A documented permanent account should be established for privileged users who need long-term maintenance accounts. diff --git a/linux_os/guide/system/accounts/accounts-restrictions/account_unique_id/policy/stig/shared.yml b/linux_os/guide/system/accounts/accounts-restrictions/account_unique_id/policy/stig/shared.yml index fb3d35e8da38..1ebac5fec172 100644 --- a/linux_os/guide/system/accounts/accounts-restrictions/account_unique_id/policy/stig/shared.yml +++ b/linux_os/guide/system/accounts/accounts-restrictions/account_unique_id/policy/stig/shared.yml @@ -2,7 +2,7 @@ srg_requirement: |- {{{ full_name }}} duplicate User IDs (UIDs) must not exist for interactive users. vuldiscussion: |- - To assure accountability and prevent unauthenticated access, interactive users must be identified and authenticated to prevent potential misuse and compromise of the system. + To ensure accountability and prevent unauthenticated access, interactive users must be identified and authenticated to prevent potential misuse and compromise of the system. checktext: |- Verify that {{{ full_name }}} contains no duplicate UIDs for interactive users with the following command: @@ -14,5 +14,3 @@ checktext: |- fixtext: |- Edit the file "/etc/passwd" and provide each interactive user account that has a duplicate UID with a unique UID. -vuln_discussion: |- - To ensure accountability and prevent unauthenticated access, interactive users must be identified and authenticated to prevent potential misuse and compromise of the system. diff --git a/linux_os/guide/system/accounts/accounts-restrictions/group_unique_id/policy/stig/shared.yml b/linux_os/guide/system/accounts/accounts-restrictions/group_unique_id/policy/stig/shared.yml index 1f251549eb41..3b64b6c3a7eb 100644 --- a/linux_os/guide/system/accounts/accounts-restrictions/group_unique_id/policy/stig/shared.yml +++ b/linux_os/guide/system/accounts/accounts-restrictions/group_unique_id/policy/stig/shared.yml @@ -2,7 +2,7 @@ srg_requirement: |- {{{ full_name }}} groups must have unique Group ID (GID). vuldiscussion: |- - To assure accountability and prevent unauthenticated access, groups must be identified uniquely to prevent potential misuse and compromise of the system. + To ensure accountability and prevent unauthenticated access, groups must be identified uniquely to prevent potential misuse and compromise of the system. checktext: |- Verify that {{{ full_name }}} contains no duplicate GIDs for interactive users with the following command: @@ -14,5 +14,3 @@ checktext: |- fixtext: |- Edit the file "/etc/group" and provide each group that has a duplicate GID with a unique GID. -vuln_discussion: |- - To ensure accountability and prevent unauthenticated access, groups must be identified uniquely to prevent potential misuse and compromise of the system. diff --git a/linux_os/guide/system/accounts/accounts-restrictions/password_expiration/accounts_maximum_age_login_defs/policy/stig/shared.yml b/linux_os/guide/system/accounts/accounts-restrictions/password_expiration/accounts_maximum_age_login_defs/policy/stig/shared.yml index 141e77f0fba6..dc9ef7379b91 100644 --- a/linux_os/guide/system/accounts/accounts-restrictions/password_expiration/accounts_maximum_age_login_defs/policy/stig/shared.yml +++ b/linux_os/guide/system/accounts/accounts-restrictions/password_expiration/accounts_maximum_age_login_defs/policy/stig/shared.yml @@ -2,17 +2,9 @@ srg_requirement: |- {{{ full_name }}} user account passwords for new users or password changes must have a 60-day maximum password lifetime restriction in /etc/login.defs. vuldiscussion: |- - 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. - - + Any password, no matter how complex, can eventually be cracked; therefore, passwords need to be changed periodically. If the operating system does not limit the lifetime of passwords and force users to change their passwords, there is the risk that the operating system passwords could be compromised. - Setting the password maximum age ensures users are required to - periodically change their passwords. Requiring shorter password lifetimes - increases the risk of users writing down the password in a convenient - location subject to physical compromise. + Setting the password maximum age ensures users are required to periodically change their passwords. Requiring shorter password lifetimes increases the risk of users writing down the password in a convenient location subject to physical compromise. checktext: |- Verify that {{{ full_name }}} enforces a 60-day maximum password lifetime for new user accounts by running the following command: @@ -30,7 +22,3 @@ fixtext: |- PASS_MAX_DAYS 60 -vuln_discussion: |- - Any password, no matter how complex, can eventually be cracked; therefore, passwords need to be changed periodically. If the operating system does not limit the lifetime of passwords and force users to change their passwords, there is the risk that the operating system passwords could be compromised. - - Setting the password maximum age ensures users are required to periodically change their passwords. Requiring shorter password lifetimes increases the risk of users writing down the password in a convenient location subject to physical compromise. diff --git a/linux_os/guide/system/accounts/accounts-restrictions/password_expiration/accounts_minimum_age_login_defs/policy/stig/shared.yml b/linux_os/guide/system/accounts/accounts-restrictions/password_expiration/accounts_minimum_age_login_defs/policy/stig/shared.yml index 7b4fb65cd22b..1144e86dea8e 100644 --- a/linux_os/guide/system/accounts/accounts-restrictions/password_expiration/accounts_minimum_age_login_defs/policy/stig/shared.yml +++ b/linux_os/guide/system/accounts/accounts-restrictions/password_expiration/accounts_minimum_age_login_defs/policy/stig/shared.yml @@ -2,14 +2,9 @@ srg_requirement: |- {{{ full_name }}} passwords for new users or password changes must have a 24 hours minimum password lifetime restriction in /etc/login.defs. vuldiscussion: |- - 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. + Enforcing a minimum password lifetime helps to prevent repeated password changes to defeat the password reuse or history enforcement requirement. If users are allowed to immediately and continually change their password, then the password could be repeatedly changed in a short period of time to defeat the organization's policy regarding password reuse. - Setting the minimum password age protects against users cycling back to a - favorite password after satisfying the password reuse requirement. + Setting the minimum password age protects against users cycling back to a favorite password after satisfying the password reuse requirement. checktext: |- Verify {{{ full_name }}} enforces 24 hours as the minimum password lifetime for new user accounts. @@ -29,7 +24,3 @@ fixtext: |- PASS_MIN_DAYS 1 -vuln_discussion: |- - Enforcing a minimum password lifetime helps to prevent repeated password changes to defeat the password reuse or history enforcement requirement. If users are allowed to immediately and continually change their password, then the password could be repeatedly changed in a short period of time to defeat the organization's policy regarding password reuse. - - Setting the minimum password age protects against users cycling back to a favorite password after satisfying the password reuse requirement. diff --git a/linux_os/guide/system/accounts/accounts-restrictions/password_expiration/accounts_password_minlen_login_defs/policy/stig/shared.yml b/linux_os/guide/system/accounts/accounts-restrictions/password_expiration/accounts_password_minlen_login_defs/policy/stig/shared.yml index 20a9b343ed7f..2e3cfc33f509 100644 --- a/linux_os/guide/system/accounts/accounts-restrictions/password_expiration/accounts_password_minlen_login_defs/policy/stig/shared.yml +++ b/linux_os/guide/system/accounts/accounts-restrictions/password_expiration/accounts_password_minlen_login_defs/policy/stig/shared.yml @@ -17,9 +17,3 @@ checktext: |- If the command does not return a "PASS_MIN_LEN" value of "15" or greater, does not return a line, or the line is commented out, this is a finding. -vuln_discussion: |- - 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 increase exponentially the time and/or resources required to compromise the password. - - The DOD minimum password requirement is 15 characters. diff --git a/linux_os/guide/system/accounts/accounts-restrictions/password_storage/accounts_password_all_shadowed_sha512/policy/stig/shared.yml b/linux_os/guide/system/accounts/accounts-restrictions/password_storage/accounts_password_all_shadowed_sha512/policy/stig/shared.yml index 24ab2f451d8e..2d60f074bce4 100644 --- a/linux_os/guide/system/accounts/accounts-restrictions/password_storage/accounts_password_all_shadowed_sha512/policy/stig/shared.yml +++ b/linux_os/guide/system/accounts/accounts-restrictions/password_storage/accounts_password_all_shadowed_sha512/policy/stig/shared.yml @@ -20,7 +20,3 @@ checktext: |- fixtext: |- Lock all interactive user accounts not using SHA-512 hashing until the passwords can be regenerated with SHA-512. -vuln_discussion: |- - The system must use a strong hashing algorithm to store the password. - - 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. diff --git a/linux_os/guide/system/accounts/accounts-restrictions/password_storage/accounts_password_pam_unix_rounds_system_auth/policy/stig/shared.yml b/linux_os/guide/system/accounts/accounts-restrictions/password_storage/accounts_password_pam_unix_rounds_system_auth/policy/stig/shared.yml index e8e9d00ecfba..dd022571b518 100644 --- a/linux_os/guide/system/accounts/accounts-restrictions/password_storage/accounts_password_pam_unix_rounds_system_auth/policy/stig/shared.yml +++ b/linux_os/guide/system/accounts/accounts-restrictions/password_storage/accounts_password_pam_unix_rounds_system_auth/policy/stig/shared.yml @@ -2,16 +2,12 @@ srg_requirement: |- {{{ full_name }}} system-auth must be configured to use a sufficient number of hashing rounds. vuldiscussion: |- - Passwords need to be protected at all times, and encryption is the standard - method for protecting passwords. If passwords are not encrypted, they can - be plainly read (i.e., clear text) and easily compromised. Passwords - that are encrypted with a weak algorithm are no more protected than if - they are kept in plain text. + Passwords need to be protected at all times, and encryption is the standard method for protecting passwords. If passwords are not encrypted, they can be plainly read (i.e., clear text) and easily compromised. Passwords that are encrypted with a weak algorithm are no more protected than if they are kept in plain text. Using more hashing rounds makes password cracking attacks more difficult. fixtext: |- - Configure Red Hat Enterprise Linux 9 to use 5000 hashing rounds for hashing passwords. + Configure {{{ full_name }}} to use 5000 hashing rounds for hashing passwords. Add or modify the following line in "/etc/pam.d/system-auth" and set "rounds" to 5000. @@ -26,7 +22,3 @@ checktext: |- If a matching line is not returned or "rounds" is less than 5000, this a finding. -vuln_discussion: |- - Passwords need to be protected at all times, and encryption is the standard method for protecting passwords. If passwords are not encrypted, they can be plainly read (i.e., clear text) and easily compromised. Passwords that are encrypted with a weak algorithm are no more protected than if they are kept in plain text. - - Using more hashing rounds makes password cracking attacks more difficult. diff --git a/linux_os/guide/system/accounts/accounts-restrictions/password_storage/gid_passwd_group_same/policy/stig/shared.yml b/linux_os/guide/system/accounts/accounts-restrictions/password_storage/gid_passwd_group_same/policy/stig/shared.yml index 7f49e08e6589..495819948568 100644 --- a/linux_os/guide/system/accounts/accounts-restrictions/password_storage/gid_passwd_group_same/policy/stig/shared.yml +++ b/linux_os/guide/system/accounts/accounts-restrictions/password_storage/gid_passwd_group_same/policy/stig/shared.yml @@ -2,9 +2,7 @@ srg_requirement: |- All {{{ full_name }}} interactive users must have a primary group that exists. vuldiscussion: |- - If a user is assigned the Group Identifier (GID) of a group that does not exist on the system, and a group - with the Group Identifier (GID) is subsequently created, the user may have unintended rights to - any files associated with the group. + If a user is assigned the Group Identifier (GID) of a group that does not exist on the system, and a group with the GID is subsequently created, the user may have unintended rights to any files associated with the group. checktext: |- Verify that all {{{ full_name }}} interactive users have a valid GID. @@ -20,5 +18,3 @@ fixtext: |- Edit the file "/etc/passwd" and ensure that every user's GID is a valid GID. -vuln_discussion: |- - If a user is assigned the Group Identifier (GID) of a group that does not exist on the system, and a group with the GID is subsequently created, the user may have unintended rights to any files associated with the group. diff --git a/linux_os/guide/system/accounts/accounts-restrictions/password_storage/no_empty_passwords/policy/stig/shared.yml b/linux_os/guide/system/accounts/accounts-restrictions/password_storage/no_empty_passwords/policy/stig/shared.yml index 4d10658576f0..65c4953fe923 100644 --- a/linux_os/guide/system/accounts/accounts-restrictions/password_storage/no_empty_passwords/policy/stig/shared.yml +++ b/linux_os/guide/system/accounts/accounts-restrictions/password_storage/no_empty_passwords/policy/stig/shared.yml @@ -2,9 +2,7 @@ srg_requirement: |- {{{ full_name }}} must not allow blank or null passwords. vuldiscussion: |- - If an account has an empty password, anyone could log in and - run commands with the privileges of that account. Accounts with - empty passwords should never be used in operational environments. + If an account has an empty password, anyone could log in and run commands with the privileges of that account. Accounts with empty passwords should never be used in operational environments. checktext: |- Verify that null passwords cannot be used with the following command: @@ -18,5 +16,3 @@ fixtext: |- Note: Manual changes to the listed file may be overwritten by the "authselect" program. -vuln_discussion: |- - If an account has an empty password, anyone could log in and run commands with the privileges of that account. Accounts with empty passwords should never be used in operational environments. diff --git a/linux_os/guide/system/accounts/accounts-restrictions/password_storage/no_empty_passwords_etc_shadow/policy/stig/shared.yml b/linux_os/guide/system/accounts/accounts-restrictions/password_storage/no_empty_passwords_etc_shadow/policy/stig/shared.yml index 93f67d59fde8..0235414bc8da 100644 --- a/linux_os/guide/system/accounts/accounts-restrictions/password_storage/no_empty_passwords_etc_shadow/policy/stig/shared.yml +++ b/linux_os/guide/system/accounts/accounts-restrictions/password_storage/no_empty_passwords_etc_shadow/policy/stig/shared.yml @@ -2,9 +2,7 @@ srg_requirement: |- {{{ full_name }}} must not have accounts configured with blank or null passwords. vuldiscussion: |- - If an account has an empty password, anyone could log in and - run commands with the privileges of that account. Accounts with - empty passwords should never be used in operational environments. + If an account has an empty password, anyone could log in and run commands with the privileges of that account. Accounts with empty passwords should never be used in operational environments. checktext: |- Verify that null or blank passwords cannot be used with the following command: @@ -24,5 +22,3 @@ fixtext: |- $ sudo passwd -l [username] -vuln_discussion: |- - If an account has an empty password, anyone could log in and run commands with the privileges of that account. Accounts with empty passwords should never be used in operational environments. diff --git a/linux_os/guide/system/accounts/accounts-restrictions/root_logins/accounts_no_uid_except_zero/policy/stig/shared.yml b/linux_os/guide/system/accounts/accounts-restrictions/root_logins/accounts_no_uid_except_zero/policy/stig/shared.yml index 1eedec593dd4..c9ccd6fefe26 100644 --- a/linux_os/guide/system/accounts/accounts-restrictions/root_logins/accounts_no_uid_except_zero/policy/stig/shared.yml +++ b/linux_os/guide/system/accounts/accounts-restrictions/root_logins/accounts_no_uid_except_zero/policy/stig/shared.yml @@ -2,11 +2,7 @@ srg_requirement: |- The root account must be the only account having unrestricted access to {{{ full_name }}} system. vuldiscussion: |- - An account has root authority if it has a UID of 0. Multiple accounts - with a UID of 0 afford more opportunity for potential intruders to - guess a password for a privileged account. Proper configuration of - sudo is recommended to afford multiple system administrators - access to root privileges in an accountable manner. + An account has root authority if it has a user identifier (UID) of "0". Multiple accounts with a UID of "0" afford more opportunity for potential intruders to guess a password for a privileged account. Proper configuration of sudo is recommended to afford multiple system administrators access to root privileges in an accountable manner. checktext: |- Verify that only the "root" account has a UID "0" assignment with the following command: @@ -22,5 +18,3 @@ fixtext: |- 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. -vuln_discussion: |- - An account has root authority if it has a user identifier (UID) of "0". Multiple accounts with a UID of "0" afford more opportunity for potential intruders to guess a password for a privileged account. Proper configuration of sudo is recommended to afford multiple system administrators access to root privileges in an accountable manner. diff --git a/linux_os/guide/system/accounts/accounts-restrictions/root_logins/no_shelllogin_for_systemaccounts/policy/stig/shared.yml b/linux_os/guide/system/accounts/accounts-restrictions/root_logins/no_shelllogin_for_systemaccounts/policy/stig/shared.yml index 66c118ce8c48..a9a5275f7dea 100644 --- a/linux_os/guide/system/accounts/accounts-restrictions/root_logins/no_shelllogin_for_systemaccounts/policy/stig/shared.yml +++ b/linux_os/guide/system/accounts/accounts-restrictions/root_logins/no_shelllogin_for_systemaccounts/policy/stig/shared.yml @@ -2,8 +2,7 @@ srg_requirement: |- {{{ full_name }}} system accounts must not have an interactive login shell. vuldiscussion: |- - Ensuring shells are not given to system accounts upon login makes it more - difficult for attackers to make use of system accounts. + Ensuring shells are not given to system accounts upon login makes it more difficult for attackers to make use of system accounts. checktext: |- Verify that system accounts must not have an interactive login shell with the following command: @@ -33,5 +32,3 @@ fixtext: |- Do not perform the steps in this section on the root account. Doing so will cause the system to become inaccessible. -vuln_discussion: |- - Ensuring shells are not given to system accounts upon login makes it more difficult for attackers to make use of system accounts. diff --git a/linux_os/guide/system/accounts/accounts-restrictions/root_logins/use_pam_wheel_for_su/policy/stig/shared.yml b/linux_os/guide/system/accounts/accounts-restrictions/root_logins/use_pam_wheel_for_su/policy/stig/shared.yml index ef91b00711e0..770fed467485 100644 --- a/linux_os/guide/system/accounts/accounts-restrictions/root_logins/use_pam_wheel_for_su/policy/stig/shared.yml +++ b/linux_os/guide/system/accounts/accounts-restrictions/root_logins/use_pam_wheel_for_su/policy/stig/shared.yml @@ -2,9 +2,7 @@ srg_requirement: |- {{{ full_name }}} must restrict the use of the "su" command. vuldiscussion: |- - The "su" program allows to run commands with a substitute user and - group ID. It is commonly used to run commands as the root user. Limiting - access to such command is considered a good security practice. + The "su" program allows to run commands with a substitute user and group ID. It is commonly used to run commands as the root user. Limiting access to such commands is considered a good security practice. checktext: |- Verify that {{{ full_name }}} requires uses to be members of the "wheel" group with the following command: @@ -26,5 +24,3 @@ fixtext: |- If necessary, create a "wheel" group and add administrative users to the group. -vuln_discussion: |- - The "su" program allows to run commands with a substitute user and group ID. It is commonly used to run commands as the root user. Limiting access to such commands is considered a good security practice. diff --git a/linux_os/guide/system/accounts/accounts-session/accounts_have_homedir_login_defs/policy/stig/shared.yml b/linux_os/guide/system/accounts/accounts-session/accounts_have_homedir_login_defs/policy/stig/shared.yml index c38b4e8b7696..20fd1ac2d814 100644 --- a/linux_os/guide/system/accounts/accounts-session/accounts_have_homedir_login_defs/policy/stig/shared.yml +++ b/linux_os/guide/system/accounts/accounts-session/accounts_have_homedir_login_defs/policy/stig/shared.yml @@ -18,5 +18,3 @@ fixtext: |- CREATE_HOME yes -vuln_discussion: |- - 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. diff --git a/linux_os/guide/system/accounts/accounts-session/accounts_tmout/policy/stig/shared.yml b/linux_os/guide/system/accounts/accounts-session/accounts_tmout/policy/stig/shared.yml index 387b57282e5b..453cda84f2de 100644 --- a/linux_os/guide/system/accounts/accounts-session/accounts_tmout/policy/stig/shared.yml +++ b/linux_os/guide/system/accounts/accounts-session/accounts_tmout/policy/stig/shared.yml @@ -2,10 +2,7 @@ srg_requirement: |- {{{ full_name }}} must automatically exit interactive command shell user sessions after 15 minutes of inactivity. vuldiscussion: |- - Terminating an idle session within a short time period reduces - the window of opportunity for unauthorized personnel to take control of a - management session enabled on the console or console port that has been - left unattended. + Terminating an idle interactive command shell user session within a short time period reduces the window of opportunity for unauthorized personnel to take control of it when left unattended in a virtual terminal or physical console. checktext: |- Verify {{{ full_name }}} is configured to exit interactive command shell user sessions after 15 minutes of inactivity or less with the following command: @@ -25,5 +22,3 @@ fixtext: |- declare -xr TMOUT=900 -vuln_discussion: |- - Terminating an idle interactive command shell user session within a short time period reduces the window of opportunity for unauthorized personnel to take control of it when left unattended in a virtual terminal or physical console. diff --git a/linux_os/guide/system/accounts/accounts-session/accounts_user_dot_no_world_writable_programs/policy/stig/shared.yml b/linux_os/guide/system/accounts/accounts-session/accounts_user_dot_no_world_writable_programs/policy/stig/shared.yml index e848a1750550..65a6aef7ec76 100644 --- a/linux_os/guide/system/accounts/accounts-session/accounts_user_dot_no_world_writable_programs/policy/stig/shared.yml +++ b/linux_os/guide/system/accounts/accounts-session/accounts_user_dot_no_world_writable_programs/policy/stig/shared.yml @@ -2,11 +2,7 @@ srg_requirement: |- Local {{{ full_name }}} initialization files must not execute world-writable programs. vuldiscussion: |- - If user start-up files execute world-writable programs, especially in - unprotected directories, they could be maliciously modified to destroy user - files or otherwise compromise the system at the user level. If the system is - compromised at the user level, it is easier to elevate privileges to eventually - compromise the system at the root and network level. + If user start-up files execute world-writable programs, especially in unprotected directories, they could be maliciously modified to destroy user files or otherwise compromise the system at the user level. If the system is compromised at the user level, it is easier to elevate privileges to eventually compromise the system at the root and network level. checktext: |- Verify that local initialization files do not execute world-writable programs with the following command: @@ -22,5 +18,3 @@ fixtext: |- $ sudo chmod 0755 <file> -vuln_discussion: |- - If user start-up files execute world-writable programs, especially in unprotected directories, they could be maliciously modified to destroy user files or otherwise compromise the system at the user level. If the system is compromised at the user level, it is easier to elevate privileges to eventually compromise the system at the root and network level. diff --git a/linux_os/guide/system/accounts/accounts-session/accounts_user_home_paths_only/policy/stig/shared.yml b/linux_os/guide/system/accounts/accounts-session/accounts_user_home_paths_only/policy/stig/shared.yml index a38e0c62fc74..6c48af1ba31d 100644 --- a/linux_os/guide/system/accounts/accounts-session/accounts_user_home_paths_only/policy/stig/shared.yml +++ b/linux_os/guide/system/accounts/accounts-session/accounts_user_home_paths_only/policy/stig/shared.yml @@ -2,15 +2,9 @@ srg_requirement: |- Executable search paths within the initialization files of all local interactive {{{ full_name }}} users must only contain paths that resolve to the system default or the users home directory. vuldiscussion: |- - The executable search path (typically the PATH environment variable) contains a - list of directories for the shell to search to find executables. If this path - includes the current working directory (other than the users home directory), - executables in these directories may be executed instead of system commands. - This variable is formatted as a colon-separated list of directories. If there is - an empty entry, such as a leading or trailing colon or two consecutive colons, - this is interpreted as the current working directory. If deviations from the - default system search path for the local interactive user are required, they - must be documented with the Information System Security Officer (ISSO). + The executable search path (typically the PATH environment variable) contains a list of directories for the shell to search to find executables. If this path includes the current working directory (other than the users home directory), executables in these directories may be executed instead of system commands. + + This variable is formatted as a colon-separated list of directories. If there is an empty entry, such as a leading or trailing colon or two consecutive colons, this is interpreted as the current working directory. If deviations from the default system search path for the local interactive user are required, they must be documented with the information system security officer (ISSO). checktext: |- Verify that all local interactive user initialization file executable search path statements do not contain statements that will reference a working directory other than user home directories with the following commands: @@ -26,7 +20,3 @@ fixtext: |- If a local interactive user requires path variables to reference a directory owned by the application, it must be documented with the ISSO. -vuln_discussion: |- - The executable search path (typically the PATH environment variable) contains a list of directories for the shell to search to find executables. If this path includes the current working directory (other than the users home directory), executables in these directories may be executed instead of system commands. - - This variable is formatted as a colon-separated list of directories. If there is an empty entry, such as a leading or trailing colon or two consecutive colons, this is interpreted as the current working directory. If deviations from the default system search path for the local interactive user are required, they must be documented with the information system security officer (ISSO). diff --git a/linux_os/guide/system/accounts/accounts-session/accounts_user_interactive_home_directory_defined/policy/stig/shared.yml b/linux_os/guide/system/accounts/accounts-session/accounts_user_interactive_home_directory_defined/policy/stig/shared.yml index 9a86967cba92..4ff4d6d1035e 100644 --- a/linux_os/guide/system/accounts/accounts-session/accounts_user_interactive_home_directory_defined/policy/stig/shared.yml +++ b/linux_os/guide/system/accounts/accounts-session/accounts_user_interactive_home_directory_defined/policy/stig/shared.yml @@ -2,8 +2,7 @@ srg_requirement: |- All {{{ full_name }}} local interactive users must have a home directory assigned in the /etc/passwd file. vuldiscussion: |- - 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. + 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. checktext: |- Verify that interactive users on the system have a home directory assigned with the following command: @@ -21,5 +20,3 @@ checktext: |- fixtext: |- Create and assign home directories to all local interactive users on {{{ full_name }}} that currently do not have a home directory assigned. -vuln_discussion: |- - 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. diff --git a/linux_os/guide/system/accounts/accounts-session/accounts_user_interactive_home_directory_exists/policy/stig/shared.yml b/linux_os/guide/system/accounts/accounts-session/accounts_user_interactive_home_directory_exists/policy/stig/shared.yml index 6a9ddf4a2f05..f13ee2b4e87a 100644 --- a/linux_os/guide/system/accounts/accounts-session/accounts_user_interactive_home_directory_exists/policy/stig/shared.yml +++ b/linux_os/guide/system/accounts/accounts-session/accounts_user_interactive_home_directory_exists/policy/stig/shared.yml @@ -2,11 +2,7 @@ srg_requirement: |- All {{{ full_name }}} local interactive user home directories defined in the /etc/passwd file must exist. vuldiscussion: |- - If a local interactive user has a home directory defined that does not exist, - the user may be given access to the / directory as the current working directory - upon logon. This could create a Denial of Service because the user would not be - able to access their logon configuration files, and it may give them visibility - to system files they normally would not be able to access. + If a local interactive user has a home directory defined that does not exist, the user may be given access to the / directory as the current working directory upon logon. This could create a denial of service because the user would not be able to access their logon configuration files, and it may give them visibility to system files they normally would not be able to access. checktext: |- Verify the assigned home directories of all interactive users on the system exist with the following command: @@ -29,5 +25,3 @@ fixtext: |- $ sudo chgrp users /home/wadea $ sudo chmod 0750 /home/wadea -vuln_discussion: |- - If a local interactive user has a home directory defined that does not exist, the user may be given access to the / directory as the current working directory upon logon. This could create a denial of service because the user would not be able to access their logon configuration files, and it may give them visibility to system files they normally would not be able to access. diff --git a/linux_os/guide/system/accounts/accounts-session/file_groupownership_home_directories/policy/stig/shared.yml b/linux_os/guide/system/accounts/accounts-session/file_groupownership_home_directories/policy/stig/shared.yml index 931bd9402f14..0f87ead86fc2 100644 --- a/linux_os/guide/system/accounts/accounts-session/file_groupownership_home_directories/policy/stig/shared.yml +++ b/linux_os/guide/system/accounts/accounts-session/file_groupownership_home_directories/policy/stig/shared.yml @@ -2,10 +2,7 @@ srg_requirement: |- All {{{ full_name }}} local interactive user home directories must be group-owned by the home directory owner's primary group. vuldiscussion: |- - If the Group Identifier (GID) of a local interactive users home directory is - not the same as the primary GID of the user, this would allow unauthorized - access to the users files, and users that share the same group may not be - able to access files that they legitimately should. + If the Group Identifier (GID) of a local interactive users home directory is not the same as the primary GID of the user, this would allow unauthorized access to the users files, and users that share the same group may not be able to access files that they legitimately should. checktext: |- Verify the assigned home directory of all local interactive users is group-owned by that user's primary GID with the following command: @@ -31,5 +28,3 @@ fixtext: |- $ sudo chgrp users /home/wadea -vuln_discussion: |- - If the Group Identifier (GID) of a local interactive users home directory is not the same as the primary GID of the user, this would allow unauthorized access to the users files, and users that share the same group may not be able to access files that they legitimately should. diff --git a/linux_os/guide/system/accounts/accounts-session/file_permission_user_init_files/policy/stig/shared.yml b/linux_os/guide/system/accounts/accounts-session/file_permission_user_init_files/policy/stig/shared.yml index 2455df7766cf..b78101f7acd8 100644 --- a/linux_os/guide/system/accounts/accounts-session/file_permission_user_init_files/policy/stig/shared.yml +++ b/linux_os/guide/system/accounts/accounts-session/file_permission_user_init_files/policy/stig/shared.yml @@ -24,5 +24,3 @@ fixtext: |- $ sudo chmod 0740 /home/wadea/.<INIT_FILE> -vuln_discussion: |- - Local initialization files are used to configure the user's shell environment upon logon. Malicious modification of these files could compromise accounts upon logon. diff --git a/linux_os/guide/system/accounts/accounts-session/file_permission_user_init_files_root/policy/stig/shared.yml b/linux_os/guide/system/accounts/accounts-session/file_permission_user_init_files_root/policy/stig/shared.yml index 2455df7766cf..b78101f7acd8 100644 --- a/linux_os/guide/system/accounts/accounts-session/file_permission_user_init_files_root/policy/stig/shared.yml +++ b/linux_os/guide/system/accounts/accounts-session/file_permission_user_init_files_root/policy/stig/shared.yml @@ -24,5 +24,3 @@ fixtext: |- $ sudo chmod 0740 /home/wadea/.<INIT_FILE> -vuln_discussion: |- - Local initialization files are used to configure the user's shell environment upon logon. Malicious modification of these files could compromise accounts upon logon. diff --git a/linux_os/guide/system/accounts/accounts-session/file_permissions_home_directories/policy/stig/shared.yml b/linux_os/guide/system/accounts/accounts-session/file_permissions_home_directories/policy/stig/shared.yml index 36832a755a40..c18c820ec1a5 100644 --- a/linux_os/guide/system/accounts/accounts-session/file_permissions_home_directories/policy/stig/shared.yml +++ b/linux_os/guide/system/accounts/accounts-session/file_permissions_home_directories/policy/stig/shared.yml @@ -2,8 +2,7 @@ srg_requirement: |- All {{{ full_name }}} local interactive user home directories must have mode 0750 or less permissive. vuldiscussion: |- - Excessive permissions on local interactive user home directories may allow - unauthorized access to user files by other users. + Excessive permissions on local interactive user home directories may allow unauthorized access to user files by other users. checktext: |- Verify the assigned home directory of all local interactive users has a mode of "0750" or less permissive with the following command: @@ -23,5 +22,3 @@ fixtext: |- $ sudo chmod 0750 /home/wadea -vuln_discussion: |- - Excessive permissions on local interactive user home directories may allow unauthorized access to user files by other users. diff --git a/linux_os/guide/system/accounts/accounts-session/user_umask/accounts_umask_etc_bashrc/policy/stig/shared.yml b/linux_os/guide/system/accounts/accounts-session/user_umask/accounts_umask_etc_bashrc/policy/stig/shared.yml index 0e7d7d078929..7e313c22716e 100644 --- a/linux_os/guide/system/accounts/accounts-session/user_umask/accounts_umask_etc_bashrc/policy/stig/shared.yml +++ b/linux_os/guide/system/accounts/accounts-session/user_umask/accounts_umask_etc_bashrc/policy/stig/shared.yml @@ -23,5 +23,3 @@ fixtext: |- umask 077 -vuln_discussion: |- - 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. diff --git a/linux_os/guide/system/accounts/accounts-session/user_umask/accounts_umask_etc_csh_cshrc/policy/stig/shared.yml b/linux_os/guide/system/accounts/accounts-session/user_umask/accounts_umask_etc_csh_cshrc/policy/stig/shared.yml index 7d484307f8ff..4bc1aa46bae2 100644 --- a/linux_os/guide/system/accounts/accounts-session/user_umask/accounts_umask_etc_csh_cshrc/policy/stig/shared.yml +++ b/linux_os/guide/system/accounts/accounts-session/user_umask/accounts_umask_etc_csh_cshrc/policy/stig/shared.yml @@ -23,5 +23,3 @@ fixtext: |- umask 077 -vuln_discussion: |- - 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. diff --git a/linux_os/guide/system/accounts/accounts-session/user_umask/accounts_umask_etc_login_defs/policy/stig/shared.yml b/linux_os/guide/system/accounts/accounts-session/user_umask/accounts_umask_etc_login_defs/policy/stig/shared.yml index 64a0106347dd..a91eb63a4ebd 100644 --- a/linux_os/guide/system/accounts/accounts-session/user_umask/accounts_umask_etc_login_defs/policy/stig/shared.yml +++ b/linux_os/guide/system/accounts/accounts-session/user_umask/accounts_umask_etc_login_defs/policy/stig/shared.yml @@ -22,5 +22,3 @@ fixtext: |- UMASK 077 -vuln_discussion: |- - Setting the most restrictive default permissions ensures that when new accounts are created, they do not have unnecessary access. diff --git a/linux_os/guide/system/accounts/accounts-session/user_umask/accounts_umask_etc_profile/policy/stig/shared.yml b/linux_os/guide/system/accounts/accounts-session/user_umask/accounts_umask_etc_profile/policy/stig/shared.yml index 96527fdb0c31..f8bacb7a4385 100644 --- a/linux_os/guide/system/accounts/accounts-session/user_umask/accounts_umask_etc_profile/policy/stig/shared.yml +++ b/linux_os/guide/system/accounts/accounts-session/user_umask/accounts_umask_etc_profile/policy/stig/shared.yml @@ -22,5 +22,3 @@ fixtext: |- umask 077 -vuln_discussion: |- - 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. diff --git a/linux_os/guide/system/bootloader-grub2/grub2_pti_argument/policy/stig/shared.yml b/linux_os/guide/system/bootloader-grub2/grub2_pti_argument/policy/stig/shared.yml index db38e457d698..76b05b9e1f02 100644 --- a/linux_os/guide/system/bootloader-grub2/grub2_pti_argument/policy/stig/shared.yml +++ b/linux_os/guide/system/bootloader-grub2/grub2_pti_argument/policy/stig/shared.yml @@ -2,10 +2,7 @@ srg_requirement: |- {{{ full_name }}} must enable mitigations against processor-based vulnerabilities. vuldiscussion: |- - Kernel page-table isolation is a kernel feature that mitigates - the Meltdown security vulnerability and hardens the kernel - against attempts to bypass kernel address space layout - randomization (KASLR). + Kernel page-table isolation is a kernel feature that mitigates the Meltdown security vulnerability and hardens the kernel against attempts to bypass kernel address space layout randomization (KASLR). checktext: |- Verify {{{ full_name }}} enables kernel page-table isolation with the following command: @@ -33,5 +30,3 @@ fixtext: |- GRUB_CMDLINE_LINUX="pti=on" -vuln_discussion: |- - Kernel page-table isolation is a kernel feature that mitigates the Meltdown security vulnerability and hardens the kernel against attempts to bypass kernel address space layout randomization (KASLR). diff --git a/linux_os/guide/system/bootloader-grub2/grub2_vsyscall_argument/policy/stig/shared.yml b/linux_os/guide/system/bootloader-grub2/grub2_vsyscall_argument/policy/stig/shared.yml index 5d032a4f3ffa..cdbb998db78a 100644 --- a/linux_os/guide/system/bootloader-grub2/grub2_vsyscall_argument/policy/stig/shared.yml +++ b/linux_os/guide/system/bootloader-grub2/grub2_vsyscall_argument/policy/stig/shared.yml @@ -2,9 +2,9 @@ srg_requirement: |- {{{ full_name }}} must disable virtual system calls. vuldiscussion: |- - Syscalls are special routines in the Linux kernel, which userspace applications ask to do privileged tasks. Invoking a system call is an expensive operation because the processor must interrupt the currently executing task and switch context to kernel mode and then back to userspace after the system call completes. Virtual Syscalls map into user space a page that contains some variables and the implementation of some system calls. This allows the system calls to be executed in userspace to alleviate the context switching expense. + System calls are special routines in the Linux kernel, which userspace applications ask to do privileged tasks. Invoking a system call is an expensive operation because the processor must interrupt the currently executing task and switch context to kernel mode and then back to userspace after the system call completes. Virtual system calls map into user space a page that contains some variables and the implementation of some system calls. This allows the system calls to be executed in userspace to alleviate the context switching expense. - Virtual Syscalls provide an opportunity of attack for a user who has control of the return instruction pointer. Disabling vsyscalls help to prevent return oriented programming (ROP) attacks via buffer overflows and overruns. If the system intends to run containers based on RHEL 6 components, then virtual syscalls will need enabled so the components function properly. + Virtual system calls provide an opportunity of attack for a user who has control of the return instruction pointer. Disabling virtual system calls help to prevent return oriented programming (ROP) attacks via buffer overflows and overruns. If the system intends to run containers based on RHEL 6 components, then virtual system calls will need enabled so the components function properly. checktext: |- Verify the current GRUB 2 configuration disables virtual system calls with the following command: @@ -30,7 +30,3 @@ fixtext: |- GRUB_CMDLINE_LINUX="vsyscall=none" -vuln_discussion: |- - System calls are special routines in the Linux kernel, which userspace applications ask to do privileged tasks. Invoking a system call is an expensive operation because the processor must interrupt the currently executing task and switch context to kernel mode and then back to userspace after the system call completes. Virtual system calls map into user space a page that contains some variables and the implementation of some system calls. This allows the system calls to be executed in userspace to alleviate the context switching expense. - - Virtual system calls provide an opportunity of attack for a user who has control of the return instruction pointer. Disabling virtual system calls help to prevent return oriented programming (ROP) attacks via buffer overflows and overruns. If the system intends to run containers based on RHEL 6 components, then virtual system calls will need enabled so the components function properly. diff --git a/linux_os/guide/system/bootloader-grub2/non-uefi/file_groupowner_grub2_cfg/policy/stig/shared.yml b/linux_os/guide/system/bootloader-grub2/non-uefi/file_groupowner_grub2_cfg/policy/stig/shared.yml index ac524adcd71c..eb6ab7a96851 100644 --- a/linux_os/guide/system/bootloader-grub2/non-uefi/file_groupowner_grub2_cfg/policy/stig/shared.yml +++ b/linux_os/guide/system/bootloader-grub2/non-uefi/file_groupowner_grub2_cfg/policy/stig/shared.yml @@ -2,8 +2,7 @@ srg_requirement: |- {{{ full_name }}} /boot/grub2/grub.cfg file must be group-owned by root. vuldiscussion: |- - The "root" group is a highly-privileged group. Furthermore, the group-owner of this - file should not have any access privileges anyway. + The "root" group is a highly privileged group. Furthermore, the group-owner of this file should not have any access privileges anyway. checktext: |- Verify the group ownership of the "/boot/grub2/grub.cfg" file with the following command: @@ -19,5 +18,3 @@ fixtext: |- $ sudo chgrp root /boot/grub2/grub.cfg -vuln_discussion: |- - The "root" group is a highly privileged group. Furthermore, the group-owner of this file should not have any access privileges anyway. diff --git a/linux_os/guide/system/bootloader-grub2/non-uefi/file_owner_grub2_cfg/policy/stig/shared.yml b/linux_os/guide/system/bootloader-grub2/non-uefi/file_owner_grub2_cfg/policy/stig/shared.yml index 57f486112579..009bbb67b059 100644 --- a/linux_os/guide/system/bootloader-grub2/non-uefi/file_owner_grub2_cfg/policy/stig/shared.yml +++ b/linux_os/guide/system/bootloader-grub2/non-uefi/file_owner_grub2_cfg/policy/stig/shared.yml @@ -15,5 +15,3 @@ checktext: |- If "/boot/grub2/grub.cfg" file does not have an owner of "root", this is a finding. -vuln_discussion: |- - The " /boot/grub2/grub.cfg" file stores sensitive system configuration. Protection of this file is critical for system security. diff --git a/linux_os/guide/system/bootloader-grub2/non-uefi/grub2_admin_username/policy/stig/shared.yml b/linux_os/guide/system/bootloader-grub2/non-uefi/grub2_admin_username/policy/stig/shared.yml index 189528e1b2f4..80a9380a3927 100644 --- a/linux_os/guide/system/bootloader-grub2/non-uefi/grub2_admin_username/policy/stig/shared.yml +++ b/linux_os/guide/system/bootloader-grub2/non-uefi/grub2_admin_username/policy/stig/shared.yml @@ -2,7 +2,7 @@ srg_requirement: |- {{{ full_name }}} must require a unique superusers name upon booting into single-user and maintenance modes. vuldiscussion: |- - Having a non-default grub superuser username makes password-guessing attacks less effective. + Having a nondefault grub superuser username makes password-guessing attacks less effective. checktext: |- Verify the boot loader superuser account has been set with the following command: @@ -28,5 +28,3 @@ fixtext: |- $ sudo grubby --update-kernel=ALL -vuln_discussion: |- - Having a nondefault grub superuser username makes password-guessing attacks less effective. diff --git a/linux_os/guide/system/bootloader-grub2/non-uefi/grub2_password/policy/stig/shared.yml b/linux_os/guide/system/bootloader-grub2/non-uefi/grub2_password/policy/stig/shared.yml index 32aea1a2990f..6ba27d022cea 100644 --- a/linux_os/guide/system/bootloader-grub2/non-uefi/grub2_password/policy/stig/shared.yml +++ b/linux_os/guide/system/bootloader-grub2/non-uefi/grub2_password/policy/stig/shared.yml @@ -2,10 +2,9 @@ srg_requirement: |- {{{ full_name }}} must require a boot loader superuser password. vuldiscussion: |- - 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. + 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. - Password protection on the boot loader configuration ensures users with physical access cannot trivially alter - important bootloader settings. These include which kernel to use, and whether to enter single-user mode. + Password protection on the boot loader configuration ensures users with physical access cannot trivially alter important bootloader settings. These include which kernel to use, and whether to enter single-user mode. checktext: |- Verify the boot loader superuser password has been set and run the following command: @@ -34,7 +33,3 @@ fixtext: |- Enter password: Confirm password: -vuln_discussion: |- - 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. - - Password protection on the boot loader configuration ensures users with physical access cannot trivially alter important bootloader settings. These include which kernel to use, and whether to enter single-user mode. diff --git a/linux_os/guide/system/logging/ensure_rsyslog_log_file_configuration/rsyslog_cron_logging/policy/stig/shared.yml b/linux_os/guide/system/logging/ensure_rsyslog_log_file_configuration/rsyslog_cron_logging/policy/stig/shared.yml index 362ab75fcea6..422ff11b221f 100644 --- a/linux_os/guide/system/logging/ensure_rsyslog_log_file_configuration/rsyslog_cron_logging/policy/stig/shared.yml +++ b/linux_os/guide/system/logging/ensure_rsyslog_log_file_configuration/rsyslog_cron_logging/policy/stig/shared.yml @@ -2,9 +2,7 @@ srg_requirement: |- {{{ full_name }}} must use cron logging. vuldiscussion: |- - Cron logging can be used to trace the successful or unsuccessful execution - of cron jobs. It can also be used to spot intrusions into the use of the cron - facility by unauthorized and malicious users. + Cron logging can be used to trace the successful or unsuccessful execution of cron jobs. It can also be used to spot intrusions into the use of the cron facility by unauthorized and malicious users. checktext: |- Verify that "rsyslog" is configured to log cron events with the following command: @@ -33,5 +31,3 @@ fixtext: |- $ sudo systemctl restart rsyslog.service -vuln_discussion: |- - Cron logging can be used to trace the successful or unsuccessful execution of cron jobs. It can also be used to spot intrusions into the use of the cron facility by unauthorized and malicious users. diff --git a/linux_os/guide/system/logging/ensure_rsyslog_log_file_configuration/rsyslog_encrypt_offload_actionsendstreamdriverauthmode/policy/stig/shared.yml b/linux_os/guide/system/logging/ensure_rsyslog_log_file_configuration/rsyslog_encrypt_offload_actionsendstreamdriverauthmode/policy/stig/shared.yml index b0f064cdce55..045262ef47e3 100644 --- a/linux_os/guide/system/logging/ensure_rsyslog_log_file_configuration/rsyslog_encrypt_offload_actionsendstreamdriverauthmode/policy/stig/shared.yml +++ b/linux_os/guide/system/logging/ensure_rsyslog_log_file_configuration/rsyslog_encrypt_offload_actionsendstreamdriverauthmode/policy/stig/shared.yml @@ -4,9 +4,9 @@ srg_requirement: |- vuldiscussion: |- Information stored in one location is vulnerable to accidental or incidental deletion or alteration. - Off-loading is a common process in information systems with limited audit storage capacity. + Offloading is a common process in information systems with limited audit storage capacity. - {{{ full_name }}} 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 you have a method to securely encrypt and off-load auditing. + {{{ full_name }}} installation media provides "rsyslogd", 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. Coupling this utility with "gnutls" (a secure communications library implementing the SSL, TLS and DTLS protocols) creates a method to securely encrypt and offload auditing. "Rsyslog" supported authentication modes include: anon - anonymous authentication @@ -30,15 +30,3 @@ fixtext: |- $ActionSendStreamDriverAuthMode x509/name -vuln_discussion: |- - 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. - - {{{ full_name }}} installation media provides "rsyslogd", 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. Coupling this utility with "gnutls" (a secure communications library implementing the SSL, TLS and DTLS protocols) creates a method to securely encrypt and offload auditing. - - "Rsyslog" supported authentication modes include: - anon - anonymous authentication - x509/fingerprint - certificate fingerprint authentication - x509/certvalid - certificate validation only - x509/name - certificate validation and subject name authentication diff --git a/linux_os/guide/system/logging/ensure_rsyslog_log_file_configuration/rsyslog_encrypt_offload_actionsendstreamdrivermode/policy/stig/shared.yml b/linux_os/guide/system/logging/ensure_rsyslog_log_file_configuration/rsyslog_encrypt_offload_actionsendstreamdrivermode/policy/stig/shared.yml index e3ef7d8145ad..3fc5d7e1aaf6 100644 --- a/linux_os/guide/system/logging/ensure_rsyslog_log_file_configuration/rsyslog_encrypt_offload_actionsendstreamdrivermode/policy/stig/shared.yml +++ b/linux_os/guide/system/logging/ensure_rsyslog_log_file_configuration/rsyslog_encrypt_offload_actionsendstreamdrivermode/policy/stig/shared.yml @@ -4,9 +4,9 @@ srg_requirement: |- vuldiscussion: |- Information stored in one location is vulnerable to accidental or incidental deletion or alteration. - Off-loading is a common process in information systems with limited audit storage capacity. + Offloading is a common process in information systems with limited audit storage capacity. - {{{ full_name }}} 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 you have a method to securely encrypt and off-load auditing. + {{{ full_name }}} installation media provides "rsyslogd", 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. Coupling this utility with "gnutls" (a secure communications library implementing the SSL, TLS and DTLS protocols) creates a method to securely encrypt and offload auditing. "Rsyslog" supported authentication modes include: anon - anonymous authentication @@ -28,15 +28,3 @@ fixtext: |- $ActionSendStreamDriverMode 1 -vuln_discussion: |- - 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. - - {{{ full_name }}} installation media provides "rsyslogd", 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. Coupling this utility with "gnutls" (a secure communications library implementing the SSL, TLS and DTLS protocols) creates a method to securely encrypt and offload auditing. - - "Rsyslog" supported authentication modes include: - anon - anonymous authentication - x509/fingerprint - certificate fingerprint authentication - x509/certvalid - certificate validation only - x509/name - certificate validation and subject name authentication diff --git a/linux_os/guide/system/logging/ensure_rsyslog_log_file_configuration/rsyslog_encrypt_offload_defaultnetstreamdriver/policy/stig/shared.yml b/linux_os/guide/system/logging/ensure_rsyslog_log_file_configuration/rsyslog_encrypt_offload_defaultnetstreamdriver/policy/stig/shared.yml index a38176883f7f..cd3a9f1c2e8d 100644 --- a/linux_os/guide/system/logging/ensure_rsyslog_log_file_configuration/rsyslog_encrypt_offload_defaultnetstreamdriver/policy/stig/shared.yml +++ b/linux_os/guide/system/logging/ensure_rsyslog_log_file_configuration/rsyslog_encrypt_offload_defaultnetstreamdriver/policy/stig/shared.yml @@ -4,9 +4,9 @@ srg_requirement: |- vuldiscussion: |- Information stored in one location is vulnerable to accidental or incidental deletion or alteration. - Off-loading is a common process in information systems with limited audit storage capacity. + Offloading is a common process in information systems with limited audit storage capacity. - {{{ full_name }}} 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 you have a method to securely encrypt and off-load auditing. + {{{ full_name }}} installation media provides "rsyslogd", 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. Coupling this utility with "gnutls" (a secure communications library implementing the SSL, TLS and DTLS protocols) creates a method to securely encrypt and offload auditing. checktext: |- Verify {{{ full_name }}} uses the gtls driver to encrypt audit records offloaded onto a different system or media from the system being audited with the following command: @@ -22,9 +22,3 @@ fixtext: |- $DefaultNetstreamDriver gtls -vuln_discussion: |- - 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. - - {{{ full_name }}} installation media provides "rsyslogd", 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. Coupling this utility with "gnutls" (a secure communications library implementing the SSL, TLS and DTLS protocols) creates a method to securely encrypt and offload auditing. diff --git a/linux_os/guide/system/logging/ensure_rsyslog_log_file_configuration/rsyslog_remote_access_monitoring/policy/stig/shared.yml b/linux_os/guide/system/logging/ensure_rsyslog_log_file_configuration/rsyslog_remote_access_monitoring/policy/stig/shared.yml index b80ad1ffc9b7..98d32bd37cb0 100644 --- a/linux_os/guide/system/logging/ensure_rsyslog_log_file_configuration/rsyslog_remote_access_monitoring/policy/stig/shared.yml +++ b/linux_os/guide/system/logging/ensure_rsyslog_log_file_configuration/rsyslog_remote_access_monitoring/policy/stig/shared.yml @@ -2,10 +2,7 @@ srg_requirement: |- All {{{ full_name }}} remote access methods must be monitored. vuldiscussion: |- - Logging remote access methods can be used to trace the decrease the risks - associated with remote user access management. It can also be used to spot - cyber attacks and ensure ongoing compliance with organizational policies - surrounding the use of remote access methods. + Logging remote access methods can be used to trace the decrease in the risks associated with remote user access management. It can also be used to spot cyberattacks and ensure ongoing compliance with organizational policies surrounding the use of remote access methods. checktext: |- Verify that {{{ full_name }}} monitors all remote access methods. @@ -27,5 +24,3 @@ fixtext: |- $ sudo systemctl restart rsyslog.service -vuln_discussion: |- - Logging remote access methods can be used to trace the decrease in the risks associated with remote user access management. It can also be used to spot cyberattacks and ensure ongoing compliance with organizational policies surrounding the use of remote access methods. diff --git a/linux_os/guide/system/logging/journald/service_systemd-journald_enabled/policy/stig/shared.yml b/linux_os/guide/system/logging/journald/service_systemd-journald_enabled/policy/stig/shared.yml index 57438a885669..51b7c52d6d21 100644 --- a/linux_os/guide/system/logging/journald/service_systemd-journald_enabled/policy/stig/shared.yml +++ b/linux_os/guide/system/logging/journald/service_systemd-journald_enabled/policy/stig/shared.yml @@ -18,5 +18,3 @@ fixtext: |- $ sudo systemctl enable --now systemd-journald -vuln_discussion: |- - In the event of a system failure, {{{ full_name }}} must preserve any information necessary to determine cause of failure and any information necessary to return to operations with least disruption to system processes. diff --git a/linux_os/guide/system/logging/package_rsyslog-gnutls_installed/policy/stig/shared.yml b/linux_os/guide/system/logging/package_rsyslog-gnutls_installed/policy/stig/shared.yml index 5dd2eb4737a5..7e18f30c67ba 100644 --- a/linux_os/guide/system/logging/package_rsyslog-gnutls_installed/policy/stig/shared.yml +++ b/linux_os/guide/system/logging/package_rsyslog-gnutls_installed/policy/stig/shared.yml @@ -2,8 +2,7 @@ srg_requirement: |- {{{ full_name }}} must have the packages required for encrypting offloaded audit logs installed. vuldiscussion: |- - The rsyslog-gnutls package provides Transport Layer Security (TLS) support - for the rsyslog daemon, which enables secure remote logging. + The rsyslog-gnutls package provides Transport Layer Security (TLS) support for the rsyslog daemon, which enables secure remote logging. checktext: |- Verify that {{{ full_name }}} has the rsyslog-gnutls package installed with the following command: @@ -21,5 +20,3 @@ fixtext: |- $ sudo dnf install rsyslog-gnutls -vuln_discussion: |- - The rsyslog-gnutls package provides Transport Layer Security (TLS) support for the rsyslog daemon, which enables secure remote logging. diff --git a/linux_os/guide/system/logging/package_rsyslog_installed/policy/stig/shared.yml b/linux_os/guide/system/logging/package_rsyslog_installed/policy/stig/shared.yml index e5341ac1db00..dae9ad73cb5f 100644 --- a/linux_os/guide/system/logging/package_rsyslog_installed/policy/stig/shared.yml +++ b/linux_os/guide/system/logging/package_rsyslog_installed/policy/stig/shared.yml @@ -2,7 +2,7 @@ srg_requirement: |- {{{ full_name }}} must have the rsyslog package installed. vuldiscussion: |- - rsyslogd is a system utility providing support for message logging. Support for both internet and UNIX domain sockets enables this utility to support both local and remote logging. Couple this utility with "gnutls" (which is a secure communications library implementing the SSL, TLS and DTLS protocols), and you have a method to securely encrypt and off-load auditing. + 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), to create a method to securely encrypt and offload auditing. checktext: |- Verify that {{{ full_name }}} has the rsyslogd package installed with the following command: @@ -20,5 +20,3 @@ fixtext: |- $ sudo dnf install rsyslogd -vuln_discussion: |- - 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), to create a method to securely encrypt and offload auditing. diff --git a/linux_os/guide/system/logging/rsyslog_accepting_remote_messages/rsyslog_nolisten/policy/stig/shared.yml b/linux_os/guide/system/logging/rsyslog_accepting_remote_messages/rsyslog_nolisten/policy/stig/shared.yml index 7b98114542d6..1ffa081e7571 100644 --- a/linux_os/guide/system/logging/rsyslog_accepting_remote_messages/rsyslog_nolisten/policy/stig/shared.yml +++ b/linux_os/guide/system/logging/rsyslog_accepting_remote_messages/rsyslog_nolisten/policy/stig/shared.yml @@ -2,9 +2,9 @@ srg_requirement: |- {{{ full_name }}} must be configured so that the rsyslog daemon does not accept log messages from other servers unless the server is being used for log aggregation. vuldiscussion: |- - Unintentionally running a rsyslog server accepting remote messages puts the system at increased risk. Malicious rsyslog messages sent to the server could exploit vulnerabilities in the server software itself, could introduce misleading information in to the system's logs, or could fill the system's storage leading to a Denial of Service. + Unintentionally running a rsyslog server accepting remote messages puts the system at increased risk. Malicious rsyslog messages sent to the server could exploit vulnerabilities in the server software itself, could introduce misleading information into the system's logs, or could fill the system's storage leading to a denial of service. - If the system is intended to be a log aggregation server its use must be documented with the ISSO. + If the system is intended to be a log aggregation server, its use must be documented with the information system security officer (ISSO). checktext: |- Verify that {{{ full_name }}} is not configured to receive remote logs using rsyslog with the following commands: @@ -37,7 +37,3 @@ fixtext: |- $ sudo systemctl restart rsyslog.service -vuln_discussion: |- - Unintentionally running a rsyslog server accepting remote messages puts the system at increased risk. Malicious rsyslog messages sent to the server could exploit vulnerabilities in the server software itself, could introduce misleading information into the system's logs, or could fill the system's storage leading to a denial of service. - - If the system is intended to be a log aggregation server, its use must be documented with the information system security officer (ISSO). diff --git a/linux_os/guide/system/logging/rsyslog_sending_messages/rsyslog_remote_loghost/policy/stig/shared.yml b/linux_os/guide/system/logging/rsyslog_sending_messages/rsyslog_remote_loghost/policy/stig/shared.yml index c6a6f6c3f0b9..be902c2201c7 100644 --- a/linux_os/guide/system/logging/rsyslog_sending_messages/rsyslog_remote_loghost/policy/stig/shared.yml +++ b/linux_os/guide/system/logging/rsyslog_sending_messages/rsyslog_remote_loghost/policy/stig/shared.yml @@ -4,11 +4,12 @@ srg_requirement: |- vuldiscussion: |- Information stored in one location is vulnerable to accidental or incidental deletion or alteration. - Off-loading is a common process in information systems with limited audit storage capacity. + Offloading is a common process in information systems with limited audit storage capacity. - {{{ full_name }}} 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 you have a method to securely encrypt and off-load auditing. + {{{ full_name }}} installation media provides "rsyslogd", 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. Coupling this utility with "gnutls" (a secure communications library implementing the SSL, TLS and DTLS protocols) creates 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 @@ -31,17 +32,3 @@ fixtext: |- *.* @@[remoteloggingserver]:[port]" -vuln_discussion: |- - 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. - - {{{ full_name }}} installation media provides "rsyslogd", 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. Coupling this utility with "gnutls" (a secure communications library implementing the SSL, TLS and DTLS protocols) creates 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. diff --git a/linux_os/guide/system/logging/service_rsyslog_enabled/policy/stig/shared.yml b/linux_os/guide/system/logging/service_rsyslog_enabled/policy/stig/shared.yml index d5a5c895defb..46391d9b41e4 100644 --- a/linux_os/guide/system/logging/service_rsyslog_enabled/policy/stig/shared.yml +++ b/linux_os/guide/system/logging/service_rsyslog_enabled/policy/stig/shared.yml @@ -2,8 +2,7 @@ srg_requirement: |- The rsyslog service on {{{ full_name }}} must be active. vuldiscussion: |- - The "rsyslog" service must be running in order to provide - logging services, which are essential to system administration. + The "rsyslog" service must be running to provide logging services, which are essential to system administration. checktext: |- Verify that "rsyslog" is active with the following command: @@ -19,5 +18,3 @@ fixtext: |- $ sudo systemctl enable --now rsyslog -vuln_discussion: |- - The "rsyslog" service must be running to provide logging services, which are essential to system administration. diff --git a/linux_os/guide/system/network/network-firewalld/firewalld-backend/policy/stig/shared.yml b/linux_os/guide/system/network/network-firewalld/firewalld-backend/policy/stig/shared.yml index 5e5de972b6ad..7f01413ab6e6 100644 --- a/linux_os/guide/system/network/network-firewalld/firewalld-backend/policy/stig/shared.yml +++ b/linux_os/guide/system/network/network-firewalld/firewalld-backend/policy/stig/shared.yml @@ -18,7 +18,3 @@ checktext: |- If the "nftables" is not set as the "FirewallBackend" default, this is a finding. -vuln_discussion: |- - 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 {{{ full_name }}} 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. diff --git a/linux_os/guide/system/network/network-firewalld/firewalld_activation/package_firewalld_installed/policy/stig/shared.yml b/linux_os/guide/system/network/network-firewalld/firewalld_activation/package_firewalld_installed/policy/stig/shared.yml index 98c4e8a61910..2449e16df976 100644 --- a/linux_os/guide/system/network/network-firewalld/firewalld_activation/package_firewalld_installed/policy/stig/shared.yml +++ b/linux_os/guide/system/network/network-firewalld/firewalld_activation/package_firewalld_installed/policy/stig/shared.yml @@ -6,10 +6,9 @@ vuldiscussion: |- 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. + Remote access is access to DOD nonpublic information systems by an authorized user (or an information system) communicating through an external, nonorganization-controlled network. Remote access methods include, for example, dial-up, broadband, and wireless. - {{{ full_name }}} 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)." + {{{ full_name }}} 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). checktext: |- Run the following command to determine if the firewalld package is installed with the following command: @@ -27,11 +26,3 @@ fixtext: |- $ sudo dnf install firewalld -vuln_discussion: |- - "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, nonorganization-controlled network. Remote access methods include, for example, dial-up, broadband, and wireless. - - {{{ full_name }}} 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). diff --git a/linux_os/guide/system/network/network-firewalld/firewalld_activation/service_firewalld_enabled/policy/stig/shared.yml b/linux_os/guide/system/network/network-firewalld/firewalld_activation/service_firewalld_enabled/policy/stig/shared.yml index 94e12e27cffc..3a8ea4fea89f 100644 --- a/linux_os/guide/system/network/network-firewalld/firewalld_activation/service_firewalld_enabled/policy/stig/shared.yml +++ b/linux_os/guide/system/network/network-firewalld/firewalld_activation/service_firewalld_enabled/policy/stig/shared.yml @@ -6,7 +6,8 @@ vuldiscussion: |- 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. + 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. + {{{ full_name }}} functionality (e.g., RDP) 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). checktext: |- @@ -23,11 +24,3 @@ fixtext: |- $ sudo systemctl enable --now firewalld -vuln_discussion: |- - "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. - - {{{ full_name }}} functionality (e.g., RDP) 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). diff --git a/linux_os/guide/system/network/network-firewalld/ruleset_modifications/configure_firewalld_ports/policy/stig/shared.yml b/linux_os/guide/system/network/network-firewalld/ruleset_modifications/configure_firewalld_ports/policy/stig/shared.yml index 53b9f546bca5..8bbd6574b8d7 100644 --- a/linux_os/guide/system/network/network-firewalld/ruleset_modifications/configure_firewalld_ports/policy/stig/shared.yml +++ b/linux_os/guide/system/network/network-firewalld/ruleset_modifications/configure_firewalld_ports/policy/stig/shared.yml @@ -2,26 +2,11 @@ srg_requirement: |- {{{ full_name }}} must control remote access methods. vuldiscussion: |- - In order to prevent unauthorized connection of devices, unauthorized transfer of information, - or unauthorized tunneling (i.e., embedding of data types within data types), organizations must - disable or restrict unused or unnecessary physical and logical ports/protocols on information - systems. - - - - Operating systems are capable of providing a wide variety of functions and services. - Some of the functions and services provided by default may not be necessary to support - essential organizational operations. - Additionally, it is sometimes convenient to provide multiple services from a single component - (e.g., VPN and IPS); however, doing so increases risk over limiting the services provided by - one component. - + To prevent unauthorized connection of devices, unauthorized transfer of information, or unauthorized tunneling (i.e., embedding of data types within data types), organizations must disable or restrict unused or unnecessary physical and logical ports/protocols on information systems. + Operating systems are capable of providing a wide variety of functions and services. Some of the functions and services provided by default may not be necessary to support essential organizational operations. Additionally, it is sometimes convenient to provide multiple services from a single component (e.g., VPN and IPS); however, doing so increases risk over limiting the services provided by one component. - To support the requirements and principles of least functionality, the operating system must - support the organizational requirements, providing only essential capabilities and limiting the - use of ports, protocols, and/or services to only those required, authorized, and approved to - conduct official business. + To support the requirements and principles of least functionality, the operating system must support the organizational requirements, providing only essential capabilities and limiting the use of ports, protocols, and/or services to only those required, authorized, and approved to conduct official business. checktext: |- Inspect the list of enabled firewall ports and verify they are configured correctly by running the following command: @@ -41,9 +26,3 @@ fixtext: |- or $ sudo firewall-cmd --permanent --add-service=service_name -vuln_discussion: |- - To prevent unauthorized connection of devices, unauthorized transfer of information, or unauthorized tunneling (i.e., embedding of data types within data types), organizations must disable or restrict unused or unnecessary physical and logical ports/protocols on information systems. - - Operating systems are capable of providing a wide variety of functions and services. Some of the functions and services provided by default may not be necessary to support essential organizational operations. Additionally, it is sometimes convenient to provide multiple services from a single component (e.g., VPN and IPS); however, doing so increases risk over limiting the services provided by one component. - - To support the requirements and principles of least functionality, the operating system must support the organizational requirements, providing only essential capabilities and limiting the use of ports, protocols, and/or services to only those required, authorized, and approved to conduct official business. diff --git a/linux_os/guide/system/network/network-firewalld/ruleset_modifications/configured_firewalld_default_deny/policy/stig/shared.yml b/linux_os/guide/system/network/network-firewalld/ruleset_modifications/configured_firewalld_default_deny/policy/stig/shared.yml index 16da25313b31..dada8b279100 100644 --- a/linux_os/guide/system/network/network-firewalld/ruleset_modifications/configured_firewalld_default_deny/policy/stig/shared.yml +++ b/linux_os/guide/system/network/network-firewalld/ruleset_modifications/configured_firewalld_default_deny/policy/stig/shared.yml @@ -41,7 +41,3 @@ checktext: |- If no zones are active on the {{{ full_name }}} interfaces or if runtime and permanent targets are set to a different option other than "DROP", this is a finding. -vuln_discussion: |- - Failure to restrict network connectivity only to authorized systems permits inbound connections from malicious systems. It also permits outbound connections that may facilitate exfiltration of DOD data. - - {{{ full_name }}} incorporates the "firewalld" daemon, which allows for many different configurations. One of these configurations is zones. Zones can be utilized to a deny-all, allow-by-exception approach. The default "drop" zone will drop all incoming network packets unless it is explicitly allowed by the configuration file or is related to an outgoing network connection. diff --git a/linux_os/guide/system/network/network-ipsec/libreswan_approved_tunnels/policy/stig/shared.yml b/linux_os/guide/system/network/network-ipsec/libreswan_approved_tunnels/policy/stig/shared.yml index 7959184d401a..ba2b3fdf9369 100644 --- a/linux_os/guide/system/network/network-ipsec/libreswan_approved_tunnels/policy/stig/shared.yml +++ b/linux_os/guide/system/network/network-ipsec/libreswan_approved_tunnels/policy/stig/shared.yml @@ -2,7 +2,7 @@ srg_requirement: |- {{{ full_name }}} must not have unauthorized IP tunnels configured. vuldiscussion: |- - IP tunneling mechanisms can be used to bypass network filtering. If tunneling is required, it must be documented with the Information System Security Officer (ISSO). + IP tunneling mechanisms can be used to bypass network filtering. If tunneling is required, it must be documented with the information system security officer (ISSO). checktext: |- Verify that {{{ full_name }}} does not have unauthorized IP tunnels configured. @@ -26,5 +26,3 @@ checktext: |- fixtext: |- Remove all unapproved tunnels from the system, or document them with the ISSO. -vuln_discussion: |- - IP tunneling mechanisms can be used to bypass network filtering. If tunneling is required, it must be documented with the information system security officer (ISSO). diff --git a/linux_os/guide/system/network/network-ipsec/package_libreswan_installed/policy/stig/shared.yml b/linux_os/guide/system/network/network-ipsec/package_libreswan_installed/policy/stig/shared.yml index d5a833868115..84f1e3ab1e2f 100644 --- a/linux_os/guide/system/network/network-ipsec/package_libreswan_installed/policy/stig/shared.yml +++ b/linux_os/guide/system/network/network-ipsec/package_libreswan_installed/policy/stig/shared.yml @@ -2,9 +2,7 @@ srg_requirement: |- {{{ full_name }}} libreswan package must be installed. vuldiscussion: |- - Providing the ability for remote users or systems - to initiate a secure VPN connection protects information when it is - transmitted over a wide area network. + Providing the ability for remote users or systems to initiate a secure VPN connection protects information when it is transmitted over a wide area network. checktext: |- Verify that {{{ full_name }}} libreswan service package is installed. @@ -24,5 +22,3 @@ fixtext: |- $ sudo dnf install libreswan -vuln_discussion: |- - Providing the ability for remote users or systems to initiate a secure VPN connection protects information when it is transmitted over a wide area network. diff --git a/linux_os/guide/system/network/network-ipv6/configuring_ipv6/sysctl_net_ipv6_conf_all_accept_ra/policy/stig/shared.yml b/linux_os/guide/system/network/network-ipv6/configuring_ipv6/sysctl_net_ipv6_conf_all_accept_ra/policy/stig/shared.yml index 9e337631bb2b..40cd1c04d532 100644 --- a/linux_os/guide/system/network/network-ipv6/configuring_ipv6/sysctl_net_ipv6_conf_all_accept_ra/policy/stig/shared.yml +++ b/linux_os/guide/system/network/network-ipv6/configuring_ipv6/sysctl_net_ipv6_conf_all_accept_ra/policy/stig/shared.yml @@ -36,5 +36,3 @@ fixtext: |- $ sudo sysctl --system -vuln_discussion: |- - An illicit router advertisement message could result in a man-in-the-middle attack. diff --git a/linux_os/guide/system/network/network-ipv6/configuring_ipv6/sysctl_net_ipv6_conf_all_accept_redirects/policy/stig/shared.yml b/linux_os/guide/system/network/network-ipv6/configuring_ipv6/sysctl_net_ipv6_conf_all_accept_redirects/policy/stig/shared.yml index eff3d81cd6a6..438f9381c581 100644 --- a/linux_os/guide/system/network/network-ipv6/configuring_ipv6/sysctl_net_ipv6_conf_all_accept_redirects/policy/stig/shared.yml +++ b/linux_os/guide/system/network/network-ipv6/configuring_ipv6/sysctl_net_ipv6_conf_all_accept_redirects/policy/stig/shared.yml @@ -36,5 +36,3 @@ fixtext: |- $ sudo sysctl --system -vuln_discussion: |- - An illicit ICMP redirect message could result in a man-in-the-middle attack. diff --git a/linux_os/guide/system/network/network-ipv6/configuring_ipv6/sysctl_net_ipv6_conf_all_accept_source_route/policy/stig/shared.yml b/linux_os/guide/system/network/network-ipv6/configuring_ipv6/sysctl_net_ipv6_conf_all_accept_source_route/policy/stig/shared.yml index 5523065dcb0f..6f59d35d5532 100644 --- a/linux_os/guide/system/network/network-ipv6/configuring_ipv6/sysctl_net_ipv6_conf_all_accept_source_route/policy/stig/shared.yml +++ b/linux_os/guide/system/network/network-ipv6/configuring_ipv6/sysctl_net_ipv6_conf_all_accept_source_route/policy/stig/shared.yml @@ -4,7 +4,6 @@ srg_requirement: |- vuldiscussion: |- 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. - checktext: |- Verify {{{ full_name }}} does not accept IPv6 source-routed packets. @@ -37,5 +36,3 @@ fixtext: |- $ sudo sysctl --system -vuln_discussion: |- - 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. diff --git a/linux_os/guide/system/network/network-ipv6/configuring_ipv6/sysctl_net_ipv6_conf_all_forwarding/policy/stig/shared.yml b/linux_os/guide/system/network/network-ipv6/configuring_ipv6/sysctl_net_ipv6_conf_all_forwarding/policy/stig/shared.yml index 39dd20a8c961..0fdc81242d36 100644 --- a/linux_os/guide/system/network/network-ipv6/configuring_ipv6/sysctl_net_ipv6_conf_all_forwarding/policy/stig/shared.yml +++ b/linux_os/guide/system/network/network-ipv6/configuring_ipv6/sysctl_net_ipv6_conf_all_forwarding/policy/stig/shared.yml @@ -2,9 +2,7 @@ srg_requirement: |- {{{ full_name }}} must not enable IPv6 packet forwarding unless the system is a router. vuldiscussion: |- - IP forwarding permits the kernel to forward packets from one network - interface to another. The ability to forward packets between two networks is - only appropriate for systems acting as routers. + IP forwarding permits the kernel to forward packets from one network interface to another. The ability to forward packets between two networks is only appropriate for systems acting as routers. checktext: |- Verify {{{ full_name }}} is not performing IPv6 packet forwarding, unless the system is a router. @@ -38,5 +36,3 @@ fixtext: |- $ sudo sysctl --system -vuln_discussion: |- - IP forwarding permits the kernel to forward packets from one network interface to another. The ability to forward packets between two networks is only appropriate for systems acting as routers. diff --git a/linux_os/guide/system/network/network-ipv6/configuring_ipv6/sysctl_net_ipv6_conf_default_accept_ra/policy/stig/shared.yml b/linux_os/guide/system/network/network-ipv6/configuring_ipv6/sysctl_net_ipv6_conf_default_accept_ra/policy/stig/shared.yml index bc5acada8c50..602bf7414782 100644 --- a/linux_os/guide/system/network/network-ipv6/configuring_ipv6/sysctl_net_ipv6_conf_default_accept_ra/policy/stig/shared.yml +++ b/linux_os/guide/system/network/network-ipv6/configuring_ipv6/sysctl_net_ipv6_conf_default_accept_ra/policy/stig/shared.yml @@ -36,5 +36,3 @@ fixtext: |- $ sudo sysctl --system -vuln_discussion: |- - An illicit router advertisement message could result in a man-in-the-middle attack. diff --git a/linux_os/guide/system/network/network-ipv6/configuring_ipv6/sysctl_net_ipv6_conf_default_accept_redirects/policy/stig/shared.yml b/linux_os/guide/system/network/network-ipv6/configuring_ipv6/sysctl_net_ipv6_conf_default_accept_redirects/policy/stig/shared.yml index 5eb1f43712d2..e0755a8302e3 100644 --- a/linux_os/guide/system/network/network-ipv6/configuring_ipv6/sysctl_net_ipv6_conf_default_accept_redirects/policy/stig/shared.yml +++ b/linux_os/guide/system/network/network-ipv6/configuring_ipv6/sysctl_net_ipv6_conf_default_accept_redirects/policy/stig/shared.yml @@ -36,5 +36,3 @@ fixtext: |- $ sudo sysctl --system -vuln_discussion: |- - 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. diff --git a/linux_os/guide/system/network/network-ipv6/configuring_ipv6/sysctl_net_ipv6_conf_default_accept_source_route/policy/stig/shared.yml b/linux_os/guide/system/network/network-ipv6/configuring_ipv6/sysctl_net_ipv6_conf_default_accept_source_route/policy/stig/shared.yml index cc5b0d74d9a3..7f0a8f68e82e 100644 --- a/linux_os/guide/system/network/network-ipv6/configuring_ipv6/sysctl_net_ipv6_conf_default_accept_source_route/policy/stig/shared.yml +++ b/linux_os/guide/system/network/network-ipv6/configuring_ipv6/sysctl_net_ipv6_conf_default_accept_source_route/policy/stig/shared.yml @@ -4,8 +4,7 @@ srg_requirement: |- vuldiscussion: |- 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. - Accepting source-routed packets in the IPv6 protocol has few legitimate - uses. It should be disabled unless it is absolutely required. + Accepting source-routed packets in the IPv6 protocol has few legitimate uses. It must be disabled unless it is absolutely required. checktext: |- Verify {{{ full_name }}} does not accept IPv6 source-routed packets by default. @@ -39,7 +38,3 @@ fixtext: |- $ sudo sysctl --system -vuln_discussion: |- - 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. - - Accepting source-routed packets in the IPv6 protocol has few legitimate uses. It must be disabled unless it is absolutely required. diff --git a/linux_os/guide/system/network/network-kernel/network_host_and_router_parameters/sysctl_net_ipv4_conf_all_accept_redirects/policy/stig/shared.yml b/linux_os/guide/system/network/network-kernel/network_host_and_router_parameters/sysctl_net_ipv4_conf_all_accept_redirects/policy/stig/shared.yml index 1604aa428bc7..b3055bc7b716 100644 --- a/linux_os/guide/system/network/network-kernel/network_host_and_router_parameters/sysctl_net_ipv4_conf_all_accept_redirects/policy/stig/shared.yml +++ b/linux_os/guide/system/network/network-kernel/network_host_and_router_parameters/sysctl_net_ipv4_conf_all_accept_redirects/policy/stig/shared.yml @@ -2,14 +2,9 @@ srg_requirement: |- {{{ full_name }}} must ignore Internet Protocol version 4 (IPv4) Internet Control Message Protocol (ICMP) redirect messages. vuldiscussion: |- - 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. - + ICMP redirect messages are used by routers to inform hosts that a more direct route exists for a particular destination. These messages modify the host's route table and are unauthenticated. An illicit ICMP redirect message could result in a man-in-the-middle attack. - This feature of the IPv4 protocol has few legitimate uses. It should be - disabled unless absolutely required." + This feature of the IPv4 protocol has few legitimate uses. It should be disabled unless absolutely required. checktext: |- Verify {{{ full_name }}} will not accept IPv4 ICMP redirect messages. @@ -41,7 +36,3 @@ fixtext: |- $ sudo sysctl --system -vuln_discussion: |- - ICMP redirect messages are used by routers to inform hosts that a more direct route exists for a particular destination. These messages modify the host's route table and are unauthenticated. An illicit ICMP redirect message could result in a man-in-the-middle attack. - - This feature of the IPv4 protocol has few legitimate uses. It should be disabled unless absolutely required. diff --git a/linux_os/guide/system/network/network-kernel/network_host_and_router_parameters/sysctl_net_ipv4_conf_all_accept_source_route/policy/stig/shared.yml b/linux_os/guide/system/network/network-kernel/network_host_and_router_parameters/sysctl_net_ipv4_conf_all_accept_source_route/policy/stig/shared.yml index b6dc0b98f820..8658e8ad8905 100644 --- a/linux_os/guide/system/network/network-kernel/network_host_and_router_parameters/sysctl_net_ipv4_conf_all_accept_source_route/policy/stig/shared.yml +++ b/linux_os/guide/system/network/network-kernel/network_host_and_router_parameters/sysctl_net_ipv4_conf_all_accept_source_route/policy/stig/shared.yml @@ -2,16 +2,9 @@ srg_requirement: |- {{{ full_name }}} must not forward Internet Protocol version 4 (IPv4) source-routed packets. vuldiscussion: |- - Source-routed packets allow the source of the packet to suggest routers - forward the packet along a different path than configured on the router, - which can be used to bypass network security measures. This requirement - applies only to the forwarding of source-routerd traffic, such as when IPv4 - forwarding is enabled and the system is functioning as a router. - - + Source-routed packets allow the source of the packet to suggest routers forward the packet along a different path than configured on the router, which can be used to bypass network security measures. This requirement applies only to the forwarding of source-routerd traffic, such as when IPv4 forwarding is enabled and the system is functioning as a router. - Accepting source-routed packets in the IPv4 protocol has few legitimate - uses. It should be disabled unless it is absolutely required. + Accepting source-routed packets in the IPv4 protocol has few legitimate uses. It must be disabled unless it is absolutely required. checktext: |- Verify {{{ full_name }}} will not accept IPv4 source-routed packets. @@ -43,7 +36,3 @@ fixtext: |- $ sudo sysctl --system -vuln_discussion: |- - Source-routed packets allow the source of the packet to suggest routers forward the packet along a different path than configured on the router, which can be used to bypass network security measures. This requirement applies only to the forwarding of source-routerd traffic, such as when IPv4 forwarding is enabled and the system is functioning as a router. - - Accepting source-routed packets in the IPv4 protocol has few legitimate uses. It must be disabled unless it is absolutely required. diff --git a/linux_os/guide/system/network/network-kernel/network_host_and_router_parameters/sysctl_net_ipv4_conf_all_forwarding/policy/stig/shared.yml b/linux_os/guide/system/network/network-kernel/network_host_and_router_parameters/sysctl_net_ipv4_conf_all_forwarding/policy/stig/shared.yml index 67590db4d0e6..709dd1852dd4 100644 --- a/linux_os/guide/system/network/network-kernel/network_host_and_router_parameters/sysctl_net_ipv4_conf_all_forwarding/policy/stig/shared.yml +++ b/linux_os/guide/system/network/network-kernel/network_host_and_router_parameters/sysctl_net_ipv4_conf_all_forwarding/policy/stig/shared.yml @@ -31,5 +31,3 @@ checktext: |- If "net.ipv4.conf.all.forwarding" is not set to "0" and is not documented with the ISSO as an operational requirement or is missing, this is a finding. -vuln_discussion: |- - Routing protocol daemons are typically used on routers to exchange network topology information with other routers. If this capability is used when not required, system network information may be unnecessarily transmitted across the network. diff --git a/linux_os/guide/system/network/network-kernel/network_host_and_router_parameters/sysctl_net_ipv4_conf_all_log_martians/policy/stig/shared.yml b/linux_os/guide/system/network/network-kernel/network_host_and_router_parameters/sysctl_net_ipv4_conf_all_log_martians/policy/stig/shared.yml index 38735c42ca6f..67c3150017ee 100644 --- a/linux_os/guide/system/network/network-kernel/network_host_and_router_parameters/sysctl_net_ipv4_conf_all_log_martians/policy/stig/shared.yml +++ b/linux_os/guide/system/network/network-kernel/network_host_and_router_parameters/sysctl_net_ipv4_conf_all_log_martians/policy/stig/shared.yml @@ -2,10 +2,7 @@ srg_requirement: |- {{{ full_name }}} must log IPv4 packets with impossible addresses. vuldiscussion: |- - The presence of "martian" packets (which have impossible addresses) - as well as spoofed packets, source-routed packets, and redirects could be a - sign of nefarious network activity. Logging these packets enables this activity - to be detected. + The presence of "martian" packets (which have impossible addresses) as well as spoofed packets, source-routed packets, and redirects could be a sign of nefarious network activity. Logging these packets enables this activity to be detected. checktext: |- Verify {{{ full_name }}} logs IPv4 martian packets. @@ -37,5 +34,3 @@ fixtext: |- $ sudo sysctl --system -vuln_discussion: |- - The presence of "martian" packets (which have impossible addresses) as well as spoofed packets, source-routed packets, and redirects could be a sign of nefarious network activity. Logging these packets enables this activity to be detected. diff --git a/linux_os/guide/system/network/network-kernel/network_host_and_router_parameters/sysctl_net_ipv4_conf_all_rp_filter/policy/stig/shared.yml b/linux_os/guide/system/network/network-kernel/network_host_and_router_parameters/sysctl_net_ipv4_conf_all_rp_filter/policy/stig/shared.yml index b05081cd3f57..3f6f71dce8be 100644 --- a/linux_os/guide/system/network/network-kernel/network_host_and_router_parameters/sysctl_net_ipv4_conf_all_rp_filter/policy/stig/shared.yml +++ b/linux_os/guide/system/network/network-kernel/network_host_and_router_parameters/sysctl_net_ipv4_conf_all_rp_filter/policy/stig/shared.yml @@ -2,11 +2,7 @@ srg_requirement: |- {{{ full_name }}} must use reverse path filtering on all IPv4 interfaces. vuldiscussion: |- - Enabling reverse path filtering drops packets with source addresses - that should not have been able to be received on the interface they were - received on. It should not be used on systems which are routers for - complicated networks, but is helpful for end hosts and routers serving small - networks. + Enabling reverse path filtering drops packets with source addresses that should not have been able to be received on the interface on which they were received. It must not be used on systems that are routers for complicated networks, but is helpful for end hosts and routers serving small networks. checktext: |- Verify {{{ full_name }}} uses reverse path filtering on all IPv4 interfaces with the following commands: @@ -36,5 +32,3 @@ fixtext: |- $ sudo sysctl --system -vuln_discussion: |- - Enabling reverse path filtering drops packets with source addresses that should not have been able to be received on the interface on which they were received. It must not be used on systems that are routers for complicated networks, but is helpful for end hosts and routers serving small networks. diff --git a/linux_os/guide/system/network/network-kernel/network_host_and_router_parameters/sysctl_net_ipv4_conf_default_accept_redirects/policy/stig/shared.yml b/linux_os/guide/system/network/network-kernel/network_host_and_router_parameters/sysctl_net_ipv4_conf_default_accept_redirects/policy/stig/shared.yml index 4d5f0cd58fa1..cbe945160435 100644 --- a/linux_os/guide/system/network/network-kernel/network_host_and_router_parameters/sysctl_net_ipv4_conf_default_accept_redirects/policy/stig/shared.yml +++ b/linux_os/guide/system/network/network-kernel/network_host_and_router_parameters/sysctl_net_ipv4_conf_default_accept_redirects/policy/stig/shared.yml @@ -2,13 +2,9 @@ srg_requirement: |- {{{ full_name }}} must prevent IPv4 Internet Control Message Protocol (ICMP) redirect messages from being accepted. vuldiscussion: |- - 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. + ICMP redirect messages are used by routers to inform hosts that a more direct route exists for a particular destination. These messages modify the host's route table and are unauthenticated. An illicit ICMP redirect message could result in a man-in-the-middle attack. - This feature of the IPv4 protocol has few legitimate uses. It should - be disabled unless absolutely required. + This feature of the IPv4 protocol has few legitimate uses. It must be disabled unless absolutely required. checktext: |- Verify {{{ full_name }}} will not accept IPv4 ICMP redirect messages. @@ -40,7 +36,3 @@ fixtext: |- $ sudo sysctl --system -vuln_discussion: |- - ICMP redirect messages are used by routers to inform hosts that a more direct route exists for a particular destination. These messages modify the host's route table and are unauthenticated. An illicit ICMP redirect message could result in a man-in-the-middle attack. - - This feature of the IPv4 protocol has few legitimate uses. It must be disabled unless absolutely required. diff --git a/linux_os/guide/system/network/network-kernel/network_host_and_router_parameters/sysctl_net_ipv4_conf_default_accept_source_route/policy/stig/shared.yml b/linux_os/guide/system/network/network-kernel/network_host_and_router_parameters/sysctl_net_ipv4_conf_default_accept_source_route/policy/stig/shared.yml index c4509e897350..c14cc887698e 100644 --- a/linux_os/guide/system/network/network-kernel/network_host_and_router_parameters/sysctl_net_ipv4_conf_default_accept_source_route/policy/stig/shared.yml +++ b/linux_os/guide/system/network/network-kernel/network_host_and_router_parameters/sysctl_net_ipv4_conf_default_accept_source_route/policy/stig/shared.yml @@ -2,15 +2,9 @@ srg_requirement: |- {{{ full_name }}} must not forward IPv4 source-routed packets by default. vuldiscussion: |- - Source-routed packets allow the source of the packet to suggest routers - forward the packet along a different path than configured on the router, - which can be used to bypass network security measures. - + Source-routed packets allow the source of the packet to suggest routers forward the packet along a different path than configured on the router, which can be used to bypass network security measures. - Accepting source-routed packets in the IPv4 protocol has few legitimate - uses. It should be disabled unless it is absolutely required, such as when - IPv4 forwarding is enabled and the system is legitimately functioning as a - router. + Accepting source-routed packets in the IPv4 protocol has few legitimate uses. It must be disabled unless it is absolutely required, such as when IPv4 forwarding is enabled and the system is legitimately functioning as a router. checktext: |- Verify {{{ full_name }}} does not accept IPv4 source-routed packets by default. @@ -42,7 +36,3 @@ fixtext: |- $ sudo sysctl --system -vuln_discussion: |- - Source-routed packets allow the source of the packet to suggest routers forward the packet along a different path than configured on the router, which can be used to bypass network security measures. - - Accepting source-routed packets in the IPv4 protocol has few legitimate uses. It must be disabled unless it is absolutely required, such as when IPv4 forwarding is enabled and the system is legitimately functioning as a router. diff --git a/linux_os/guide/system/network/network-kernel/network_host_and_router_parameters/sysctl_net_ipv4_conf_default_log_martians/policy/stig/shared.yml b/linux_os/guide/system/network/network-kernel/network_host_and_router_parameters/sysctl_net_ipv4_conf_default_log_martians/policy/stig/shared.yml index faccd8508304..253c953670df 100644 --- a/linux_os/guide/system/network/network-kernel/network_host_and_router_parameters/sysctl_net_ipv4_conf_default_log_martians/policy/stig/shared.yml +++ b/linux_os/guide/system/network/network-kernel/network_host_and_router_parameters/sysctl_net_ipv4_conf_default_log_martians/policy/stig/shared.yml @@ -31,6 +31,3 @@ checktext: |- If "net.ipv4.conf.default.log_martians" is not set to "1" or is missing, this is a finding. -vuln_discussion: |- - The presence of "martian" packets (which have impossible addresses) as well as spoofed packets, source-routed packets, and redirects could be a sign of nefarious network activity. - Logging these packets enables this activity to be detected. diff --git a/linux_os/guide/system/network/network-kernel/network_host_and_router_parameters/sysctl_net_ipv4_conf_default_rp_filter/policy/stig/shared.yml b/linux_os/guide/system/network/network-kernel/network_host_and_router_parameters/sysctl_net_ipv4_conf_default_rp_filter/policy/stig/shared.yml index 05e60bb59ef4..a0b94448dc9f 100644 --- a/linux_os/guide/system/network/network-kernel/network_host_and_router_parameters/sysctl_net_ipv4_conf_default_rp_filter/policy/stig/shared.yml +++ b/linux_os/guide/system/network/network-kernel/network_host_and_router_parameters/sysctl_net_ipv4_conf_default_rp_filter/policy/stig/shared.yml @@ -2,11 +2,7 @@ srg_requirement: |- {{{ full_name }}} must use a reverse-path filter for IPv4 network traffic when possible by default. vuldiscussion: |- - Enabling reverse path filtering drops packets with source addresses - that should not have been able to be received on the interface they were - received on. It should not be used on systems which are routers for - complicated networks, but is helpful for end hosts and routers serving small - networks. + Enabling reverse path filtering drops packets with source addresses that should not have been able to be received on the interface on which they were received. It must not be used on systems that are routers for complicated networks, but is helpful for end hosts and routers serving small networks. checktext: |- Verify {{{ full_name }}} uses reverse path filtering on IPv4 interfaces with the following commands: @@ -36,5 +32,3 @@ fixtext: |- $ sudo sysctl --system -vuln_discussion: |- - Enabling reverse path filtering drops packets with source addresses that should not have been able to be received on the interface on which they were received. It must not be used on systems that are routers for complicated networks, but is helpful for end hosts and routers serving small networks. diff --git a/linux_os/guide/system/network/network-kernel/network_host_and_router_parameters/sysctl_net_ipv4_icmp_echo_ignore_broadcasts/policy/stig/shared.yml b/linux_os/guide/system/network/network-kernel/network_host_and_router_parameters/sysctl_net_ipv4_icmp_echo_ignore_broadcasts/policy/stig/shared.yml index db1114448169..84aef73a9ddd 100644 --- a/linux_os/guide/system/network/network-kernel/network_host_and_router_parameters/sysctl_net_ipv4_icmp_echo_ignore_broadcasts/policy/stig/shared.yml +++ b/linux_os/guide/system/network/network-kernel/network_host_and_router_parameters/sysctl_net_ipv4_icmp_echo_ignore_broadcasts/policy/stig/shared.yml @@ -2,12 +2,9 @@ srg_requirement: |- {{{ full_name }}} must not respond to Internet Control Message Protocol (ICMP) echoes sent to a broadcast address. vuldiscussion: |- - Responding to broadcast (ICMP) echoes facilitates network mapping - and provides a vector for amplification attacks. - + Responding to broadcast (ICMP) echoes facilitates network mapping and provides a vector for amplification attacks. - Ignoring ICMP echo requests (pings) sent to broadcast or multicast - addresses makes the system slightly more difficult to enumerate on the network. + Ignoring ICMP echo requests (pings) sent to broadcast or multicast addresses makes the system slightly more difficult to enumerate on the network. checktext: |- Verify {{{ full_name }}} does not respond to ICMP echoes sent to a broadcast address. @@ -39,7 +36,3 @@ fixtext: |- $ sudo sysctl --system -vuln_discussion: |- - Responding to broadcast (ICMP) echoes facilitates network mapping and provides a vector for amplification attacks. - - Ignoring ICMP echo requests (pings) sent to broadcast or multicast addresses makes the system slightly more difficult to enumerate on the network. diff --git a/linux_os/guide/system/network/network-kernel/network_host_and_router_parameters/sysctl_net_ipv4_icmp_ignore_bogus_error_responses/policy/stig/shared.yml b/linux_os/guide/system/network/network-kernel/network_host_and_router_parameters/sysctl_net_ipv4_icmp_ignore_bogus_error_responses/policy/stig/shared.yml index 6df9977d06b5..8caca3f5371b 100644 --- a/linux_os/guide/system/network/network-kernel/network_host_and_router_parameters/sysctl_net_ipv4_icmp_ignore_bogus_error_responses/policy/stig/shared.yml +++ b/linux_os/guide/system/network/network-kernel/network_host_and_router_parameters/sysctl_net_ipv4_icmp_ignore_bogus_error_responses/policy/stig/shared.yml @@ -2,7 +2,7 @@ srg_requirement: |- {{{ full_name }}} must limit the number of bogus Internet Control Message Protocol (ICMP) response errors logs. vuldiscussion: |- - Some routers will send responses to broadcast frames that violate RFC-1122 which fills up a log file system with many useless error messages. An attacker may take advantage of this and attempt to flood the logs with bogus error logs. Ignoring bogus ICMP error responses reduces log size, although some activity would not be logged. + Some routers will send responses to broadcast frames that violate RFC-1122, which fills up a log file system with many useless error messages. An attacker may take advantage of this and attempt to flood the logs with bogus error logs. Ignoring bogus ICMP error responses reduces log size, although some activity would not be logged. checktext: |- The runtime status of the net.ipv4.icmp_ignore_bogus_error_responses kernel parameter can be queried by running the following command: @@ -32,5 +32,3 @@ fixtext: |- $ sudo sysctl --system -vuln_discussion: |- - Some routers will send responses to broadcast frames that violate RFC-1122, which fills up a log file system with many useless error messages. An attacker may take advantage of this and attempt to flood the logs with bogus error logs. Ignoring bogus ICMP error responses reduces log size, although some activity would not be logged. diff --git a/linux_os/guide/system/network/network-kernel/network_host_and_router_parameters/sysctl_net_ipv4_tcp_syncookies/policy/stig/shared.yml b/linux_os/guide/system/network/network-kernel/network_host_and_router_parameters/sysctl_net_ipv4_tcp_syncookies/policy/stig/shared.yml index 81e617111748..1d7a43616152 100644 --- a/linux_os/guide/system/network/network-kernel/network_host_and_router_parameters/sysctl_net_ipv4_tcp_syncookies/policy/stig/shared.yml +++ b/linux_os/guide/system/network/network-kernel/network_host_and_router_parameters/sysctl_net_ipv4_tcp_syncookies/policy/stig/shared.yml @@ -2,7 +2,7 @@ srg_requirement: |- {{{ full_name }}} must be configured to use TCP syncookies. vuldiscussion: |- - 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. + 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. @@ -35,7 +35,3 @@ fixtext: |- $ sudo sysctl --system -vuln_discussion: |- - 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. diff --git a/linux_os/guide/system/network/network-kernel/network_host_parameters/sysctl_net_ipv4_conf_all_send_redirects/policy/stig/shared.yml b/linux_os/guide/system/network/network-kernel/network_host_parameters/sysctl_net_ipv4_conf_all_send_redirects/policy/stig/shared.yml index cab7b5a7bb9c..423965ee0fa4 100644 --- a/linux_os/guide/system/network/network-kernel/network_host_parameters/sysctl_net_ipv4_conf_all_send_redirects/policy/stig/shared.yml +++ b/linux_os/guide/system/network/network-kernel/network_host_parameters/sysctl_net_ipv4_conf_all_send_redirects/policy/stig/shared.yml @@ -2,10 +2,7 @@ srg_requirement: |- {{{ full_name }}} must not send Internet Control Message Protocol (ICMP) redirects. vuldiscussion: |- - ICMP redirect messages are used by routers to inform hosts that a more - direct route exists for a particular destination. These messages contain information - from the system's route table possibly revealing portions of the network topology. - + ICMP redirect messages are used by routers to inform hosts that a more direct route exists for a particular destination. These messages contain information from the system's route table possibly revealing portions of the network topology. The ability to send ICMP redirects is only appropriate for systems acting as routers. @@ -39,7 +36,3 @@ fixtext: |- $ sudo sysctl --system -vuln_discussion: |- - ICMP redirect messages are used by routers to inform hosts that a more direct route exists for a particular destination. These messages contain information from the system's route table possibly revealing portions of the network topology. - - The ability to send ICMP redirects is only appropriate for systems acting as routers. diff --git a/linux_os/guide/system/network/network-kernel/network_host_parameters/sysctl_net_ipv4_conf_default_send_redirects/policy/stig/shared.yml b/linux_os/guide/system/network/network-kernel/network_host_parameters/sysctl_net_ipv4_conf_default_send_redirects/policy/stig/shared.yml index fceba9e3c62f..d32a06611931 100644 --- a/linux_os/guide/system/network/network-kernel/network_host_parameters/sysctl_net_ipv4_conf_default_send_redirects/policy/stig/shared.yml +++ b/linux_os/guide/system/network/network-kernel/network_host_parameters/sysctl_net_ipv4_conf_default_send_redirects/policy/stig/shared.yml @@ -2,10 +2,7 @@ srg_requirement: |- {{{ full_name }}} must not allow interfaces to perform Internet Control Message Protocol (ICMP) redirects by default. vuldiscussion: |- - ICMP redirect messages are used by routers to inform hosts that a more - direct route exists for a particular destination. These messages contain information - from the system's route table possibly revealing portions of the network topology. - + ICMP redirect messages are used by routers to inform hosts that a more direct route exists for a particular destination. These messages contain information from the system's route table possibly revealing portions of the network topology. The ability to send ICMP redirects is only appropriate for systems acting as routers. @@ -39,7 +36,3 @@ fixtext: |- $ sudo sysctl --system -vuln_discussion: |- - ICMP redirect messages are used by routers to inform hosts that a more direct route exists for a particular destination. These messages contain information from the system's route table possibly revealing portions of the network topology. - - The ability to send ICMP redirects is only appropriate for systems acting as routers. diff --git a/linux_os/guide/system/network/network-uncommon/kernel_module_atm_disabled/policy/stig/shared.yml b/linux_os/guide/system/network/network-uncommon/kernel_module_atm_disabled/policy/stig/shared.yml index cc50e9ba2fbd..d407cd44f2e9 100644 --- a/linux_os/guide/system/network/network-uncommon/kernel_module_atm_disabled/policy/stig/shared.yml +++ b/linux_os/guide/system/network/network-uncommon/kernel_module_atm_disabled/policy/stig/shared.yml @@ -2,8 +2,7 @@ srg_requirement: |- {{{ full_name }}} must be configured to disable the Asynchronous Transfer Mode kernel module. vuldiscussion: |- - Disabling ATM protects the system against exploitation of any - flaws in its implementation. + Disabling Asynchronous Transfer Mode (ATM) protects the system against exploitation of any flaws in its implementation. checktext: |- Verify that {{{ full_name }}} disables the ability to load the ATM kernel module with the following command: @@ -20,5 +19,3 @@ fixtext: |- install atm /bin/false blacklist atm -vuln_discussion: |- - Disabling Asynchronous Transfer Mode (ATM) protects the system against exploitation of any flaws in its implementation. diff --git a/linux_os/guide/system/network/network-uncommon/kernel_module_can_disabled/policy/stig/shared.yml b/linux_os/guide/system/network/network-uncommon/kernel_module_can_disabled/policy/stig/shared.yml index 03f52774777a..e12c1adc05f6 100644 --- a/linux_os/guide/system/network/network-uncommon/kernel_module_can_disabled/policy/stig/shared.yml +++ b/linux_os/guide/system/network/network-uncommon/kernel_module_can_disabled/policy/stig/shared.yml @@ -19,5 +19,3 @@ fixtext: |- install can /bin/false blacklist can -vuln_discussion: |- - Disabling Controller Area Network (CAN) protects the system against exploitation of any flaws in its implementation. diff --git a/linux_os/guide/system/network/network-uncommon/kernel_module_firewire-core_disabled/policy/stig/shared.yml b/linux_os/guide/system/network/network-uncommon/kernel_module_firewire-core_disabled/policy/stig/shared.yml index 1ff94a457213..ff07a8e52c47 100644 --- a/linux_os/guide/system/network/network-uncommon/kernel_module_firewire-core_disabled/policy/stig/shared.yml +++ b/linux_os/guide/system/network/network-uncommon/kernel_module_firewire-core_disabled/policy/stig/shared.yml @@ -16,5 +16,3 @@ checktext: |- If the command does not return any output, or the line is commented out, and use of firewire-core is not documented with the information system security officer (ISSO) as an operational requirement, this is a finding. -vuln_discussion: |- - Disabling firewire protects the system against exploitation of any flaws in its implementation. diff --git a/linux_os/guide/system/network/network-uncommon/kernel_module_sctp_disabled/policy/stig/shared.yml b/linux_os/guide/system/network/network-uncommon/kernel_module_sctp_disabled/policy/stig/shared.yml index b8e3eaedff3c..51af49a27130 100644 --- a/linux_os/guide/system/network/network-uncommon/kernel_module_sctp_disabled/policy/stig/shared.yml +++ b/linux_os/guide/system/network/network-uncommon/kernel_module_sctp_disabled/policy/stig/shared.yml @@ -23,9 +23,3 @@ checktext: |- If the command does not return any output, or the line is commented out, and use of sctp is not documented with the information system security officer (ISSO) as an operational requirement, this is a finding. -vuln_discussion: |- - 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. diff --git a/linux_os/guide/system/network/network-uncommon/kernel_module_tipc_disabled/policy/stig/shared.yml b/linux_os/guide/system/network/network-uncommon/kernel_module_tipc_disabled/policy/stig/shared.yml index 82257f05c29f..564fb63948c4 100644 --- a/linux_os/guide/system/network/network-uncommon/kernel_module_tipc_disabled/policy/stig/shared.yml +++ b/linux_os/guide/system/network/network-uncommon/kernel_module_tipc_disabled/policy/stig/shared.yml @@ -23,9 +23,3 @@ fixtext: |- install tipc /bin/false blacklist tipc -vuln_discussion: |- - 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) is a protocol that is specially designed for intra-cluster communication. It can be configured to transmit messages either on UDP or directly across Ethernet. Message delivery is sequence guaranteed, loss free and flow controlled. Disabling TIPC protects the system against exploitation of any flaws in its implementation. diff --git a/linux_os/guide/system/network/network-wireless/wireless_software/kernel_module_bluetooth_disabled/policy/stig/shared.yml b/linux_os/guide/system/network/network-wireless/wireless_software/kernel_module_bluetooth_disabled/policy/stig/shared.yml index e6d082083231..cdbda187c985 100644 --- a/linux_os/guide/system/network/network-wireless/wireless_software/kernel_module_bluetooth_disabled/policy/stig/shared.yml +++ b/linux_os/guide/system/network/network-wireless/wireless_software/kernel_module_bluetooth_disabled/policy/stig/shared.yml @@ -2,7 +2,7 @@ srg_requirement: |- {{{ full_name }}} Bluetooth must be disabled. vuldiscussion: |- - This requirement applies to wireless peripheral technologies (e.g., wireless mice, keyboards, displays, etc.) used with {{{ full_name }}} systems. Wireless peripherals (e.g., Wi-Fi/Bluetooth/IR Keyboards, Mice, and Pointing Devices and Near Field Communications [NFC]) present a unique challenge by creating an open, unsecured port on a computer. Wireless peripherals must meet DoD requirements for wireless data transmission and be approved for use by the Authorizing Official (AO). Even though some wireless peripherals, such as mice and pointing devices, do not ordinarily carry information that need to be protected, modification of communications with these wireless peripherals may be used to compromise the {{{ full_name }}} operating system. + This requirement applies to wireless peripheral technologies (e.g., wireless mice, keyboards, displays, etc.) used with {{{ full_name }}} systems. Wireless peripherals (e.g., Wi-Fi/Bluetooth/IR keyboards, mice and pointing devices, and near field communications [NFC]) present a unique challenge by creating an open, unsecured port on a computer. Wireless peripherals must meet DOD requirements for wireless data transmission and be approved for use by the Authorizing Official (AO). Even though some wireless peripherals, such as mice and pointing devices, do not ordinarily carry information that need to be protected, modification of communications with these wireless peripherals may be used to compromise the {{{ full_name }}} operating system. checktext: |- Verify that {{{ full_name }}} disables the ability to load the Bluetooth kernel module with the following command: @@ -23,5 +23,3 @@ fixtext: |- Reboot the system for the settings to take effect. -vuln_discussion: |- - This requirement applies to wireless peripheral technologies (e.g., wireless mice, keyboards, displays, etc.) used with {{{ full_name }}} systems. Wireless peripherals (e.g., Wi-Fi/Bluetooth/IR keyboards, mice and pointing devices, and near field communications [NFC]) present a unique challenge by creating an open, unsecured port on a computer. Wireless peripherals must meet DOD requirements for wireless data transmission and be approved for use by the Authorizing Official (AO). Even though some wireless peripherals, such as mice and pointing devices, do not ordinarily carry information that need to be protected, modification of communications with these wireless peripherals may be used to compromise the {{{ full_name }}} operating system. diff --git a/linux_os/guide/system/network/network-wireless/wireless_software/wireless_disable_interfaces/policy/stig/shared.yml b/linux_os/guide/system/network/network-wireless/wireless_software/wireless_disable_interfaces/policy/stig/shared.yml index 55ca84c0ed7d..78518313e7e9 100644 --- a/linux_os/guide/system/network/network-wireless/wireless_software/wireless_disable_interfaces/policy/stig/shared.yml +++ b/linux_os/guide/system/network/network-wireless/wireless_software/wireless_disable_interfaces/policy/stig/shared.yml @@ -2,7 +2,7 @@ srg_requirement: |- {{{ full_name }}} wireless network adapters must be disabled unless approved and documented. vuldiscussion: |- - This requirement applies to wireless peripheral technologies (e.g., wireless mice, keyboards, displays, etc.) used with {{{ full_name }}} systems. Wireless peripherals (e.g., Wi-Fi/Bluetooth/IR Keyboards, Mice, and Pointing Devices and Near Field Communications [NFC]) present a unique challenge by creating an open, unsecured port on a computer. Wireless peripherals must meet DoD requirements for wireless data transmission and be approved for use by the Authorizing Official (AO). Even though some wireless peripherals, such as mice and pointing devices, do not ordinarily carry information that need to be protected, modification of communications with these wireless peripherals may be used to compromise the {{{ full_name }}} operating system. + This requirement applies to wireless peripheral technologies (e.g., wireless mice, keyboards, displays, etc.) used with {{{ full_name }}} systems. Wireless peripherals (e.g., Wi-Fi/Bluetooth/IR keyboards, mice and pointing devices, and near field communications [NFC]) present a unique challenge by creating an open, unsecured port on a computer. Wireless peripherals must meet DOD requirements for wireless data transmission and be approved for use by the Authorizing Official (AO). Even though some wireless peripherals, such as mice and pointing devices, do not ordinarily carry information that need to be protected, modification of communications with these wireless peripherals may be used to compromise the {{{ full_name }}} operating system. checktext: |- Verify there are no wireless interfaces configured on the system with the following command: @@ -26,5 +26,3 @@ fixtext: |- $ nmcli radio all off -vuln_discussion: |- - This requirement applies to wireless peripheral technologies (e.g., wireless mice, keyboards, displays, etc.) used with {{{ full_name }}} systems. Wireless peripherals (e.g., Wi-Fi/Bluetooth/IR keyboards, mice and pointing devices, and near field communications [NFC]) present a unique challenge by creating an open, unsecured port on a computer. Wireless peripherals must meet DOD requirements for wireless data transmission and be approved for use by the Authorizing Official (AO). Even though some wireless peripherals, such as mice and pointing devices, do not ordinarily carry information that need to be protected, modification of communications with these wireless peripherals may be used to compromise the {{{ full_name }}} operating system. diff --git a/linux_os/guide/system/network/network_configure_name_resolution/policy/stig/shared.yml b/linux_os/guide/system/network/network_configure_name_resolution/policy/stig/shared.yml index ddf5008b4550..b8772a01e052 100644 --- a/linux_os/guide/system/network/network_configure_name_resolution/policy/stig/shared.yml +++ b/linux_os/guide/system/network/network_configure_name_resolution/policy/stig/shared.yml @@ -2,10 +2,7 @@ srg_requirement: |- {{{ full_name }}} systems using Domain Name Servers (DNS) resolution must have at least two name servers configured. vuldiscussion: |- - To provide availability for name resolution services, multiple redundant - name servers are mandated. A failure in name resolution could lead to the - failure of security functions requiring name resolution, which may include - time synchronization, centralized authentication, and remote system logging. + To provide availability for name resolution services, multiple redundant name servers are mandated. A failure in name resolution could lead to the failure of security functions requiring name resolution, which may include time synchronization, centralized authentication, and remote system logging. checktext: |- Verify the name servers used by the system with the following command: @@ -34,5 +31,3 @@ fixtext: |- Replace [name server 1] and [name server 2] with the IPs of two different DNS resolvers. Replace [connection name] with a valid NetworkManager connection name on the system. Replace ipv4 with ipv6 if IPv6 DNS servers are used. -vuln_discussion: |- - To provide availability for name resolution services, multiple redundant name servers are mandated. A failure in name resolution could lead to the failure of security functions requiring name resolution, which may include time synchronization, centralized authentication, and remote system logging. diff --git a/linux_os/guide/system/network/network_sniffer_disabled/policy/stig/shared.yml b/linux_os/guide/system/network/network_sniffer_disabled/policy/stig/shared.yml index 31b6f4e13ad4..7388ccad8594 100644 --- a/linux_os/guide/system/network/network_sniffer_disabled/policy/stig/shared.yml +++ b/linux_os/guide/system/network/network_sniffer_disabled/policy/stig/shared.yml @@ -2,14 +2,9 @@ srg_requirement: |- {{{ full_name }}} network interfaces must not be in promiscuous mode. vuldiscussion: |- - Network interfaces in promiscuous mode allow for the capture of all network traffic - visible to the system. If unauthorized individuals can access these applications, it - may allow them to collect information such as logon IDs, passwords, and key exchanges - between systems. + Network interfaces in promiscuous mode allow for the capture of all network traffic visible to the system. If unauthorized individuals can access these applications, it may allow them to collect information such as logon IDs, passwords, and key exchanges between systems. - If the system is being used to perform a network troubleshooting function, the use of these - tools must be documented with the Information Systems Security Manager (ISSM) and restricted - to only authorized personnel. + If the system is being used to perform a network troubleshooting function, the use of these tools must be documented with the information systems security officer (ISSO) and restricted to only authorized personnel. checktext: |- Verify network interfaces are not in promiscuous mode with the following command: @@ -25,7 +20,3 @@ fixtext: |- $ sudo ip link set dev <devicename> multicast off promisc off -vuln_discussion: |- - Network interfaces in promiscuous mode allow for the capture of all network traffic visible to the system. If unauthorized individuals can access these applications, it may allow them to collect information such as logon IDs, passwords, and key exchanges between systems. - - If the system is being used to perform a network troubleshooting function, the use of these tools must be documented with the information systems security officer (ISSO) and restricted to only authorized personnel. diff --git a/linux_os/guide/system/permissions/files/dir_perms_world_writable_root_owned/policy/stig/shared.yml b/linux_os/guide/system/permissions/files/dir_perms_world_writable_root_owned/policy/stig/shared.yml index 2f288d5b5623..97ec9f358532 100644 --- a/linux_os/guide/system/permissions/files/dir_perms_world_writable_root_owned/policy/stig/shared.yml +++ b/linux_os/guide/system/permissions/files/dir_perms_world_writable_root_owned/policy/stig/shared.yml @@ -2,7 +2,7 @@ srg_requirement: |- All {{{ full_name }}} world-writable directories must be owned by root, sys, bin, or an application user. vuldiscussion: |- - If a world-writable directory is not owned by root, sys, bin, or an application User Identifier (UID), unauthorized users may be able to modify files created by others. + If a world-writable directory is not owned by root, sys, bin, or an application user identifier (UID), unauthorized users may be able to modify files created by others. The only authorized public directories are those temporary directories supplied with the system or those designed to be temporary file repositories. The setting is normally reserved for directories used by the system and by users for temporary file storage, (e.g., /tmp), and for directories requiring global read/write access. @@ -20,7 +20,3 @@ fixtext: |- $ sudo chown root [Public Directory] -vuln_discussion: |- - If a world-writable directory is not owned by root, sys, bin, or an application user identifier (UID), unauthorized users may be able to modify files created by others. - - The only authorized public directories are those temporary directories supplied with the system or those designed to be temporary file repositories. The setting is normally reserved for directories used by the system and by users for temporary file storage, (e.g., /tmp), and for directories requiring global read/write access. diff --git a/linux_os/guide/system/permissions/files/dir_perms_world_writable_sticky_bits/policy/stig/shared.yml b/linux_os/guide/system/permissions/files/dir_perms_world_writable_sticky_bits/policy/stig/shared.yml index 834e77b5ba1c..a4ee6d171d4f 100644 --- a/linux_os/guide/system/permissions/files/dir_perms_world_writable_sticky_bits/policy/stig/shared.yml +++ b/linux_os/guide/system/permissions/files/dir_perms_world_writable_sticky_bits/policy/stig/shared.yml @@ -4,7 +4,7 @@ srg_requirement: |- vuldiscussion: |- Preventing unauthorized information transfers mitigates the risk of information, including encrypted representations of information, produced by the actions of prior users/roles (or the actions of processes acting on behalf of prior users/roles) from being available to any current users/roles (or current processes) that obtain access to shared system resources (e.g., registers, main memory, hard disks) after those resources have been released back to information systems. The control of information in shared resources is also commonly referred to as object reuse and residual information protection. - This requirement generally applies to the design of an information technology product, but it can also apply to the configuration of particular information system components that are, or use, such products. This can be verified by acceptance/validation processes in DoD or other government agencies. + This requirement generally applies to the design of an information technology product, but it can also apply to the configuration of particular information system components that are, or use, such products. This can be verified by acceptance/validation processes in DOD or other government agencies. checktext: |- Verify that all world-writable directories have the sticky bit set. @@ -24,7 +24,3 @@ fixtext: |- $ chmod a+t [World-Writable Directory] -vuln_discussion: |- - Preventing unauthorized information transfers mitigates the risk of information, including encrypted representations of information, produced by the actions of prior users/roles (or the actions of processes acting on behalf of prior users/roles) from being available to any current users/roles (or current processes) that obtain access to shared system resources (e.g., registers, main memory, hard disks) after those resources have been released back to information systems. The control of information in shared resources is also commonly referred to as object reuse and residual information protection. - - This requirement generally applies to the design of an information technology product, but it can also apply to the configuration of particular information system components that are, or use, such products. This can be verified by acceptance/validation processes in DOD or other government agencies. diff --git a/linux_os/guide/system/permissions/files/file_permissions_etc_audit_auditd/policy/stig/shared.yml b/linux_os/guide/system/permissions/files/file_permissions_etc_audit_auditd/policy/stig/shared.yml index 6663baf6c00b..e7cbc58e9d37 100644 --- a/linux_os/guide/system/permissions/files/file_permissions_etc_audit_auditd/policy/stig/shared.yml +++ b/linux_os/guide/system/permissions/files/file_permissions_etc_audit_auditd/policy/stig/shared.yml @@ -2,12 +2,7 @@ srg_requirement: |- {{{ full_name }}} /etc/audit/auditd.conf file must have 0640 or less permissive to prevent unauthorized access. vuldiscussion: |- - Without the capability to restrict the roles and individuals that can select which events - are audited, unauthorized personnel may be able to prevent the auditing of critical - events. Misconfigured audits may degrade the system's performance by overwhelming - the audit log. Misconfigured audits may also make it more difficult to establish, - correlate, and investigate the events relating to an incident or identify - those responsible for one. + Without the capability to restrict the roles and individuals that can select which events are audited, unauthorized personnel may be able to prevent the auditing of critical events. Misconfigured audits may degrade the system's performance by overwhelming the audit log. Misconfigured audits may also make it more difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. checktext: |- Verify the mode of /etc/audit/auditd.conf with the command: @@ -23,5 +18,3 @@ fixtext: |- $ sudo chmod 0640 /etc/audit/auditd.conf -vuln_discussion: |- - Without the capability to restrict the roles and individuals that can select which events are audited, unauthorized personnel may be able to prevent the auditing of critical events. Misconfigured audits may degrade the system's performance by overwhelming the audit log. Misconfigured audits may also make it more difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. diff --git a/linux_os/guide/system/permissions/files/file_permissions_etc_audit_rulesd/policy/stig/shared.yml b/linux_os/guide/system/permissions/files/file_permissions_etc_audit_rulesd/policy/stig/shared.yml index f7767350732f..46a185eeb8e4 100644 --- a/linux_os/guide/system/permissions/files/file_permissions_etc_audit_rulesd/policy/stig/shared.yml +++ b/linux_os/guide/system/permissions/files/file_permissions_etc_audit_rulesd/policy/stig/shared.yml @@ -17,5 +17,3 @@ checktext: |- If the files in the "/etc/audit/rules.d/" directory or the "/etc/audit/auditd.conf" file have a mode more permissive than "0640", this is a finding. -vuln_discussion: |- - Without the capability to restrict the roles and individuals that can select which events are audited, unauthorized personnel may be able to prevent the auditing of critical events. Misconfigured audits may degrade the system's performance by overwhelming the audit log. Misconfigured audits may also make it more difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. diff --git a/linux_os/guide/system/permissions/files/file_permissions_ungroupowned/policy/stig/shared.yml b/linux_os/guide/system/permissions/files/file_permissions_ungroupowned/policy/stig/shared.yml index 7c2945e7a665..4904051a9451 100644 --- a/linux_os/guide/system/permissions/files/file_permissions_ungroupowned/policy/stig/shared.yml +++ b/linux_os/guide/system/permissions/files/file_permissions_ungroupowned/policy/stig/shared.yml @@ -16,5 +16,3 @@ fixtext: |- $ sudo chgrp <group> <file> -vuln_discussion: |- - Files without a valid group owner may be unintentionally inherited if a group is assigned the same Group Identifier (GID) as the GID of the files without a valid group owner. diff --git a/linux_os/guide/system/permissions/files/no_files_unowned_by_user/policy/stig/shared.yml b/linux_os/guide/system/permissions/files/no_files_unowned_by_user/policy/stig/shared.yml index 2802d959c117..45e5b4eef3b2 100644 --- a/linux_os/guide/system/permissions/files/no_files_unowned_by_user/policy/stig/shared.yml +++ b/linux_os/guide/system/permissions/files/no_files_unowned_by_user/policy/stig/shared.yml @@ -2,7 +2,7 @@ srg_requirement: |- All {{{ full_name }}} local files and directories must have a valid owner. vuldiscussion: |- - Unowned files and directories may be unintentionally inherited if a user is assigned the same User Identifier "UID" as the UID of the un-owned files. + Unowned files and directories may be unintentionally inherited if a user is assigned the same user identifier "UID" as the UID of the unowned files. checktext: |- Verify all local files and directories on {{{ full_name }}} have a valid owner with the following command: @@ -16,5 +16,3 @@ fixtext: |- $ sudo chown <user> <file> -vuln_discussion: |- - Unowned files and directories may be unintentionally inherited if a user is assigned the same user identifier "UID" as the UID of the unowned files. diff --git a/linux_os/guide/system/permissions/files/permissions_important_account_files/file_groupowner_backup_etc_group/policy/stig/shared.yml b/linux_os/guide/system/permissions/files/permissions_important_account_files/file_groupowner_backup_etc_group/policy/stig/shared.yml index 98dae6d11e69..dc3b6219ef36 100644 --- a/linux_os/guide/system/permissions/files/permissions_important_account_files/file_groupowner_backup_etc_group/policy/stig/shared.yml +++ b/linux_os/guide/system/permissions/files/permissions_important_account_files/file_groupowner_backup_etc_group/policy/stig/shared.yml @@ -2,9 +2,7 @@ srg_requirement: |- {{{ full_name }}} /etc/group- file must be group-owned by root. vuldiscussion: |- - The "/etc/group-" file is a backup file of "/etc/group", and as such, - it contains information regarding groups that are configured on the system. - Protection of this file is important for system security. + The "/etc/group-" file is a backup file of "/etc/group", and as such, contains information regarding groups that are configured on the system. Protection of this file is important for system security. checktext: |- Verify the group ownership of the "/etc/group-" file with the following command: @@ -20,5 +18,3 @@ fixtext: |- $ sudo chgrp root /etc/group- -vuln_discussion: |- - The "/etc/group-" file is a backup file of "/etc/group", and as such, contains information regarding groups that are configured on the system. Protection of this file is important for system security. diff --git a/linux_os/guide/system/permissions/files/permissions_important_account_files/file_groupowner_backup_etc_gshadow/policy/stig/shared.yml b/linux_os/guide/system/permissions/files/permissions_important_account_files/file_groupowner_backup_etc_gshadow/policy/stig/shared.yml index f826de99d55e..6fcd40ccffc8 100644 --- a/linux_os/guide/system/permissions/files/permissions_important_account_files/file_groupowner_backup_etc_gshadow/policy/stig/shared.yml +++ b/linux_os/guide/system/permissions/files/permissions_important_account_files/file_groupowner_backup_etc_gshadow/policy/stig/shared.yml @@ -2,8 +2,7 @@ srg_requirement: |- {{{ full_name }}} /etc/gshadow- file must be group-owned by root. vuldiscussion: |- - The "/etc/gshadow-" file is a backup of "/etc/gshadow", and as such, - it contains group password hashes. Protection of this file is critical for system security. + The "/etc/gshadow-" file is a backup of "/etc/gshadow", and as such, contains group password hashes. Protection of this file is critical for system security. checktext: |- Verify the group ownership of the "/etc/gshadow-" file with the following command: @@ -19,5 +18,3 @@ fixtext: |- $ sudo chgrp root /etc/gshadow- -vuln_discussion: |- - The "/etc/gshadow-" file is a backup of "/etc/gshadow", and as such, contains group password hashes. Protection of this file is critical for system security. diff --git a/linux_os/guide/system/permissions/files/permissions_important_account_files/file_groupowner_backup_etc_passwd/policy/stig/shared.yml b/linux_os/guide/system/permissions/files/permissions_important_account_files/file_groupowner_backup_etc_passwd/policy/stig/shared.yml index 40eb434f1b37..a5f3aaa7a81a 100644 --- a/linux_os/guide/system/permissions/files/permissions_important_account_files/file_groupowner_backup_etc_passwd/policy/stig/shared.yml +++ b/linux_os/guide/system/permissions/files/permissions_important_account_files/file_groupowner_backup_etc_passwd/policy/stig/shared.yml @@ -2,9 +2,7 @@ srg_requirement: |- {{{ full_name }}} /etc/passwd- file must be group-owned by root. vuldiscussion: |- - The "/etc/passwd-" file is a backup file of "/etc/passwd", and as such, - it contains information about the users that are configured on the system. - Protection of this file is critical for system security. + The "/etc/passwd-" file is a backup file of "/etc/passwd", and as such, contains information about the users that are configured on the system. Protection of this file is critical for system security. checktext: |- Verify the group ownership of the "/etc/passwd-" file with the following command: @@ -20,5 +18,3 @@ fixtext: |- $ sudo chgrp root /etc/passwd- -vuln_discussion: |- - The "/etc/passwd-" file is a backup file of "/etc/passwd", and as such, contains information about the users that are configured on the system. Protection of this file is critical for system security. diff --git a/linux_os/guide/system/permissions/files/permissions_important_account_files/file_groupowner_backup_etc_shadow/policy/stig/shared.yml b/linux_os/guide/system/permissions/files/permissions_important_account_files/file_groupowner_backup_etc_shadow/policy/stig/shared.yml index 75aea2d2eb35..e3cb359492a4 100644 --- a/linux_os/guide/system/permissions/files/permissions_important_account_files/file_groupowner_backup_etc_shadow/policy/stig/shared.yml +++ b/linux_os/guide/system/permissions/files/permissions_important_account_files/file_groupowner_backup_etc_shadow/policy/stig/shared.yml @@ -2,9 +2,7 @@ srg_requirement: |- {{{ full_name }}} /etc/shadow- file must be group-owned by root. vuldiscussion: |- - The "/etc/shadow-" file is a backup file of "/etc/shadow", and as such, - it contains the list of local system accounts and password hashes. - Protection of this file is critical for system security. + The "/etc/shadow-" file is a backup file of "/etc/shadow", and as such, contains the list of local system accounts and password hashes. Protection of this file is critical for system security. checktext: |- Verify the group ownership of the "/etc/shadow-" file with the following command: @@ -20,5 +18,3 @@ fixtext: |- $ sudo chgrp root /etc/shadow- -vuln_discussion: |- - The "/etc/shadow-" file is a backup file of "/etc/shadow", and as such, contains the list of local system accounts and password hashes. Protection of this file is critical for system security. diff --git a/linux_os/guide/system/permissions/files/permissions_important_account_files/file_groupowner_etc_group/policy/stig/shared.yml b/linux_os/guide/system/permissions/files/permissions_important_account_files/file_groupowner_etc_group/policy/stig/shared.yml index 4712d52fbb6c..2738822f7112 100644 --- a/linux_os/guide/system/permissions/files/permissions_important_account_files/file_groupowner_etc_group/policy/stig/shared.yml +++ b/linux_os/guide/system/permissions/files/permissions_important_account_files/file_groupowner_etc_group/policy/stig/shared.yml @@ -2,8 +2,7 @@ srg_requirement: |- {{{ full_name }}} /etc/group file must be group-owned by root. vuldiscussion: |- - The "/etc/group" file contains information regarding groups that are configured - on the system. Protection of this file is important for system security. + The "/etc/group" file contains information regarding groups that are configured on the system. Protection of this file is important for system security. checktext: |- Verify the group ownership of the "/etc/group" file with the following command: @@ -19,5 +18,3 @@ fixtext: |- $ sudo chgrp root /etc/group -vuln_discussion: |- - The "/etc/group" file contains information regarding groups that are configured on the system. Protection of this file is important for system security. diff --git a/linux_os/guide/system/permissions/files/permissions_important_account_files/file_groupowner_etc_gshadow/policy/stig/shared.yml b/linux_os/guide/system/permissions/files/permissions_important_account_files/file_groupowner_etc_gshadow/policy/stig/shared.yml index 8e2ea29c5010..2495429b01eb 100644 --- a/linux_os/guide/system/permissions/files/permissions_important_account_files/file_groupowner_etc_gshadow/policy/stig/shared.yml +++ b/linux_os/guide/system/permissions/files/permissions_important_account_files/file_groupowner_etc_gshadow/policy/stig/shared.yml @@ -2,8 +2,7 @@ srg_requirement: |- {{{ full_name }}} /etc/gshadow file must be group-owned by root. vuldiscussion: |- - The "/etc/gshadow" file contains group password hashes. Protection of this file - is critical for system security. + The "/etc/gshadow" file contains group password hashes. Protection of this file is critical for system security. checktext: |- Verify the group ownership of the "/etc/gshadow" file with the following command: @@ -19,5 +18,3 @@ fixtext: |- $ sudo chgrp root /etc/gshadow -vuln_discussion: |- - The "/etc/gshadow" file contains group password hashes. Protection of this file is critical for system security. diff --git a/linux_os/guide/system/permissions/files/permissions_important_account_files/file_groupowner_etc_passwd/policy/stig/shared.yml b/linux_os/guide/system/permissions/files/permissions_important_account_files/file_groupowner_etc_passwd/policy/stig/shared.yml index c4db0dc89e71..35fb6b4efefb 100644 --- a/linux_os/guide/system/permissions/files/permissions_important_account_files/file_groupowner_etc_passwd/policy/stig/shared.yml +++ b/linux_os/guide/system/permissions/files/permissions_important_account_files/file_groupowner_etc_passwd/policy/stig/shared.yml @@ -2,8 +2,7 @@ srg_requirement: |- {{{ full_name }}} /etc/passwd file must be group-owned by root. vuldiscussion: |- - The "/etc/passwd" file contains information about the users that are configured on - the system. Protection of this file is critical for system security. + The "/etc/passwd" file contains information about the users that are configured on the system. Protection of this file is critical for system security. checktext: |- Verify the group ownership of the "/etc/passwd" file with the following command: @@ -19,5 +18,3 @@ fixtext: |- $ sudo chgrp root /etc/passwd -vuln_discussion: |- - The "/etc/passwd" file contains information about the users that are configured on the system. Protection of this file is critical for system security. diff --git a/linux_os/guide/system/permissions/files/permissions_important_account_files/file_groupowner_etc_shadow/policy/stig/shared.yml b/linux_os/guide/system/permissions/files/permissions_important_account_files/file_groupowner_etc_shadow/policy/stig/shared.yml index e3baf2fdf8fd..ecf5674b82d2 100644 --- a/linux_os/guide/system/permissions/files/permissions_important_account_files/file_groupowner_etc_shadow/policy/stig/shared.yml +++ b/linux_os/guide/system/permissions/files/permissions_important_account_files/file_groupowner_etc_shadow/policy/stig/shared.yml @@ -2,8 +2,7 @@ srg_requirement: |- {{{ full_name }}} /etc/shadow file must be group-owned by root. vuldiscussion: |- - The "/etc/shadow" file stores password hashes. Protection of this file is - critical for system security. + The "/etc/shadow" file stores password hashes. Protection of this file is critical for system security. checktext: |- Verify the group ownership of the "/etc/shadow" file with the following command: @@ -19,5 +18,3 @@ fixtext: |- $ sudo chgrp root /etc/shadow -vuln_discussion: |- - The "/etc/shadow" file stores password hashes. Protection of this file is critical for system security. diff --git a/linux_os/guide/system/permissions/files/permissions_important_account_files/file_owner_backup_etc_group/policy/stig/shared.yml b/linux_os/guide/system/permissions/files/permissions_important_account_files/file_owner_backup_etc_group/policy/stig/shared.yml index 8952f1c0676e..cae7c7dd93b4 100644 --- a/linux_os/guide/system/permissions/files/permissions_important_account_files/file_owner_backup_etc_group/policy/stig/shared.yml +++ b/linux_os/guide/system/permissions/files/permissions_important_account_files/file_owner_backup_etc_group/policy/stig/shared.yml @@ -2,9 +2,7 @@ srg_requirement: |- {{{ full_name }}} /etc/group- file must be owned by root. vuldiscussion: |- - The "/etc/group-" file is a backup file of "/etc/group", and as such, - it contains information regarding groups that are configured on the system. - Protection of this file is important for system security. + The "/etc/group-" file is a backup file of "/etc/group", and as such, contains information regarding groups that are configured on the system. Protection of this file is important for system security. checktext: |- Verify the ownership of the "/etc/group-" file with the following command: @@ -20,5 +18,3 @@ fixtext: |- $ sudo chown root /etc/group- -vuln_discussion: |- - The "/etc/group-" file is a backup file of "/etc/group", and as such, contains information regarding groups that are configured on the system. Protection of this file is important for system security. diff --git a/linux_os/guide/system/permissions/files/permissions_important_account_files/file_owner_backup_etc_gshadow/policy/stig/shared.yml b/linux_os/guide/system/permissions/files/permissions_important_account_files/file_owner_backup_etc_gshadow/policy/stig/shared.yml index fb8e1d133106..c9a6e632ea7a 100644 --- a/linux_os/guide/system/permissions/files/permissions_important_account_files/file_owner_backup_etc_gshadow/policy/stig/shared.yml +++ b/linux_os/guide/system/permissions/files/permissions_important_account_files/file_owner_backup_etc_gshadow/policy/stig/shared.yml @@ -2,8 +2,7 @@ srg_requirement: |- {{{ full_name }}} /etc/gshadow- file must be owned by root. vuldiscussion: |- - The "/etc/gshadow-" file is a backup of "/etc/gshadow", and as such, - it contains group password hashes. Protection of this file is critical for system security. + The "/etc/gshadow-" file is a backup of "/etc/gshadow", and as such, contains group password hashes. Protection of this file is critical for system security. checktext: |- Verify the ownership of the "/etc/gshadow-" file with the following command: @@ -19,5 +18,3 @@ fixtext: |- $ sudo chown root /etc/gshadow- -vuln_discussion: |- - The "/etc/gshadow-" file is a backup of "/etc/gshadow", and as such, contains group password hashes. Protection of this file is critical for system security. diff --git a/linux_os/guide/system/permissions/files/permissions_important_account_files/file_owner_backup_etc_passwd/policy/stig/shared.yml b/linux_os/guide/system/permissions/files/permissions_important_account_files/file_owner_backup_etc_passwd/policy/stig/shared.yml index 84d48c8895aa..1584c1d32db4 100644 --- a/linux_os/guide/system/permissions/files/permissions_important_account_files/file_owner_backup_etc_passwd/policy/stig/shared.yml +++ b/linux_os/guide/system/permissions/files/permissions_important_account_files/file_owner_backup_etc_passwd/policy/stig/shared.yml @@ -2,9 +2,7 @@ srg_requirement: |- {{{ full_name }}} /etc/passwd- file must be owned by root. vuldiscussion: |- - The "/etc/passwd-" file is a backup file of "/etc/passwd", and as such, - it contains information about the users that are configured on the system. - Protection of this file is critical for system security. + The "/etc/passwd-" file is a backup file of "/etc/passwd", and as such, contains information about the users that are configured on the system. Protection of this file is critical for system security. checktext: |- Verify the ownership of the "/etc/passwd-" file with the following command: @@ -20,5 +18,3 @@ fixtext: |- $ sudo chown root /etc/passwd- -vuln_discussion: |- - The "/etc/passwd-" file is a backup file of "/etc/passwd", and as such, contains information about the users that are configured on the system. Protection of this file is critical for system security. diff --git a/linux_os/guide/system/permissions/files/permissions_important_account_files/file_owner_backup_etc_shadow/policy/stig/shared.yml b/linux_os/guide/system/permissions/files/permissions_important_account_files/file_owner_backup_etc_shadow/policy/stig/shared.yml index 9097b699e2dc..5429d4e9bc76 100644 --- a/linux_os/guide/system/permissions/files/permissions_important_account_files/file_owner_backup_etc_shadow/policy/stig/shared.yml +++ b/linux_os/guide/system/permissions/files/permissions_important_account_files/file_owner_backup_etc_shadow/policy/stig/shared.yml @@ -2,9 +2,7 @@ srg_requirement: |- {{{ full_name }}} /etc/shadow- file must be owned by root. vuldiscussion: |- - The "/etc/shadow-" file is a backup file of "/etc/shadow", and as such, - it contains the list of local system accounts and password hashes. - Protection of this file is critical for system security. + The "/etc/shadow-" file is a backup file of "/etc/shadow", and as such, contains the list of local system accounts and password hashes. Protection of this file is critical for system security. checktext: |- Verify the ownership of the "/etc/shadow-" file with the following command: @@ -20,5 +18,3 @@ fixtext: |- $ sudo chown root /etc/shadow- -vuln_discussion: |- - The "/etc/shadow-" file is a backup file of "/etc/shadow", and as such, contains the list of local system accounts and password hashes. Protection of this file is critical for system security. diff --git a/linux_os/guide/system/permissions/files/permissions_important_account_files/file_owner_etc_group/policy/stig/shared.yml b/linux_os/guide/system/permissions/files/permissions_important_account_files/file_owner_etc_group/policy/stig/shared.yml index 8d9c602e1183..71421e52ad70 100644 --- a/linux_os/guide/system/permissions/files/permissions_important_account_files/file_owner_etc_group/policy/stig/shared.yml +++ b/linux_os/guide/system/permissions/files/permissions_important_account_files/file_owner_etc_group/policy/stig/shared.yml @@ -2,8 +2,7 @@ srg_requirement: |- {{{ full_name }}} /etc/group file must be owned by root. vuldiscussion: |- - The "/etc/group" file contains information regarding groups that are configured - on the system. Protection of this file is important for system security. + The "/etc/group" file contains information regarding groups that are configured on the system. Protection of this file is important for system security. checktext: |- Verify the ownership of the "/etc/group" file with the following command: @@ -19,5 +18,3 @@ fixtext: |- $ sudo chown root /etc/group -vuln_discussion: |- - The "/etc/group" file contains information regarding groups that are configured on the system. Protection of this file is important for system security. diff --git a/linux_os/guide/system/permissions/files/permissions_important_account_files/file_owner_etc_gshadow/policy/stig/shared.yml b/linux_os/guide/system/permissions/files/permissions_important_account_files/file_owner_etc_gshadow/policy/stig/shared.yml index 0b0d4d5a5f17..47a1edc6e63d 100644 --- a/linux_os/guide/system/permissions/files/permissions_important_account_files/file_owner_etc_gshadow/policy/stig/shared.yml +++ b/linux_os/guide/system/permissions/files/permissions_important_account_files/file_owner_etc_gshadow/policy/stig/shared.yml @@ -2,8 +2,7 @@ srg_requirement: |- {{{ full_name }}} /etc/gshadow file must be owned by root. vuldiscussion: |- - The "/etc/gshadow" file contains group password hashes. Protection of this file - is critical for system security. + The "/etc/gshadow" file contains group password hashes. Protection of this file is critical for system security. checktext: |- Verify the ownership of the "/etc/gshadow" file with the following command: @@ -19,5 +18,3 @@ fixtext: |- $ sudo chown root /etc/gshadow -vuln_discussion: |- - The "/etc/gshadow" file contains group password hashes. Protection of this file is critical for system security. diff --git a/linux_os/guide/system/permissions/files/permissions_important_account_files/file_owner_etc_passwd/policy/stig/shared.yml b/linux_os/guide/system/permissions/files/permissions_important_account_files/file_owner_etc_passwd/policy/stig/shared.yml index 10c8cc44a617..22900161f2b8 100644 --- a/linux_os/guide/system/permissions/files/permissions_important_account_files/file_owner_etc_passwd/policy/stig/shared.yml +++ b/linux_os/guide/system/permissions/files/permissions_important_account_files/file_owner_etc_passwd/policy/stig/shared.yml @@ -2,8 +2,7 @@ srg_requirement: |- {{{ full_name }}} /etc/passwd file must be owned by root. vuldiscussion: |- - The "/etc/passwd" file contains information about the users that are configured on - the system. Protection of this file is critical for system security. + The "/etc/passwd" file contains information about the users that are configured on the system. Protection of this file is critical for system security. checktext: |- Verify the ownership of the "/etc/passwd" file with the following command: @@ -19,5 +18,3 @@ fixtext: |- $ sudo chown root /etc/passwd -vuln_discussion: |- - The "/etc/passwd" file contains information about the users that are configured on the system. Protection of this file is critical for system security. diff --git a/linux_os/guide/system/permissions/files/permissions_important_account_files/file_owner_etc_shadow/policy/stig/shared.yml b/linux_os/guide/system/permissions/files/permissions_important_account_files/file_owner_etc_shadow/policy/stig/shared.yml index 3ff167d7fc23..e31684dbc51e 100644 --- a/linux_os/guide/system/permissions/files/permissions_important_account_files/file_owner_etc_shadow/policy/stig/shared.yml +++ b/linux_os/guide/system/permissions/files/permissions_important_account_files/file_owner_etc_shadow/policy/stig/shared.yml @@ -2,11 +2,7 @@ srg_requirement: |- {{{ full_name }}} /etc/shadow file must be owned by root. vuldiscussion: |- - The "/etc/shadow" file contains the list of local - system accounts and stores password hashes. Protection of this file is - critical for system security. Failure to give ownership of this file - to root provides the designated owner with access to sensitive information - which could weaken the system security posture. + The "/etc/shadow" file contains the list of local system accounts and stores password hashes. Protection of this file is critical for system security. Failure to give ownership of this file to root provides the designated owner with access to sensitive information, which could weaken the system security posture. checktext: |- Verify the ownership of the "/etc/shadow" file with the following command: @@ -22,5 +18,3 @@ fixtext: |- $ sudo chown root /etc/shadow -vuln_discussion: |- - The "/etc/shadow" file contains the list of local system accounts and stores password hashes. Protection of this file is critical for system security. Failure to give ownership of this file to root provides the designated owner with access to sensitive information, which could weaken the system security posture. diff --git a/linux_os/guide/system/permissions/files/permissions_important_account_files/file_permissions_backup_etc_group/policy/stig/shared.yml b/linux_os/guide/system/permissions/files/permissions_important_account_files/file_permissions_backup_etc_group/policy/stig/shared.yml index 7640523a6994..3d7803d00312 100644 --- a/linux_os/guide/system/permissions/files/permissions_important_account_files/file_permissions_backup_etc_group/policy/stig/shared.yml +++ b/linux_os/guide/system/permissions/files/permissions_important_account_files/file_permissions_backup_etc_group/policy/stig/shared.yml @@ -2,9 +2,7 @@ srg_requirement: |- {{{ full_name }}} /etc/group- file must have mode 0644 or less permissive to prevent unauthorized access. vuldiscussion: |- - The "/etc/group-" file is a backup file of "/etc/group", and as such, - it contains information regarding groups that are configured on the system. - Protection of this file is important for system security. + The "/etc/group-" file is a backup file of "/etc/group", and as such, contains information regarding groups that are configured on the system. Protection of this file is important for system security. checktext: |- Verify that the "/etc/group-" file has mode "0644" or less permissive with the following command: @@ -20,5 +18,3 @@ fixtext: |- $ sudo chmod 0644 /etc/group- -vuln_discussion: |- - The "/etc/group-" file is a backup file of "/etc/group", and as such, contains information regarding groups that are configured on the system. Protection of this file is important for system security. diff --git a/linux_os/guide/system/permissions/files/permissions_important_account_files/file_permissions_backup_etc_gshadow/policy/stig/shared.yml b/linux_os/guide/system/permissions/files/permissions_important_account_files/file_permissions_backup_etc_gshadow/policy/stig/shared.yml index acfac5e5d5fc..4432d2eebee0 100644 --- a/linux_os/guide/system/permissions/files/permissions_important_account_files/file_permissions_backup_etc_gshadow/policy/stig/shared.yml +++ b/linux_os/guide/system/permissions/files/permissions_important_account_files/file_permissions_backup_etc_gshadow/policy/stig/shared.yml @@ -2,8 +2,7 @@ srg_requirement: |- {{{ full_name }}} /etc/gshadow- file must have mode 0000 or less permissive to prevent unauthorized access. vuldiscussion: |- - The "/etc/gshadow-" file is a backup of "/etc/gshadow", and as such, - it contains group password hashes. Protection of this file is critical for system security. + The "/etc/gshadow-" file is a backup of "/etc/gshadow", and as such, contains group password hashes. Protection of this file is critical for system security. checktext: |- Verify that the "/etc/gshadow-" file has mode "0000" with the following command: @@ -19,5 +18,3 @@ fixtext: |- $ sudo chmod 0000 /etc/gshadow- -vuln_discussion: |- - The "/etc/gshadow-" file is a backup of "/etc/gshadow", and as such, contains group password hashes. Protection of this file is critical for system security. diff --git a/linux_os/guide/system/permissions/files/permissions_important_account_files/file_permissions_backup_etc_passwd/policy/stig/shared.yml b/linux_os/guide/system/permissions/files/permissions_important_account_files/file_permissions_backup_etc_passwd/policy/stig/shared.yml index c151e4056acc..233602f34646 100644 --- a/linux_os/guide/system/permissions/files/permissions_important_account_files/file_permissions_backup_etc_passwd/policy/stig/shared.yml +++ b/linux_os/guide/system/permissions/files/permissions_important_account_files/file_permissions_backup_etc_passwd/policy/stig/shared.yml @@ -2,9 +2,7 @@ srg_requirement: |- {{{ full_name }}} /etc/passwd- file must have mode 0644 or less permissive to prevent unauthorized access. vuldiscussion: |- - The "/etc/passwd-" file is a backup file of "/etc/passwd", and as such, - it contains information about the users that are configured on the system. - Protection of this file is critical for system security. + The "/etc/passwd-" file is a backup file of "/etc/passwd", and as such, contains information about the users that are configured on the system. Protection of this file is critical for system security. checktext: |- Verify that the "/etc/passwd-" file has mode "0644" or less permissive with the following command: @@ -20,5 +18,3 @@ fixtext: |- $ sudo chmod 0644 /etc/passwd- -vuln_discussion: |- - The "/etc/passwd-" file is a backup file of "/etc/passwd", and as such, contains information about the users that are configured on the system. Protection of this file is critical for system security. diff --git a/linux_os/guide/system/permissions/files/permissions_important_account_files/file_permissions_backup_etc_shadow/policy/stig/shared.yml b/linux_os/guide/system/permissions/files/permissions_important_account_files/file_permissions_backup_etc_shadow/policy/stig/shared.yml index 44e74de08952..7a2e6dafbb9b 100644 --- a/linux_os/guide/system/permissions/files/permissions_important_account_files/file_permissions_backup_etc_shadow/policy/stig/shared.yml +++ b/linux_os/guide/system/permissions/files/permissions_important_account_files/file_permissions_backup_etc_shadow/policy/stig/shared.yml @@ -2,9 +2,7 @@ srg_requirement: |- {{{ full_name }}} /etc/shadow- file must have mode 0000 or less permissive to prevent unauthorized access. vuldiscussion: |- - The "/etc/shadow-" file is a backup file of "/etc/shadow", and as such, - it contains the list of local system accounts and password hashes. - Protection of this file is critical for system security. + The "/etc/shadow-" file is a backup file of "/etc/shadow", and as such, contains the list of local system accounts and password hashes. Protection of this file is critical for system security. checktext: |- Verify that the "/etc/shadow-" file has mode "0000" with the following command: @@ -20,5 +18,3 @@ fixtext: |- $ sudo chmod 0000 /etc/shadow- -vuln_discussion: |- - The "/etc/shadow-" file is a backup file of "/etc/shadow", and as such, contains the list of local system accounts and password hashes. Protection of this file is critical for system security. diff --git a/linux_os/guide/system/permissions/files/permissions_important_account_files/file_permissions_etc_group/policy/stig/shared.yml b/linux_os/guide/system/permissions/files/permissions_important_account_files/file_permissions_etc_group/policy/stig/shared.yml index 4ea98f39daa1..5b2aed72edb6 100644 --- a/linux_os/guide/system/permissions/files/permissions_important_account_files/file_permissions_etc_group/policy/stig/shared.yml +++ b/linux_os/guide/system/permissions/files/permissions_important_account_files/file_permissions_etc_group/policy/stig/shared.yml @@ -2,8 +2,7 @@ srg_requirement: |- {{{ full_name }}} /etc/group file must have mode 0644 or less permissive to prevent unauthorized access. vuldiscussion: |- - The "/etc/group" file contains information regarding groups that are configured - on the system. Protection of this file is important for system security. + The "/etc/group" file contains information regarding groups that are configured on the system. Protection of this file is important for system security. checktext: |- Verify that the "/etc/group" file has mode "0644" or less permissive with the following command: @@ -19,5 +18,3 @@ fixtext: |- $ sudo chmod 0644 /etc/group -vuln_discussion: |- - The "/etc/group" file contains information regarding groups that are configured on the system. Protection of this file is important for system security. diff --git a/linux_os/guide/system/permissions/files/permissions_important_account_files/file_permissions_etc_gshadow/policy/stig/shared.yml b/linux_os/guide/system/permissions/files/permissions_important_account_files/file_permissions_etc_gshadow/policy/stig/shared.yml index dfb454f62ae7..cd8a80930271 100644 --- a/linux_os/guide/system/permissions/files/permissions_important_account_files/file_permissions_etc_gshadow/policy/stig/shared.yml +++ b/linux_os/guide/system/permissions/files/permissions_important_account_files/file_permissions_etc_gshadow/policy/stig/shared.yml @@ -2,8 +2,7 @@ srg_requirement: |- {{{ full_name }}} /etc/gshadow file must have mode 0000 or less permissive to prevent unauthorized access. vuldiscussion: |- - The "/etc/gshadow" file contains group password hashes. Protection of this file - is critical for system security. + The "/etc/gshadow" file contains group password hashes. Protection of this file is critical for system security. checktext: |- Verify that the "/etc/gshadow" file has mode "0000" with the following command: @@ -19,5 +18,3 @@ fixtext: |- $ sudo chmod 0000 /etc/gshadow -vuln_discussion: |- - The "/etc/gshadow" file contains group password hashes. Protection of this file is critical for system security. diff --git a/linux_os/guide/system/permissions/files/permissions_important_account_files/file_permissions_etc_passwd/policy/stig/shared.yml b/linux_os/guide/system/permissions/files/permissions_important_account_files/file_permissions_etc_passwd/policy/stig/shared.yml index bd8d96fbc326..f2f7a6c3a37d 100644 --- a/linux_os/guide/system/permissions/files/permissions_important_account_files/file_permissions_etc_passwd/policy/stig/shared.yml +++ b/linux_os/guide/system/permissions/files/permissions_important_account_files/file_permissions_etc_passwd/policy/stig/shared.yml @@ -2,10 +2,7 @@ srg_requirement: |- {{{ full_name }}} /etc/passwd file must have mode 0644 or less permissive to prevent unauthorized access. vuldiscussion: |- - If the "/etc/passwd" file is writable by a group-owner or the - world the risk of its compromise is increased. The file contains the list of - accounts on the system and associated information, and protection of this file - is critical for system security. + If the "/etc/passwd" file is writable by a group-owner or the world the risk of its compromise is increased. The file contains the list of accounts on the system and associated information, and protection of this file is critical for system security. checktext: |- Verify that the "/etc/passwd" file has mode "0644" or less permissive with the following command: @@ -21,5 +18,3 @@ fixtext: |- $ sudo chmod 0644 /etc/passwd -vuln_discussion: |- - If the "/etc/passwd" file is writable by a group-owner or the world the risk of its compromise is increased. The file contains the list of accounts on the system and associated information, and protection of this file is critical for system security. diff --git a/linux_os/guide/system/permissions/files/permissions_important_account_files/file_permissions_etc_shadow/policy/stig/shared.yml b/linux_os/guide/system/permissions/files/permissions_important_account_files/file_permissions_etc_shadow/policy/stig/shared.yml index 6819fb35d3a8..7b6227d7cff3 100644 --- a/linux_os/guide/system/permissions/files/permissions_important_account_files/file_permissions_etc_shadow/policy/stig/shared.yml +++ b/linux_os/guide/system/permissions/files/permissions_important_account_files/file_permissions_etc_shadow/policy/stig/shared.yml @@ -2,11 +2,7 @@ srg_requirement: |- {{{ full_name }}} /etc/shadow file must have mode 0000 to prevent unauthorized access. vuldiscussion: |- - The "/etc/shadow" file contains the list of local - system accounts and stores password hashes. Protection of this file is - critical for system security. Failure to give ownership of this file - to root provides the designated owner with access to sensitive information - which could weaken the system security posture. + The "/etc/shadow" file contains the list of local system accounts and stores password hashes. Protection of this file is critical for system security. Failure to give ownership of this file to root provides the designated owner with access to sensitive information, which could weaken the system security posture. checktext: |- Verify that the "/etc/shadow" file has mode "0000" with the following command: @@ -22,5 +18,3 @@ fixtext: |- $ sudo chmod 0000 /etc/shadow -vuln_discussion: |- - The "/etc/shadow" file contains the list of local system accounts and stores password hashes. Protection of this file is critical for system security. Failure to give ownership of this file to root provides the designated owner with access to sensitive information, which could weaken the system security posture. diff --git a/linux_os/guide/system/permissions/files/permissions_var_log_dir/file_groupowner_var_log/policy/stig/shared.yml b/linux_os/guide/system/permissions/files/permissions_var_log_dir/file_groupowner_var_log/policy/stig/shared.yml index 4c1e0e2c7ee9..b58aba165ee5 100644 --- a/linux_os/guide/system/permissions/files/permissions_var_log_dir/file_groupowner_var_log/policy/stig/shared.yml +++ b/linux_os/guide/system/permissions/files/permissions_var_log_dir/file_groupowner_var_log/policy/stig/shared.yml @@ -2,7 +2,7 @@ srg_requirement: |- {{{ full_name }}} /var/log directory must be group-owned by root. vuldiscussion: |- - 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 {{{ full_name }}} 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. + 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 {{{ full_name }}} 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. @@ -20,7 +20,3 @@ fixtext: |- $ sudo chgrp root /var/log -vuln_discussion: |- - 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 {{{ full_name }}} 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. diff --git a/linux_os/guide/system/permissions/files/permissions_var_log_dir/file_groupowner_var_log_messages/policy/stig/shared.yml b/linux_os/guide/system/permissions/files/permissions_var_log_dir/file_groupowner_var_log_messages/policy/stig/shared.yml index 8118cb56c103..05cd53f4fedb 100644 --- a/linux_os/guide/system/permissions/files/permissions_var_log_dir/file_groupowner_var_log_messages/policy/stig/shared.yml +++ b/linux_os/guide/system/permissions/files/permissions_var_log_dir/file_groupowner_var_log_messages/policy/stig/shared.yml @@ -2,7 +2,7 @@ srg_requirement: |- {{{ full_name }}} /var/log/messages file must be group-owned by root. vuldiscussion: |- - 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 {{{ full_name }}} 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. + 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 {{{ full_name }}} 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. @@ -20,7 +20,3 @@ fixtext: |- $ sudo chgrp root /var/log/messages -vuln_discussion: |- - 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 {{{ full_name }}} 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. diff --git a/linux_os/guide/system/permissions/files/permissions_var_log_dir/file_owner_var_log/policy/stig/shared.yml b/linux_os/guide/system/permissions/files/permissions_var_log_dir/file_owner_var_log/policy/stig/shared.yml index de106f28e11b..9d94ffd8fea3 100644 --- a/linux_os/guide/system/permissions/files/permissions_var_log_dir/file_owner_var_log/policy/stig/shared.yml +++ b/linux_os/guide/system/permissions/files/permissions_var_log_dir/file_owner_var_log/policy/stig/shared.yml @@ -2,7 +2,7 @@ srg_requirement: |- {{{ full_name }}} /var/log directory must be owned by root. vuldiscussion: |- - 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 {{{ full_name }}} 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. + 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 {{{ full_name }}} 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. @@ -20,7 +20,3 @@ fixtext: |- $ sudo chown root /var/log -vuln_discussion: |- - 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 {{{ full_name }}} 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. diff --git a/linux_os/guide/system/permissions/files/permissions_var_log_dir/file_owner_var_log_messages/policy/stig/shared.yml b/linux_os/guide/system/permissions/files/permissions_var_log_dir/file_owner_var_log_messages/policy/stig/shared.yml index 0bfd051da814..264f5b80b99e 100644 --- a/linux_os/guide/system/permissions/files/permissions_var_log_dir/file_owner_var_log_messages/policy/stig/shared.yml +++ b/linux_os/guide/system/permissions/files/permissions_var_log_dir/file_owner_var_log_messages/policy/stig/shared.yml @@ -2,7 +2,7 @@ srg_requirement: |- {{{ full_name }}} /var/log/messages file must be owned by root. vuldiscussion: |- - 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 {{{ full_name }}} 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. + 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 {{{ full_name }}} 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. @@ -20,7 +20,3 @@ fixtext: |- $ sudo chown root /var/log/messages -vuln_discussion: |- - 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 {{{ full_name }}} 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. diff --git a/linux_os/guide/system/permissions/files/permissions_var_log_dir/file_permissions_var_log/policy/stig/shared.yml b/linux_os/guide/system/permissions/files/permissions_var_log_dir/file_permissions_var_log/policy/stig/shared.yml index f083c4424de7..8a0ef9685b60 100644 --- a/linux_os/guide/system/permissions/files/permissions_var_log_dir/file_permissions_var_log/policy/stig/shared.yml +++ b/linux_os/guide/system/permissions/files/permissions_var_log_dir/file_permissions_var_log/policy/stig/shared.yml @@ -2,7 +2,7 @@ srg_requirement: |- {{{ full_name }}} /var/log directory must have mode 0755 or less permissive. vuldiscussion: |- - 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 {{{ full_name }}} 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. + 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 {{{ full_name }}} 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. @@ -20,7 +20,3 @@ fixtext: |- $ sudo chmod 0755 /var/log -vuln_discussion: |- - 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 {{{ full_name }}} 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. diff --git a/linux_os/guide/system/permissions/files/permissions_var_log_dir/file_permissions_var_log_messages/policy/stig/shared.yml b/linux_os/guide/system/permissions/files/permissions_var_log_dir/file_permissions_var_log_messages/policy/stig/shared.yml index 418bb3cb145e..fb9998201d86 100644 --- a/linux_os/guide/system/permissions/files/permissions_var_log_dir/file_permissions_var_log_messages/policy/stig/shared.yml +++ b/linux_os/guide/system/permissions/files/permissions_var_log_dir/file_permissions_var_log_messages/policy/stig/shared.yml @@ -2,7 +2,7 @@ srg_requirement: |- {{{ full_name }}} /var/log/messages file must have mode 0640 or less permissive. vuldiscussion: |- - 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 {{{ full_name }}} 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. + 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 {{{ full_name }}} 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. @@ -20,7 +20,3 @@ fixtext: |- $ sudo chmod 0640 /var/log/messages -vuln_discussion: |- - 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 {{{ full_name }}} 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. diff --git a/linux_os/guide/system/permissions/files/permissions_within_important_dirs/dir_group_ownership_library_dirs/policy/stig/shared.yml b/linux_os/guide/system/permissions/files/permissions_within_important_dirs/dir_group_ownership_library_dirs/policy/stig/shared.yml index 40981467a851..60750d15409b 100644 --- a/linux_os/guide/system/permissions/files/permissions_within_important_dirs/dir_group_ownership_library_dirs/policy/stig/shared.yml +++ b/linux_os/guide/system/permissions/files/permissions_within_important_dirs/dir_group_ownership_library_dirs/policy/stig/shared.yml @@ -20,7 +20,3 @@ fixtext: |- $ sudo chgrp root [DIRECTORY] -vuln_discussion: |- - If {{{ full_name }}} allowed any user to make changes to software libraries, then those changes might be implemented without undergoing the appropriate testing and approvals that are part of a robust change management process. - - This requirement applies to {{{ full_name }}} with software libraries that are accessible and configurable, as in the case of interpreted languages. Software libraries also include privileged programs that execute with escalated privileges. diff --git a/linux_os/guide/system/permissions/files/permissions_within_important_dirs/dir_ownership_library_dirs/policy/stig/shared.yml b/linux_os/guide/system/permissions/files/permissions_within_important_dirs/dir_ownership_library_dirs/policy/stig/shared.yml index 804583ab9df3..023debf082ee 100644 --- a/linux_os/guide/system/permissions/files/permissions_within_important_dirs/dir_ownership_library_dirs/policy/stig/shared.yml +++ b/linux_os/guide/system/permissions/files/permissions_within_important_dirs/dir_ownership_library_dirs/policy/stig/shared.yml @@ -20,7 +20,3 @@ fixtext: |- $ sudo chown root [DIRECTORY] -vuln_discussion: |- - If {{{ full_name }}} allowed any user to make changes to software libraries, then those changes might be implemented without undergoing the appropriate testing and approvals that are part of a robust change management process. - - This requirement applies to {{{ full_name }}} with software libraries that are accessible and configurable, as in the case of interpreted languages. Software libraries also include privileged programs that execute with escalated privileges. diff --git a/linux_os/guide/system/permissions/files/permissions_within_important_dirs/dir_permissions_library_dirs/policy/stig/shared.yml b/linux_os/guide/system/permissions/files/permissions_within_important_dirs/dir_permissions_library_dirs/policy/stig/shared.yml index 1421ad1ffb23..b24113c28989 100644 --- a/linux_os/guide/system/permissions/files/permissions_within_important_dirs/dir_permissions_library_dirs/policy/stig/shared.yml +++ b/linux_os/guide/system/permissions/files/permissions_within_important_dirs/dir_permissions_library_dirs/policy/stig/shared.yml @@ -2,15 +2,9 @@ srg_requirement: |- {{{ full_name }}} library directories must have mode 755 or less permissive. vuldiscussion: |- - If the operating system were to allow any user to make changes to software libraries, - then those changes might be implemented without undergoing the appropriate testing - and approvals that are part of a robust change management process. + If {{{ full_name }}} allowed any user to make changes to software libraries, then those changes might be implemented without undergoing the appropriate testing and approvals that are part of a robust change management process. - This requirement applies to operating systems with software libraries that are accessible - and configurable, as in the case of interpreted languages. Software libraries also include - privileged programs which execute with escalated privileges. Only qualified and authorized - individuals must be allowed to obtain access to information system components for purposes - of initiating changes, including upgrades and modifications. + This requirement applies to {{{ full_name }}} with software libraries that are accessible and configurable, as in the case of interpreted languages. Software libraries also include privileged programs that execute with escalated privileges. checktext: |- Verify the system-wide shared library directories have mode "755" or less permissive with the following command: @@ -26,7 +20,3 @@ fixtext: |- $ sudo chmod 755 [DIRECTORY] -vuln_discussion: |- - If {{{ full_name }}} allowed any user to make changes to software libraries, then those changes might be implemented without undergoing the appropriate testing and approvals that are part of a robust change management process. - - This requirement applies to {{{ full_name }}} with software libraries that are accessible and configurable, as in the case of interpreted languages. Software libraries also include privileged programs that execute with escalated privileges. diff --git a/linux_os/guide/system/permissions/files/permissions_within_important_dirs/file_groupownership_system_commands_dirs/policy/stig/shared.yml b/linux_os/guide/system/permissions/files/permissions_within_important_dirs/file_groupownership_system_commands_dirs/policy/stig/shared.yml index d13a2c70c202..398232db07d1 100644 --- a/linux_os/guide/system/permissions/files/permissions_within_important_dirs/file_groupownership_system_commands_dirs/policy/stig/shared.yml +++ b/linux_os/guide/system/permissions/files/permissions_within_important_dirs/file_groupownership_system_commands_dirs/policy/stig/shared.yml @@ -20,7 +20,3 @@ fixtext: |- $ sudo chgrp root [FILE] -vuln_discussion: |- - If {{{ full_name }}} allowed any user to make changes to software libraries, then those changes might be implemented without undergoing the appropriate testing and approvals that are part of a robust change management process. - - This requirement applies to {{{ full_name }}} with software libraries that are accessible and configurable, as in the case of interpreted languages. Software libraries also include privileged programs that execute with escalated privileges. diff --git a/linux_os/guide/system/permissions/files/permissions_within_important_dirs/file_ownership_binary_dirs/policy/stig/shared.yml b/linux_os/guide/system/permissions/files/permissions_within_important_dirs/file_ownership_binary_dirs/policy/stig/shared.yml index 6beedaa9e526..45e7cc1ce889 100644 --- a/linux_os/guide/system/permissions/files/permissions_within_important_dirs/file_ownership_binary_dirs/policy/stig/shared.yml +++ b/linux_os/guide/system/permissions/files/permissions_within_important_dirs/file_ownership_binary_dirs/policy/stig/shared.yml @@ -20,7 +20,3 @@ fixtext: |- $ sudo chown root [FILE] -vuln_discussion: |- - If {{{ full_name }}} allowed any user to make changes to software libraries, then those changes might be implemented without undergoing the appropriate testing and approvals that are part of a robust change management process. - - This requirement applies to {{{ full_name }}} with software libraries that are accessible and configurable, as in the case of interpreted languages. Software libraries also include privileged programs that execute with escalated privileges. diff --git a/linux_os/guide/system/permissions/files/permissions_within_important_dirs/file_ownership_library_dirs/policy/stig/shared.yml b/linux_os/guide/system/permissions/files/permissions_within_important_dirs/file_ownership_library_dirs/policy/stig/shared.yml index fdd5f505a9dd..89ff31a29f3c 100644 --- a/linux_os/guide/system/permissions/files/permissions_within_important_dirs/file_ownership_library_dirs/policy/stig/shared.yml +++ b/linux_os/guide/system/permissions/files/permissions_within_important_dirs/file_ownership_library_dirs/policy/stig/shared.yml @@ -20,7 +20,3 @@ fixtext: |- $ sudo chown root [FILE] -vuln_discussion: |- - If {{{ full_name }}} allowed any user to make changes to software libraries, then those changes might be implemented without undergoing the appropriate testing and approvals that are part of a robust change management process. - - This requirement applies to {{{ full_name }}} with software libraries that are accessible and configurable, as in the case of interpreted languages. Software libraries also include privileged programs that execute with escalated privileges. diff --git a/linux_os/guide/system/permissions/files/permissions_within_important_dirs/file_permissions_binary_dirs/policy/stig/shared.yml b/linux_os/guide/system/permissions/files/permissions_within_important_dirs/file_permissions_binary_dirs/policy/stig/shared.yml index 5c6c969dccb9..e8bb5977c634 100644 --- a/linux_os/guide/system/permissions/files/permissions_within_important_dirs/file_permissions_binary_dirs/policy/stig/shared.yml +++ b/linux_os/guide/system/permissions/files/permissions_within_important_dirs/file_permissions_binary_dirs/policy/stig/shared.yml @@ -20,7 +20,3 @@ fixtext: |- $ sudo chmod 755 [FILE] -vuln_discussion: |- - If {{{ full_name }}} allowed any user to make changes to software libraries, then those changes might be implemented without undergoing the appropriate testing and approvals that are part of a robust change management process. - - This requirement applies to {{{ full_name }}} with software libraries that are accessible and configurable, as in the case of interpreted languages. Software libraries also include privileged programs that execute with escalated privileges. diff --git a/linux_os/guide/system/permissions/files/permissions_within_important_dirs/file_permissions_library_dirs/policy/stig/shared.yml b/linux_os/guide/system/permissions/files/permissions_within_important_dirs/file_permissions_library_dirs/policy/stig/shared.yml index 980f56c302c7..5f93ddf108c7 100644 --- a/linux_os/guide/system/permissions/files/permissions_within_important_dirs/file_permissions_library_dirs/policy/stig/shared.yml +++ b/linux_os/guide/system/permissions/files/permissions_within_important_dirs/file_permissions_library_dirs/policy/stig/shared.yml @@ -18,7 +18,3 @@ fixtext: |- $ sudo chmod 755 [FILE] -vuln_discussion: |- - If {{{ full_name }}} allowed any user to make changes to software libraries, then those changes might be implemented without undergoing the appropriate testing and approvals that are part of a robust change management process. - - This requirement applies to {{{ full_name }}} with software libraries that are accessible and configurable, as in the case of interpreted languages. Software libraries also include privileged programs that execute with escalated privileges. diff --git a/linux_os/guide/system/permissions/files/permissions_within_important_dirs/root_permissions_syslibrary_files/policy/stig/shared.yml b/linux_os/guide/system/permissions/files/permissions_within_important_dirs/root_permissions_syslibrary_files/policy/stig/shared.yml index 42ce903c637e..7ddaf957e6bc 100644 --- a/linux_os/guide/system/permissions/files/permissions_within_important_dirs/root_permissions_syslibrary_files/policy/stig/shared.yml +++ b/linux_os/guide/system/permissions/files/permissions_within_important_dirs/root_permissions_syslibrary_files/policy/stig/shared.yml @@ -20,7 +20,3 @@ fixtext: |- $ sudo chgrp root [FILE] -vuln_discussion: |- - If {{{ full_name }}} allowed any user to make changes to software libraries, then those changes might be implemented without undergoing the appropriate testing and approvals that are part of a robust change management process. - - This requirement applies to {{{ full_name }}} with software libraries that are accessible and configurable, as in the case of interpreted languages. Software libraries also include privileged programs that execute with escalated privileges. diff --git a/linux_os/guide/system/permissions/files/sysctl_fs_protected_hardlinks/policy/stig/shared.yml b/linux_os/guide/system/permissions/files/sysctl_fs_protected_hardlinks/policy/stig/shared.yml index 6d7a495d9741..8e67a685e5e6 100644 --- a/linux_os/guide/system/permissions/files/sysctl_fs_protected_hardlinks/policy/stig/shared.yml +++ b/linux_os/guide/system/permissions/files/sysctl_fs_protected_hardlinks/policy/stig/shared.yml @@ -2,7 +2,7 @@ srg_requirement: |- {{{ full_name }}} must enable kernel parameters to enforce discretionary access control on hardlinks. vuldiscussion: |- - 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(). + 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 mitigates vulnerabilities based on insecure file system accessed by privileged programs, avoiding an exploitation vector exploiting unsafe use of open() or creat(). checktext: |- Verify {{{ full_name }}} is configured to enable DAC on hardlinks. @@ -34,5 +34,3 @@ fixtext: |- $ sudo sysctl --system -vuln_discussion: |- - 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 mitigates vulnerabilities based on insecure file system accessed by privileged programs, avoiding an exploitation vector exploiting unsafe use of open() or creat(). diff --git a/linux_os/guide/system/permissions/files/sysctl_fs_protected_symlinks/policy/stig/shared.yml b/linux_os/guide/system/permissions/files/sysctl_fs_protected_symlinks/policy/stig/shared.yml index ddebc39afd1a..4f618090b8cb 100644 --- a/linux_os/guide/system/permissions/files/sysctl_fs_protected_symlinks/policy/stig/shared.yml +++ b/linux_os/guide/system/permissions/files/sysctl_fs_protected_symlinks/policy/stig/shared.yml @@ -2,7 +2,7 @@ srg_requirement: |- {{{ full_name }}} must enable kernel parameters to enforce discretionary access control on symlinks. vuldiscussion: |- - 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(). + 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 user identifier (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(). checktext: |- Verify {{{ full_name }}} is configured to enable DAC on symlinks. @@ -34,5 +34,3 @@ fixtext: |- $ sudo sysctl --system -vuln_discussion: |- - 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 user identifier (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(). diff --git a/linux_os/guide/system/permissions/mounting/kernel_module_cramfs_disabled/policy/stig/shared.yml b/linux_os/guide/system/permissions/mounting/kernel_module_cramfs_disabled/policy/stig/shared.yml index 71a9da97cda9..013918438bf9 100644 --- a/linux_os/guide/system/permissions/mounting/kernel_module_cramfs_disabled/policy/stig/shared.yml +++ b/linux_os/guide/system/permissions/mounting/kernel_module_cramfs_disabled/policy/stig/shared.yml @@ -6,7 +6,7 @@ vuldiscussion: |- 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. + 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. checktext: |- Verify that {{{ full_name }}} disables the ability to load the cramfs kernel module with the following command: @@ -23,9 +23,3 @@ fixtext: |- install cramfs /bin/false blacklist cramfs -vuln_discussion: |- - 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. diff --git a/linux_os/guide/system/permissions/mounting/kernel_module_usb-storage_disabled/policy/stig/shared.yml b/linux_os/guide/system/permissions/mounting/kernel_module_usb-storage_disabled/policy/stig/shared.yml index 2a3c7dbb45c8..dd7b9e7cf1d0 100644 --- a/linux_os/guide/system/permissions/mounting/kernel_module_usb-storage_disabled/policy/stig/shared.yml +++ b/linux_os/guide/system/permissions/mounting/kernel_module_usb-storage_disabled/policy/stig/shared.yml @@ -19,5 +19,3 @@ fixtext: |- install usb-storage /bin/false blacklist usb-storage -vuln_discussion: |- - USB mass storage permits easy introduction of unknown devices, thereby facilitating malicious activity. diff --git a/linux_os/guide/system/permissions/mounting/service_autofs_disabled/policy/stig/shared.yml b/linux_os/guide/system/permissions/mounting/service_autofs_disabled/policy/stig/shared.yml index 4c714ba20aef..25b5fa6d78fd 100644 --- a/linux_os/guide/system/permissions/mounting/service_autofs_disabled/policy/stig/shared.yml +++ b/linux_os/guide/system/permissions/mounting/service_autofs_disabled/policy/stig/shared.yml @@ -2,7 +2,7 @@ srg_requirement: |- {{{ full_name }}} file system automount function must be disabled unless required. vuldiscussion: |- - Without identifying devices, unidentified or unknown devices may be introduced, thereby facilitating malicious activity. + An authentication process resists replay attacks if it is impractical to achieve a successful authentication by recording and replaying a previous authentication message. checktext: |- Verify that {{{ full_name }}} file system automount function has been disabled with the following command: @@ -20,5 +20,3 @@ fixtext: |- $ sudo systemctl mask --now autofs.service -vuln_discussion: |- - An authentication process resists replay attacks if it is impractical to achieve a successful authentication by recording and replaying a previous authentication message. diff --git a/linux_os/guide/system/permissions/partitions/mount_option_boot_efi_nosuid/policy/stig/shared.yml b/linux_os/guide/system/permissions/partitions/mount_option_boot_efi_nosuid/policy/stig/shared.yml index 0b168dfe1498..8c7521782d4e 100644 --- a/linux_os/guide/system/permissions/partitions/mount_option_boot_efi_nosuid/policy/stig/shared.yml +++ b/linux_os/guide/system/permissions/partitions/mount_option_boot_efi_nosuid/policy/stig/shared.yml @@ -2,7 +2,7 @@ srg_requirement: |- {{{ full_name }}} must prevent files with the setuid and setgid bit set from being executed on the /boot/efi directory. vuldiscussion: |- - The "nosuid" mount option causes the system not to execute "setuid" and "setgid" files with owner privileges. This option must be used for mounting any file system not containing approved "setuid" and "setguid" files. Executing files from untrusted file systems increases the opportunity for unprivileged users to attain unauthorized administrative access. + The "nosuid" mount option causes the system not to execute "setuid" and "setgid" files with owner privileges. This option must be used for mounting any file system not containing approved "setuid" and "setguid" files. Executing files from untrusted file systems increases the opportunity for nonprivileged users to attain unauthorized administrative access. checktext: |- Note: For systems that use BIOS, this requirement is Not Applicable. @@ -18,5 +18,3 @@ checktext: |- fixtext: |- Modify "/etc/fstab" to use the "nosuid" option on the "/boot/efi" directory. -vuln_discussion: |- - The "nosuid" mount option causes the system not to execute "setuid" and "setgid" files with owner privileges. This option must be used for mounting any file system not containing approved "setuid" and "setguid" files. Executing files from untrusted file systems increases the opportunity for nonprivileged users to attain unauthorized administrative access. diff --git a/linux_os/guide/system/permissions/partitions/mount_option_boot_nodev/policy/stig/shared.yml b/linux_os/guide/system/permissions/partitions/mount_option_boot_nodev/policy/stig/shared.yml index d01e119e2610..207c7aa0dc30 100644 --- a/linux_os/guide/system/permissions/partitions/mount_option_boot_nodev/policy/stig/shared.yml +++ b/linux_os/guide/system/permissions/partitions/mount_option_boot_nodev/policy/stig/shared.yml @@ -2,8 +2,7 @@ srg_requirement: |- {{{ full_name }}} must mount /boot with the nodev option. vuldiscussion: |- - The only legitimate location for device files is the "/dev" directory - located on the root partition. The only exception to this is chroot jails. + The only legitimate location for device files is the "/dev" directory located on the root partition. The only exception to this is chroot jails. checktext: |- Verify that the "/boot" mount point has the "nodev" option is with the following command: @@ -19,5 +18,3 @@ checktext: |- fixtext: |- Modify "/etc/fstab" to use the "nodev" option on the "/boot" directory. -vuln_discussion: |- - The only legitimate location for device files is the "/dev" directory located on the root partition. The only exception to this is chroot jails. diff --git a/linux_os/guide/system/permissions/partitions/mount_option_boot_nosuid/policy/stig/shared.yml b/linux_os/guide/system/permissions/partitions/mount_option_boot_nosuid/policy/stig/shared.yml index 5f06d6c0165b..d9305805de15 100644 --- a/linux_os/guide/system/permissions/partitions/mount_option_boot_nosuid/policy/stig/shared.yml +++ b/linux_os/guide/system/permissions/partitions/mount_option_boot_nosuid/policy/stig/shared.yml @@ -2,7 +2,7 @@ srg_requirement: |- {{{ full_name }}} must prevent files with the setuid and setgid bit set from being executed on the /boot directory. vuldiscussion: |- - The "nosuid" mount option causes the system not to execute "setuid" and "setgid" files with owner privileges. This option must be used for mounting any file system not containing approved "setuid" and "setguid" files. Executing files from untrusted file systems increases the opportunity for unprivileged users to attain unauthorized administrative access. + The "nosuid" mount option causes the system not to execute "setuid" and "setgid" files with owner privileges. This option must be used for mounting any file system not containing approved "setuid" and "setguid" files. Executing files from untrusted file systems increases the opportunity for nonprivileged users to attain unauthorized administrative access. checktext: |- Note: For systems that use UEFI, this requirement is Not Applicable. @@ -18,5 +18,3 @@ checktext: |- fixtext: |- Modify "/etc/fstab" to use the "nosuid" option on the "/boot" directory. -vuln_discussion: |- - The "nosuid" mount option causes the system not to execute "setuid" and "setgid" files with owner privileges. This option must be used for mounting any file system not containing approved "setuid" and "setguid" files. Executing files from untrusted file systems increases the opportunity for nonprivileged users to attain unauthorized administrative access. diff --git a/linux_os/guide/system/permissions/partitions/mount_option_dev_shm_nodev/policy/stig/shared.yml b/linux_os/guide/system/permissions/partitions/mount_option_dev_shm_nodev/policy/stig/shared.yml index 539b502bd123..72c60a506900 100644 --- a/linux_os/guide/system/permissions/partitions/mount_option_dev_shm_nodev/policy/stig/shared.yml +++ b/linux_os/guide/system/permissions/partitions/mount_option_dev_shm_nodev/policy/stig/shared.yml @@ -2,7 +2,7 @@ srg_requirement: |- {{{ full_name }}} must mount /dev/shm with the nodev option. vuldiscussion: |- - The "nodev" mount option causes the system to not interpret character or block special devices. Executing character or block special devices from untrusted file systems increases the opportunity for unprivileged users to attain unauthorized administrative access. + The "nodev" mount option causes the system to not interpret character or block special devices. Executing character or block special devices from untrusted file systems increases the opportunity for nonprivileged users to attain unauthorized administrative access. The only legitimate location for device files is the "/dev" directory located on the root partition, with the exception of chroot jails if implemented. @@ -18,7 +18,3 @@ checktext: |- fixtext: |- Modify "/etc/fstab" to use the "nodev" option on the "/dev/shm" file system. -vuln_discussion: |- - The "nodev" mount option causes the system to not interpret character or block special devices. Executing character or block special devices from untrusted file systems increases the opportunity for nonprivileged users to attain unauthorized administrative access. - - The only legitimate location for device files is the "/dev" directory located on the root partition, with the exception of chroot jails if implemented. diff --git a/linux_os/guide/system/permissions/partitions/mount_option_dev_shm_noexec/policy/stig/shared.yml b/linux_os/guide/system/permissions/partitions/mount_option_dev_shm_noexec/policy/stig/shared.yml index 329f08a8fd6a..682615aa9017 100644 --- a/linux_os/guide/system/permissions/partitions/mount_option_dev_shm_noexec/policy/stig/shared.yml +++ b/linux_os/guide/system/permissions/partitions/mount_option_dev_shm_noexec/policy/stig/shared.yml @@ -2,7 +2,7 @@ srg_requirement: |- {{{ full_name }}} must mount /dev/shm with the noexec option. vuldiscussion: |- - The "noexec" mount option causes the system to not execute binary files. This option must be used for mounting any file system not containing approved binary files, as they may be incompatible. Executing files from untrusted file systems increases the opportunity for unprivileged users to attain unauthorized administrative access. + The "noexec" mount option causes the system to not execute binary files. This option must be used for mounting any file system not containing approved binary files, as they may be incompatible. Executing files from untrusted file systems increases the opportunity for nonprivileged users to attain unauthorized administrative access. checktext: |- Verify "/dev/shm" is mounted with the "noexec" option with the following command: @@ -16,5 +16,3 @@ checktext: |- fixtext: |- Modify "/etc/fstab" to use the "noexec" option on the "/dev/shm" file system. -vuln_discussion: |- - The "noexec" mount option causes the system to not execute binary files. This option must be used for mounting any file system not containing approved binary files, as they may be incompatible. Executing files from untrusted file systems increases the opportunity for nonprivileged users to attain unauthorized administrative access. diff --git a/linux_os/guide/system/permissions/partitions/mount_option_dev_shm_nosuid/policy/stig/shared.yml b/linux_os/guide/system/permissions/partitions/mount_option_dev_shm_nosuid/policy/stig/shared.yml index d8c145608996..eca3eaf32763 100644 --- a/linux_os/guide/system/permissions/partitions/mount_option_dev_shm_nosuid/policy/stig/shared.yml +++ b/linux_os/guide/system/permissions/partitions/mount_option_dev_shm_nosuid/policy/stig/shared.yml @@ -2,7 +2,7 @@ srg_requirement: |- {{{ full_name }}} must mount /dev/shm with the nosuid option. vuldiscussion: |- - The "nosuid" mount option causes the system to not execute "setuid" and "setgid" files with owner privileges. This option must be used for mounting any file system not containing approved "setuid" and "setguid" files. Executing files from untrusted file systems increases the opportunity for unprivileged users to attain unauthorized administrative access. + The "nosuid" mount option causes the system to not execute "setuid" and "setgid" files with owner privileges. This option must be used for mounting any file system not containing approved "setuid" and "setguid" files. Executing files from untrusted file systems increases the opportunity for nonprivileged users to attain unauthorized administrative access. checktext: |- Verify "/dev/shm" is mounted with the "nosuid" option with the following command: @@ -16,5 +16,3 @@ checktext: |- fixtext: |- Modify "/etc/fstab" to use the "nosuid" option on the "/dev/shm" file system. -vuln_discussion: |- - The "nosuid" mount option causes the system to not execute "setuid" and "setgid" files with owner privileges. This option must be used for mounting any file system not containing approved "setuid" and "setguid" files. Executing files from untrusted file systems increases the opportunity for nonprivileged users to attain unauthorized administrative access. diff --git a/linux_os/guide/system/permissions/partitions/mount_option_home_nodev/policy/stig/shared.yml b/linux_os/guide/system/permissions/partitions/mount_option_home_nodev/policy/stig/shared.yml index 477e9d005b4d..0f1e23e756e6 100644 --- a/linux_os/guide/system/permissions/partitions/mount_option_home_nodev/policy/stig/shared.yml +++ b/linux_os/guide/system/permissions/partitions/mount_option_home_nodev/policy/stig/shared.yml @@ -2,7 +2,7 @@ srg_requirement: |- {{{ full_name }}} must prevent device files from being interpreted on file systems that contain user home directories. vuldiscussion: |- - The "nodev" mount option causes the system to not interpret character or block special devices. Executing character or block special devices from untrusted file systems increases the opportunity for unprivileged users to attain unauthorized administrative access. + The "nodev" mount option causes the system to not interpret character or block special devices. Executing character or block special devices from untrusted file systems increases the opportunity for nonprivileged users to attain unauthorized administrative access. The only legitimate location for device files is the "/dev" directory located on the root partition, with the exception of chroot jails if implemented. @@ -20,7 +20,3 @@ checktext: |- fixtext: |- Modify "/etc/fstab" to use the "nodev" option on the "/home" directory. -vuln_discussion: |- - The "nodev" mount option causes the system to not interpret character or block special devices. Executing character or block special devices from untrusted file systems increases the opportunity for nonprivileged users to attain unauthorized administrative access. - - The only legitimate location for device files is the "/dev" directory located on the root partition, with the exception of chroot jails if implemented. diff --git a/linux_os/guide/system/permissions/partitions/mount_option_home_noexec/policy/stig/shared.yml b/linux_os/guide/system/permissions/partitions/mount_option_home_noexec/policy/stig/shared.yml index 4c7252b53c91..8f2bc30861ca 100644 --- a/linux_os/guide/system/permissions/partitions/mount_option_home_noexec/policy/stig/shared.yml +++ b/linux_os/guide/system/permissions/partitions/mount_option_home_noexec/policy/stig/shared.yml @@ -2,7 +2,7 @@ srg_requirement: |- {{{ full_name }}} must prevent code from being executed on file systems that contain user home directories. vuldiscussion: |- - The "noexec" mount option causes the system to not execute binary files. This option must be used for mounting any file system not containing approved binary files, as they may be incompatible. Executing files from untrusted file systems increases the opportunity for unprivileged users to attain unauthorized administrative access. + The "noexec" mount option causes the system to not execute binary files. This option must be used for mounting any file system not containing approved binary files, as they may be incompatible. Executing files from untrusted file systems increases the opportunity for nonprivileged users to attain unauthorized administrative access. checktext: |- Verify "/home" is mounted with the "noexec" option with the following command: @@ -18,5 +18,3 @@ checktext: |- fixtext: |- Modify "/etc/fstab" to use the "noexec" option on the "/home" directory. -vuln_discussion: |- - The "noexec" mount option causes the system to not execute binary files. This option must be used for mounting any file system not containing approved binary files, as they may be incompatible. Executing files from untrusted file systems increases the opportunity for nonprivileged users to attain unauthorized administrative access. diff --git a/linux_os/guide/system/permissions/partitions/mount_option_home_nosuid/policy/stig/shared.yml b/linux_os/guide/system/permissions/partitions/mount_option_home_nosuid/policy/stig/shared.yml index 12aa43a19898..00147e59e1e7 100644 --- a/linux_os/guide/system/permissions/partitions/mount_option_home_nosuid/policy/stig/shared.yml +++ b/linux_os/guide/system/permissions/partitions/mount_option_home_nosuid/policy/stig/shared.yml @@ -2,7 +2,7 @@ srg_requirement: |- {{{ full_name }}} must prevent files with the setuid and setgid bit set from being executed on file systems that contain user home directories. vuldiscussion: |- - The "nosuid" mount option causes the system to not execute "setuid" and "setgid" files with owner privileges. This option must be used for mounting any file system not containing approved "setuid" and "setguid" files. Executing files from untrusted file systems increases the opportunity for unprivileged users to attain unauthorized administrative access. + The "nosuid" mount option causes the system to not execute "setuid" and "setgid" files with owner privileges. This option must be used for mounting any file system not containing approved "setuid" and "setguid" files. Executing files from untrusted file systems increases the opportunity for nonprivileged users to attain unauthorized administrative access. checktext: |- Verify "/home" is mounted with the "nosuid" option with the following command: @@ -18,5 +18,3 @@ checktext: |- fixtext: |- Modify "/etc/fstab" to use the "nosuid" option on the "/home" directory. -vuln_discussion: |- - The "nosuid" mount option causes the system to not execute "setuid" and "setgid" files with owner privileges. This option must be used for mounting any file system not containing approved "setuid" and "setguid" files. Executing files from untrusted file systems increases the opportunity for nonprivileged users to attain unauthorized administrative access. diff --git a/linux_os/guide/system/permissions/partitions/mount_option_nodev_nonroot_local_partitions/policy/stig/shared.yml b/linux_os/guide/system/permissions/partitions/mount_option_nodev_nonroot_local_partitions/policy/stig/shared.yml index ce5057f70152..faab2553b7ef 100644 --- a/linux_os/guide/system/permissions/partitions/mount_option_nodev_nonroot_local_partitions/policy/stig/shared.yml +++ b/linux_os/guide/system/permissions/partitions/mount_option_nodev_nonroot_local_partitions/policy/stig/shared.yml @@ -2,7 +2,7 @@ srg_requirement: |- {{{ full_name }}} must prevent special devices on non-root local partitions. vuldiscussion: |- - The "nodev" mount option causes the system to not interpret character or block special devices. Executing character or block special devices from untrusted file systems increases the opportunity for unprivileged users to attain unauthorized administrative access. + The "nodev" mount option causes the system to not interpret character or block special devices. Executing character or block special devices from untrusted file systems increases the opportunity for nonprivileged users to attain unauthorized administrative access. The only legitimate location for device files is the "/dev" directory located on the root partition, with the exception of chroot jails if implemented. @@ -16,7 +16,3 @@ checktext: |- fixtext: |- Configure the "/etc/fstab" to use the "nodev" option on all non-root local partitions. -vuln_discussion: |- - The "nodev" mount option causes the system to not interpret character or block special devices. Executing character or block special devices from untrusted file systems increases the opportunity for nonprivileged users to attain unauthorized administrative access. - - The only legitimate location for device files is the "/dev" directory located on the root partition, with the exception of chroot jails if implemented. diff --git a/linux_os/guide/system/permissions/partitions/mount_option_nodev_removable_partitions/policy/stig/shared.yml b/linux_os/guide/system/permissions/partitions/mount_option_nodev_removable_partitions/policy/stig/shared.yml index ae22b79f0871..97eac06913bc 100644 --- a/linux_os/guide/system/permissions/partitions/mount_option_nodev_removable_partitions/policy/stig/shared.yml +++ b/linux_os/guide/system/permissions/partitions/mount_option_nodev_removable_partitions/policy/stig/shared.yml @@ -2,10 +2,7 @@ srg_requirement: |- {{{ full_name }}} must prevent special devices on file systems that are used with removable media. vuldiscussion: |- - The only legitimate location for device files is the "/dev" directory - located on the root partition. An exception to this is chroot jails, and it is - not advised to set "nodev" on partitions which contain their root - filesystems. + The "nodev" mount option causes the system not to interpret character or block special devices. Executing character or blocking special devices from untrusted file systems increases the opportunity for nonprivileged users to attain unauthorized administrative access. checktext: |- Verify file systems that are used for removable media are mounted with the "nodev" option with the following command: @@ -19,5 +16,3 @@ checktext: |- fixtext: |- Configure the "/etc/fstab" to use the "nodev" option on file systems that are associated with removable media. -vuln_discussion: |- - The "nodev" mount option causes the system not to interpret character or block special devices. Executing character or blocking special devices from untrusted file systems increases the opportunity for nonprivileged users to attain unauthorized administrative access. diff --git a/linux_os/guide/system/permissions/partitions/mount_option_noexec_removable_partitions/policy/stig/shared.yml b/linux_os/guide/system/permissions/partitions/mount_option_noexec_removable_partitions/policy/stig/shared.yml index 1d942d84a13c..bde51946fc7c 100644 --- a/linux_os/guide/system/permissions/partitions/mount_option_noexec_removable_partitions/policy/stig/shared.yml +++ b/linux_os/guide/system/permissions/partitions/mount_option_noexec_removable_partitions/policy/stig/shared.yml @@ -2,7 +2,7 @@ srg_requirement: |- {{{ full_name }}} must prevent code from being executed on file systems that are used with removable media. vuldiscussion: |- - The "nosuid" mount option causes the system not to execute "setuid" and "setgid" files with owner privileges. This option must be used for mounting any file system not containing approved "setuid" and "setguid" files. Executing files from untrusted file systems increases the opportunity for unprivileged users to attain unauthorized administrative access. + The "noexec" mount option causes the system not to execute binary files. This option must be used for mounting any file system not containing approved binary files, as they may be incompatible. Executing files from untrusted file systems increases the opportunity for nonprivileged users to attain unauthorized administrative access. checktext: |- Verify file systems that are used for removable media are mounted with the "noexec" option with the following command: @@ -16,5 +16,3 @@ checktext: |- fixtext: |- Configure the "/etc/fstab" to use the "noexec" option on file systems that are associated with removable media. -vuln_discussion: |- - The "noexec" mount option causes the system not to execute binary files. This option must be used for mounting any file system not containing approved binary files, as they may be incompatible. Executing files from untrusted file systems increases the opportunity for nonprivileged users to attain unauthorized administrative access. diff --git a/linux_os/guide/system/permissions/partitions/mount_option_nosuid_removable_partitions/policy/stig/shared.yml b/linux_os/guide/system/permissions/partitions/mount_option_nosuid_removable_partitions/policy/stig/shared.yml index be5e69ad79b1..6f25c7f7ec1d 100644 --- a/linux_os/guide/system/permissions/partitions/mount_option_nosuid_removable_partitions/policy/stig/shared.yml +++ b/linux_os/guide/system/permissions/partitions/mount_option_nosuid_removable_partitions/policy/stig/shared.yml @@ -2,9 +2,7 @@ srg_requirement: |- {{{ full_name }}} must prevent files with the setuid and setgid bit set from being executed on file systems that are used with removable media. vuldiscussion: |- - The presence of SUID and SGID executables should be tightly controlled. Allowing - users to introduce SUID or SGID binaries from partitions mounted off of - removable media would allow them to introduce their own highly-privileged programs. + The "nosuid" mount option causes the system not to execute "setuid" and "setgid" files with owner privileges. This option must be used for mounting any file system not containing approved "setuid" and "setguid" files. Executing files from untrusted file systems increases the opportunity for nonprivileged users to attain unauthorized administrative access. checktext: |- Verify file systems that are used for removable media are mounted with the "nosuid" option with the following command: @@ -18,5 +16,3 @@ checktext: |- fixtext: |- Configure the "/etc/fstab" to use the "nosuid" option on file systems that are associated with removable media. -vuln_discussion: |- - The "nosuid" mount option causes the system not to execute "setuid" and "setgid" files with owner privileges. This option must be used for mounting any file system not containing approved "setuid" and "setguid" files. Executing files from untrusted file systems increases the opportunity for nonprivileged users to attain unauthorized administrative access. diff --git a/linux_os/guide/system/permissions/partitions/mount_option_tmp_nodev/policy/stig/shared.yml b/linux_os/guide/system/permissions/partitions/mount_option_tmp_nodev/policy/stig/shared.yml index 54cb0b397465..387c31596434 100644 --- a/linux_os/guide/system/permissions/partitions/mount_option_tmp_nodev/policy/stig/shared.yml +++ b/linux_os/guide/system/permissions/partitions/mount_option_tmp_nodev/policy/stig/shared.yml @@ -2,7 +2,7 @@ srg_requirement: |- {{{ full_name }}} must mount /tmp with the nodev option. vuldiscussion: |- - The "nodev" mount option causes the system to not interpret character or block special devices. Executing character or block special devices from untrusted file systems increases the opportunity for unprivileged users to attain unauthorized administrative access. + The "nodev" mount option causes the system to not interpret character or block special devices. Executing character or block special devices from untrusted file systems increases the opportunity for nonprivileged users to attain unauthorized administrative access. The only legitimate location for device files is the "/dev" directory located on the root partition, with the exception of chroot jails if implemented. @@ -18,7 +18,3 @@ checktext: |- fixtext: |- Modify "/etc/fstab" to use the "nodev" option on the "/tmp" directory. -vuln_discussion: |- - The "nodev" mount option causes the system to not interpret character or block special devices. Executing character or block special devices from untrusted file systems increases the opportunity for nonprivileged users to attain unauthorized administrative access. - - The only legitimate location for device files is the "/dev" directory located on the root partition, with the exception of chroot jails if implemented. diff --git a/linux_os/guide/system/permissions/partitions/mount_option_tmp_noexec/policy/stig/shared.yml b/linux_os/guide/system/permissions/partitions/mount_option_tmp_noexec/policy/stig/shared.yml index b7ab50d0bd11..5bf5d34b0aa2 100644 --- a/linux_os/guide/system/permissions/partitions/mount_option_tmp_noexec/policy/stig/shared.yml +++ b/linux_os/guide/system/permissions/partitions/mount_option_tmp_noexec/policy/stig/shared.yml @@ -2,7 +2,7 @@ srg_requirement: |- {{{ full_name }}} must mount /tmp with the noexec option. vuldiscussion: |- - The "noexec" mount option causes the system to not execute binary files. This option must be used for mounting any file system not containing approved binary files, as they may be incompatible. Executing files from untrusted file systems increases the opportunity for unprivileged users to attain unauthorized administrative access. + The "noexec" mount option causes the system to not execute binary files. This option must be used for mounting any file system not containing approved binary files, as they may be incompatible. Executing files from untrusted file systems increases the opportunity for nonprivileged users to attain unauthorized administrative access. checktext: |- Verify "/tmp" is mounted with the "noexec" option: @@ -16,5 +16,3 @@ checktext: |- fixtext: |- Modify "/etc/fstab" to use the "noexec" option on the "/tmp" directory. -vuln_discussion: |- - The "noexec" mount option causes the system to not execute binary files. This option must be used for mounting any file system not containing approved binary files, as they may be incompatible. Executing files from untrusted file systems increases the opportunity for nonprivileged users to attain unauthorized administrative access. diff --git a/linux_os/guide/system/permissions/partitions/mount_option_tmp_nosuid/policy/stig/shared.yml b/linux_os/guide/system/permissions/partitions/mount_option_tmp_nosuid/policy/stig/shared.yml index 859a531228e9..363416f79fa7 100644 --- a/linux_os/guide/system/permissions/partitions/mount_option_tmp_nosuid/policy/stig/shared.yml +++ b/linux_os/guide/system/permissions/partitions/mount_option_tmp_nosuid/policy/stig/shared.yml @@ -2,7 +2,7 @@ srg_requirement: |- {{{ full_name }}} must mount /tmp with the nosuid option. vuldiscussion: |- - The "nosuid" mount option causes the system to not execute "setuid" and "setgid" files with owner privileges. This option must be used for mounting any file system not containing approved "setuid" and "setguid" files. Executing files from untrusted file systems increases the opportunity for unprivileged users to attain unauthorized administrative access. + The "nosuid" mount option causes the system to not execute "setuid" and "setgid" files with owner privileges. This option must be used for mounting any file system not containing approved "setuid" and "setguid" files. Executing files from untrusted file systems increases the opportunity for nonprivileged users to attain unauthorized administrative access. checktext: |- Verify "/tmp" is mounted with the "nosuid" option: @@ -16,5 +16,3 @@ checktext: |- fixtext: |- Modify "/etc/fstab" to use the "nosuid" option on the "/tmp" directory. -vuln_discussion: |- - The "nosuid" mount option causes the system to not execute "setuid" and "setgid" files with owner privileges. This option must be used for mounting any file system not containing approved "setuid" and "setguid" files. Executing files from untrusted file systems increases the opportunity for nonprivileged users to attain unauthorized administrative access. diff --git a/linux_os/guide/system/permissions/partitions/mount_option_var_log_audit_nodev/policy/stig/shared.yml b/linux_os/guide/system/permissions/partitions/mount_option_var_log_audit_nodev/policy/stig/shared.yml index d33a6571f657..c8962fbc414f 100644 --- a/linux_os/guide/system/permissions/partitions/mount_option_var_log_audit_nodev/policy/stig/shared.yml +++ b/linux_os/guide/system/permissions/partitions/mount_option_var_log_audit_nodev/policy/stig/shared.yml @@ -2,7 +2,7 @@ srg_requirement: |- {{{ full_name }}} must mount /var/log/audit with the nodev option. vuldiscussion: |- - The "nodev" mount option causes the system to not interpret character or block special devices. Executing character or block special devices from untrusted file systems increases the opportunity for unprivileged users to attain unauthorized administrative access. + The "nodev" mount option causes the system to not interpret character or block special devices. Executing character or block special devices from untrusted file systems increases the opportunity for nonprivileged users to attain unauthorized administrative access. The only legitimate location for device files is the "/dev" directory located on the root partition, with the exception of chroot jails if implemented. @@ -18,7 +18,3 @@ checktext: |- fixtext: |- Modify "/etc/fstab" to use the "nodev" option on the "/var/log/audit" directory. -vuln_discussion: |- - The "nodev" mount option causes the system to not interpret character or block special devices. Executing character or block special devices from untrusted file systems increases the opportunity for nonprivileged users to attain unauthorized administrative access. - - The only legitimate location for device files is the "/dev" directory located on the root partition, with the exception of chroot jails if implemented. diff --git a/linux_os/guide/system/permissions/partitions/mount_option_var_log_audit_noexec/policy/stig/shared.yml b/linux_os/guide/system/permissions/partitions/mount_option_var_log_audit_noexec/policy/stig/shared.yml index 64531847a141..1d6c33959440 100644 --- a/linux_os/guide/system/permissions/partitions/mount_option_var_log_audit_noexec/policy/stig/shared.yml +++ b/linux_os/guide/system/permissions/partitions/mount_option_var_log_audit_noexec/policy/stig/shared.yml @@ -2,7 +2,7 @@ srg_requirement: |- {{{ full_name }}} must mount /var/log/audit with the noexec option. vuldiscussion: |- - The "noexec" mount option causes the system to not execute binary files. This option must be used for mounting any file system not containing approved binary files, as they may be incompatible. Executing files from untrusted file systems increases the opportunity for unprivileged users to attain unauthorized administrative access. + The "noexec" mount option causes the system to not execute binary files. This option must be used for mounting any file system not containing approved binary files, as they may be incompatible. Executing files from untrusted file systems increases the opportunity for nonprivileged users to attain unauthorized administrative access. checktext: |- Verify "/var/log/audit" is mounted with the "noexec" option: @@ -16,5 +16,3 @@ checktext: |- fixtext: |- Modify "/etc/fstab" to use the "noexec" option on the "/var/log/audit" directory. -vuln_discussion: |- - The "noexec" mount option causes the system to not execute binary files. This option must be used for mounting any file system not containing approved binary files, as they may be incompatible. Executing files from untrusted file systems increases the opportunity for nonprivileged users to attain unauthorized administrative access. diff --git a/linux_os/guide/system/permissions/partitions/mount_option_var_log_audit_nosuid/policy/stig/shared.yml b/linux_os/guide/system/permissions/partitions/mount_option_var_log_audit_nosuid/policy/stig/shared.yml index 550d72503cef..139d3888276d 100644 --- a/linux_os/guide/system/permissions/partitions/mount_option_var_log_audit_nosuid/policy/stig/shared.yml +++ b/linux_os/guide/system/permissions/partitions/mount_option_var_log_audit_nosuid/policy/stig/shared.yml @@ -2,7 +2,7 @@ srg_requirement: |- {{{ full_name }}} must mount /var/log/audit with the nosuid option. vuldiscussion: |- - The "nosuid" mount option causes the system to not execute "setuid" and "setgid" files with owner privileges. This option must be used for mounting any file system not containing approved "setuid" and "setguid" files. Executing files from untrusted file systems increases the opportunity for unprivileged users to attain unauthorized administrative access. + The "nosuid" mount option causes the system to not execute "setuid" and "setgid" files with owner privileges. This option must be used for mounting any file system not containing approved "setuid" and "setguid" files. Executing files from untrusted file systems increases the opportunity for nonprivileged users to attain unauthorized administrative access. checktext: |- Verify "/var/log/audit" is mounted with the "nosuid" option: @@ -16,5 +16,3 @@ checktext: |- fixtext: |- Modify "/etc/fstab" to use the "nosuid" option on the "/var/log/audit" directory. -vuln_discussion: |- - The "nosuid" mount option causes the system to not execute "setuid" and "setgid" files with owner privileges. This option must be used for mounting any file system not containing approved "setuid" and "setguid" files. Executing files from untrusted file systems increases the opportunity for nonprivileged users to attain unauthorized administrative access. diff --git a/linux_os/guide/system/permissions/partitions/mount_option_var_log_nodev/policy/stig/shared.yml b/linux_os/guide/system/permissions/partitions/mount_option_var_log_nodev/policy/stig/shared.yml index 28c6669bec19..0dc40097a6e4 100644 --- a/linux_os/guide/system/permissions/partitions/mount_option_var_log_nodev/policy/stig/shared.yml +++ b/linux_os/guide/system/permissions/partitions/mount_option_var_log_nodev/policy/stig/shared.yml @@ -2,7 +2,7 @@ srg_requirement: |- {{{ full_name }}} must mount /var/log with the nodev option. vuldiscussion: |- - The "nodev" mount option causes the system to not interpret character or block special devices. Executing character or block special devices from untrusted file systems increases the opportunity for unprivileged users to attain unauthorized administrative access. + The "nodev" mount option causes the system to not interpret character or block special devices. Executing character or block special devices from untrusted file systems increases the opportunity for nonprivileged users to attain unauthorized administrative access. The only legitimate location for device files is the "/dev" directory located on the root partition, with the exception of chroot jails if implemented. @@ -18,7 +18,3 @@ checktext: |- fixtext: |- Modify "/etc/fstab" to use the "nodev" option on the "/var/log" directory. -vuln_discussion: |- - The "nodev" mount option causes the system to not interpret character or block special devices. Executing character or block special devices from untrusted file systems increases the opportunity for nonprivileged users to attain unauthorized administrative access. - - The only legitimate location for device files is the "/dev" directory located on the root partition, with the exception of chroot jails if implemented. diff --git a/linux_os/guide/system/permissions/partitions/mount_option_var_log_noexec/policy/stig/shared.yml b/linux_os/guide/system/permissions/partitions/mount_option_var_log_noexec/policy/stig/shared.yml index 7cd75e88cd8d..125082ee4b5c 100644 --- a/linux_os/guide/system/permissions/partitions/mount_option_var_log_noexec/policy/stig/shared.yml +++ b/linux_os/guide/system/permissions/partitions/mount_option_var_log_noexec/policy/stig/shared.yml @@ -2,7 +2,7 @@ srg_requirement: |- {{{ full_name }}} must mount /var/log with the noexec option. vuldiscussion: |- - The "noexec" mount option causes the system to not execute binary files. This option must be used for mounting any file system not containing approved binary files, as they may be incompatible. Executing files from untrusted file systems increases the opportunity for unprivileged users to attain unauthorized administrative access. + The "noexec" mount option causes the system to not execute binary files. This option must be used for mounting any file system not containing approved binary files, as they may be incompatible. Executing files from untrusted file systems increases the opportunity for nonprivileged users to attain unauthorized administrative access. checktext: |- Verify "/var/log" is mounted with the "noexec" option: @@ -16,5 +16,3 @@ checktext: |- fixtext: |- Modify "/etc/fstab" to use the "noexec" option on the "/var/log" directory. -vuln_discussion: |- - The "noexec" mount option causes the system to not execute binary files. This option must be used for mounting any file system not containing approved binary files, as they may be incompatible. Executing files from untrusted file systems increases the opportunity for nonprivileged users to attain unauthorized administrative access. diff --git a/linux_os/guide/system/permissions/partitions/mount_option_var_log_nosuid/policy/stig/shared.yml b/linux_os/guide/system/permissions/partitions/mount_option_var_log_nosuid/policy/stig/shared.yml index 0da70ba8e3f3..ce3491c9c580 100644 --- a/linux_os/guide/system/permissions/partitions/mount_option_var_log_nosuid/policy/stig/shared.yml +++ b/linux_os/guide/system/permissions/partitions/mount_option_var_log_nosuid/policy/stig/shared.yml @@ -2,7 +2,7 @@ srg_requirement: |- {{{ full_name }}} must mount /var/log with the nosuid option. vuldiscussion: |- - The "nosuid" mount option causes the system to not execute "setuid" and "setgid" files with owner privileges. This option must be used for mounting any file system not containing approved "setuid" and "setguid" files. Executing files from untrusted file systems increases the opportunity for unprivileged users to attain unauthorized administrative access. + The "nosuid" mount option causes the system to not execute "setuid" and "setgid" files with owner privileges. This option must be used for mounting any file system not containing approved "setuid" and "setguid" files. Executing files from untrusted file systems increases the opportunity for nonprivileged users to attain unauthorized administrative access. checktext: |- Verify "/var/log" is mounted with the "nosuid" option: @@ -16,5 +16,3 @@ checktext: |- fixtext: |- Modify "/etc/fstab" to use the "nosuid" option on the "/var/log" directory. -vuln_discussion: |- - The "nosuid" mount option causes the system to not execute "setuid" and "setgid" files with owner privileges. This option must be used for mounting any file system not containing approved "setuid" and "setguid" files. Executing files from untrusted file systems increases the opportunity for nonprivileged users to attain unauthorized administrative access. diff --git a/linux_os/guide/system/permissions/partitions/mount_option_var_nodev/policy/stig/shared.yml b/linux_os/guide/system/permissions/partitions/mount_option_var_nodev/policy/stig/shared.yml index 47439289feee..e1465f710317 100644 --- a/linux_os/guide/system/permissions/partitions/mount_option_var_nodev/policy/stig/shared.yml +++ b/linux_os/guide/system/permissions/partitions/mount_option_var_nodev/policy/stig/shared.yml @@ -2,7 +2,7 @@ srg_requirement: |- {{{ full_name }}} must mount /var with the nodev option. vuldiscussion: |- - The "nodev" mount option causes the system to not interpret character or block special devices. Executing character or block special devices from untrusted file systems increases the opportunity for unprivileged users to attain unauthorized administrative access. + The "nodev" mount option causes the system to not interpret character or block special devices. Executing character or block special devices from untrusted file systems increases the opportunity for nonprivileged users to attain unauthorized administrative access. The only legitimate location for device files is the "/dev" directory located on the root partition, with the exception of chroot jails if implemented. @@ -18,7 +18,3 @@ checktext: |- fixtext: |- Modify "/etc/fstab" to use the "nodev" option on the "/var" directory. -vuln_discussion: |- - The "nodev" mount option causes the system to not interpret character or block special devices. Executing character or block special devices from untrusted file systems increases the opportunity for nonprivileged users to attain unauthorized administrative access. - - The only legitimate location for device files is the "/dev" directory located on the root partition, with the exception of chroot jails if implemented. diff --git a/linux_os/guide/system/permissions/partitions/mount_option_var_tmp_nodev/policy/stig/shared.yml b/linux_os/guide/system/permissions/partitions/mount_option_var_tmp_nodev/policy/stig/shared.yml index d845fc6b5079..8ee8e813359c 100644 --- a/linux_os/guide/system/permissions/partitions/mount_option_var_tmp_nodev/policy/stig/shared.yml +++ b/linux_os/guide/system/permissions/partitions/mount_option_var_tmp_nodev/policy/stig/shared.yml @@ -2,7 +2,7 @@ srg_requirement: |- {{{ full_name }}} must mount /var/tmp with the nodev option. vuldiscussion: |- - The "nodev" mount option causes the system to not interpret character or block special devices. Executing character or block special devices from untrusted file systems increases the opportunity for unprivileged users to attain unauthorized administrative access. + The "nodev" mount option causes the system to not interpret character or block special devices. Executing character or block special devices from untrusted file systems increases the opportunity for nonprivileged users to attain unauthorized administrative access. The only legitimate location for device files is the "/dev" directory located on the root partition, with the exception of chroot jails if implemented. @@ -18,7 +18,3 @@ checktext: |- fixtext: |- Modify "/etc/fstab" to use the "nodev" option on the "/var/tmp" directory. -vuln_discussion: |- - The "nodev" mount option causes the system to not interpret character or block special devices. Executing character or block special devices from untrusted file systems increases the opportunity for nonprivileged users to attain unauthorized administrative access. - - The only legitimate location for device files is the "/dev" directory located on the root partition, with the exception of chroot jails if implemented. diff --git a/linux_os/guide/system/permissions/partitions/mount_option_var_tmp_noexec/policy/stig/shared.yml b/linux_os/guide/system/permissions/partitions/mount_option_var_tmp_noexec/policy/stig/shared.yml index fdf43ee9cbeb..191aa810b9ed 100644 --- a/linux_os/guide/system/permissions/partitions/mount_option_var_tmp_noexec/policy/stig/shared.yml +++ b/linux_os/guide/system/permissions/partitions/mount_option_var_tmp_noexec/policy/stig/shared.yml @@ -2,7 +2,7 @@ srg_requirement: |- {{{ full_name }}} must mount /var/tmp with the noexec option. vuldiscussion: |- - The "noexec" mount option causes the system to not execute binary files. This option must be used for mounting any file system not containing approved binary files, as they may be incompatible. Executing files from untrusted file systems increases the opportunity for unprivileged users to attain unauthorized administrative access. + The "noexec" mount option causes the system to not execute binary files. This option must be used for mounting any file system not containing approved binary files, as they may be incompatible. Executing files from untrusted file systems increases the opportunity for nonprivileged users to attain unauthorized administrative access. checktext: |- Verify "/var/tmp" is mounted with the "noexec" option: @@ -16,5 +16,3 @@ checktext: |- fixtext: |- Modify "/etc/fstab" to use the "noexec" option on the "/var/tmp" directory. -vuln_discussion: |- - The "noexec" mount option causes the system to not execute binary files. This option must be used for mounting any file system not containing approved binary files, as they may be incompatible. Executing files from untrusted file systems increases the opportunity for nonprivileged users to attain unauthorized administrative access. diff --git a/linux_os/guide/system/permissions/partitions/mount_option_var_tmp_nosuid/policy/stig/shared.yml b/linux_os/guide/system/permissions/partitions/mount_option_var_tmp_nosuid/policy/stig/shared.yml index 733ba85cdcb0..7e48f89cd1e4 100644 --- a/linux_os/guide/system/permissions/partitions/mount_option_var_tmp_nosuid/policy/stig/shared.yml +++ b/linux_os/guide/system/permissions/partitions/mount_option_var_tmp_nosuid/policy/stig/shared.yml @@ -2,7 +2,7 @@ srg_requirement: |- {{{ full_name }}} must mount /var/tmp with the nosuid option. vuldiscussion: |- - The "nosuid" mount option causes the system to not execute "setuid" and "setgid" files with owner privileges. This option must be used for mounting any file system not containing approved "setuid" and "setguid" files. Executing files from untrusted file systems increases the opportunity for unprivileged users to attain unauthorized administrative access. + The "nosuid" mount option causes the system to not execute "setuid" and "setgid" files with owner privileges. This option must be used for mounting any file system not containing approved "setuid" and "setguid" files. Executing files from untrusted file systems increases the opportunity for nonprivileged users to attain unauthorized administrative access. checktext: |- Verify "/var/tmp" is mounted with the "nosuid" option: @@ -16,5 +16,3 @@ checktext: |- fixtext: |- Modify "/etc/fstab" to use the "nosuid" option on the "/var/tmp" directory. -vuln_discussion: |- - The "nosuid" mount option causes the system to not execute "setuid" and "setgid" files with owner privileges. This option must be used for mounting any file system not containing approved "setuid" and "setguid" files. Executing files from untrusted file systems increases the opportunity for nonprivileged users to attain unauthorized administrative access. diff --git a/linux_os/guide/system/permissions/restrictions/coredumps/coredump_disable_backtraces/policy/stig/shared.yml b/linux_os/guide/system/permissions/restrictions/coredumps/coredump_disable_backtraces/policy/stig/shared.yml index 323d02835d19..c9f241901e54 100644 --- a/linux_os/guide/system/permissions/restrictions/coredumps/coredump_disable_backtraces/policy/stig/shared.yml +++ b/linux_os/guide/system/permissions/restrictions/coredumps/coredump_disable_backtraces/policy/stig/shared.yml @@ -2,15 +2,9 @@ srg_requirement: |- {{{ full_name }}} must disable core dump backtraces. vuldiscussion: |- - A core dump includes a memory image taken at the time the operating system - terminates an application. The memory image could contain sensitive data - and is generally useful only for developers or system operators trying to - debug problems. + A core dump includes a memory image taken at the time the operating system terminates an application. The memory image could contain sensitive data and is generally useful only for developers or system operators trying to debug problems. - Enabling core dumps on production systems is not recommended, - however there may be overriding operational requirements to enable advanced - debuging. Permitting temporary enablement of core dumps during such situations - should be reviewed through local needs and policy. + Enabling core dumps on production systems is not recommended; however, there may be overriding operational requirements to enable advanced debugging. Permitting temporary enablement of core dumps during such situations must be reviewed through local needs and policy. checktext: |- Verify {{{ full_name }}} disables core dump backtraces by issuing the following command: @@ -28,7 +22,3 @@ fixtext: |- ProcessSizeMax=0 -vuln_discussion: |- - A core dump includes a memory image taken at the time the operating system terminates an application. The memory image could contain sensitive data and is generally useful only for developers or system operators trying to debug problems. - - Enabling core dumps on production systems is not recommended; however, there may be overriding operational requirements to enable advanced debugging. Permitting temporary enablement of core dumps during such situations must be reviewed through local needs and policy. diff --git a/linux_os/guide/system/permissions/restrictions/coredumps/coredump_disable_storage/policy/stig/shared.yml b/linux_os/guide/system/permissions/restrictions/coredumps/coredump_disable_storage/policy/stig/shared.yml index ee39f9f75301..c0b401567b25 100644 --- a/linux_os/guide/system/permissions/restrictions/coredumps/coredump_disable_storage/policy/stig/shared.yml +++ b/linux_os/guide/system/permissions/restrictions/coredumps/coredump_disable_storage/policy/stig/shared.yml @@ -2,13 +2,7 @@ srg_requirement: |- {{{ full_name }}} must disable storing core dumps. vuldiscussion: |- - A core dump includes a memory image taken at the time the operating system - terminates an application. The memory image could contain sensitive data - and is generally useful only for developers or system operators trying to - debug problems. Enabling core dumps on production systems is not recommended, - however there may be overriding operational requirements to enable advanced - debuging. Permitting temporary enablement of core dumps during such situations - should be reviewed through local needs and policy. + A core dump includes a memory image taken at the time the operating system terminates an application. The memory image could contain sensitive data and is generally useful only for developers or system operators trying to debug problems. Enabling core dumps on production systems is not recommended; however, there may be overriding operational requirements to enable advanced debugging. Permitting temporary enablement of core dumps during such situations must be reviewed through local needs and policy. checktext: |- Verify {{{ full_name }}} disables storing core dumps for all users by issuing the following command: @@ -26,5 +20,3 @@ fixtext: |- Storage=none -vuln_discussion: |- - A core dump includes a memory image taken at the time the operating system terminates an application. The memory image could contain sensitive data and is generally useful only for developers or system operators trying to debug problems. Enabling core dumps on production systems is not recommended; however, there may be overriding operational requirements to enable advanced debugging. Permitting temporary enablement of core dumps during such situations must be reviewed through local needs and policy. diff --git a/linux_os/guide/system/permissions/restrictions/coredumps/disable_users_coredumps/policy/stig/shared.yml b/linux_os/guide/system/permissions/restrictions/coredumps/disable_users_coredumps/policy/stig/shared.yml index db37029e2180..30b1fd17654b 100644 --- a/linux_os/guide/system/permissions/restrictions/coredumps/disable_users_coredumps/policy/stig/shared.yml +++ b/linux_os/guide/system/permissions/restrictions/coredumps/disable_users_coredumps/policy/stig/shared.yml @@ -22,5 +22,3 @@ fixtext: |- * hard core 0 -vuln_discussion: |- - A core dump includes a memory image taken at the time the operating system terminates an application. The memory image could contain sensitive data and is generally useful only for developers trying to debug problems. diff --git a/linux_os/guide/system/permissions/restrictions/coredumps/service_systemd-coredump_disabled/policy/stig/shared.yml b/linux_os/guide/system/permissions/restrictions/coredumps/service_systemd-coredump_disabled/policy/stig/shared.yml index 2bd0767cb5af..d836d68fa428 100644 --- a/linux_os/guide/system/permissions/restrictions/coredumps/service_systemd-coredump_disabled/policy/stig/shared.yml +++ b/linux_os/guide/system/permissions/restrictions/coredumps/service_systemd-coredump_disabled/policy/stig/shared.yml @@ -2,9 +2,7 @@ srg_requirement: |- {{{ full_name }}} must disable acquiring, saving, and processing core dumps. vuldiscussion: |- - A core dump includes a memory image taken at the time the operating system - terminates an application. The memory image could contain sensitive data - and is generally useful only for developers trying to debug problems. + A core dump includes a memory image taken at the time the operating system terminates an application. The memory image could contain sensitive data and is generally useful only for developers trying to debug problems. checktext: |- Verify {{{ full_name }}} is not configured to acquire, save, or process core dumps with the following command: @@ -28,5 +26,3 @@ fixtext: |- $ sudo systemctl daemon-reload -vuln_discussion: |- - A core dump includes a memory image taken at the time the operating system terminates an application. The memory image could contain sensitive data and is generally useful only for developers trying to debug problems. diff --git a/linux_os/guide/system/permissions/restrictions/enable_execshield_settings/sysctl_kernel_exec_shield/policy/stig/shared.yml b/linux_os/guide/system/permissions/restrictions/enable_execshield_settings/sysctl_kernel_exec_shield/policy/stig/shared.yml index 39dc3b6accf0..116783e857ad 100644 --- a/linux_os/guide/system/permissions/restrictions/enable_execshield_settings/sysctl_kernel_exec_shield/policy/stig/shared.yml +++ b/linux_os/guide/system/permissions/restrictions/enable_execshield_settings/sysctl_kernel_exec_shield/policy/stig/shared.yml @@ -2,13 +2,7 @@ srg_requirement: |- {{{ full_name }}} must implement nonexecutable data to protect its memory from unauthorized code execution. vuldiscussion: |- - ExecShield uses the segmentation feature on all x86 systems to prevent - execution in memory higher than a certain address. It writes an address as - a limit in the code segment descriptor, to control where code can be - executed, on a per-process basis. When the kernel places a process's memory - regions such as the stack and heap higher than this address, the hardware - prevents execution in that address range. This is enabled by default on the - latest Red Hat and Fedora systems if supported by the hardware. + ExecShield uses the segmentation feature on all x86 systems to prevent execution in memory higher than a certain address. It writes an address as a limit in the code segment descriptor, to control where code can be executed, on a per-process basis. When the kernel places a process's memory regions such as the stack and heap higher than this address, the hardware prevents execution in that address range. This is enabled by default on the latest Red Hat and Fedora systems if supported by the hardware. checktext: |- Verify ExecShield is enabled on 64-bit {{{ full_name }}} systems with the following command: @@ -26,5 +20,3 @@ fixtext: |- $ sudo grubby --update-kernel=ALL --remove-args=noexec -vuln_discussion: |- - ExecShield uses the segmentation feature on all x86 systems to prevent execution in memory higher than a certain address. It writes an address as a limit in the code segment descriptor, to control where code can be executed, on a per-process basis. When the kernel places a process's memory regions such as the stack and heap higher than this address, the hardware prevents execution in that address range. This is enabled by default on the latest Red Hat and Fedora systems if supported by the hardware. diff --git a/linux_os/guide/system/permissions/restrictions/enable_execshield_settings/sysctl_kernel_kptr_restrict/policy/stig/shared.yml b/linux_os/guide/system/permissions/restrictions/enable_execshield_settings/sysctl_kernel_kptr_restrict/policy/stig/shared.yml index 146f15494388..3166b5a82308 100644 --- a/linux_os/guide/system/permissions/restrictions/enable_execshield_settings/sysctl_kernel_kptr_restrict/policy/stig/shared.yml +++ b/linux_os/guide/system/permissions/restrictions/enable_execshield_settings/sysctl_kernel_kptr_restrict/policy/stig/shared.yml @@ -2,7 +2,7 @@ srg_requirement: |- {{{ full_name }}} must restrict exposed kernel pointer addresses access. vuldiscussion: |- - Exposing kernel pointers (through procfs or "seq_printf()") exposes kernel writeable structures which may contain functions pointers. If a write vulnerability occurs in the kernel, allowing write access to any of this structure, the kernel can be compromised. This option disallow any program without the CAP_SYSLOG capability to get the addresses of kernel pointers by replacing them with 0. + Exposing kernel pointers (through procfs or "seq_printf()") exposes kernel writeable structures, which may contain functions pointers. If a write vulnerability occurs in the kernel, allowing write access to any of this structure, the kernel can be compromised. This option disallows any program without the CAP_SYSLOG capability to get the addresses of kernel pointers by replacing them with "0". checktext: |- Verify the runtime status of the kernel.kptr_restrict kernel parameter with the following command: @@ -28,5 +28,3 @@ fixtext: |- $ sudo sysctl --system -vuln_discussion: |- - Exposing kernel pointers (through procfs or "seq_printf()") exposes kernel writeable structures, which may contain functions pointers. If a write vulnerability occurs in the kernel, allowing write access to any of this structure, the kernel can be compromised. This option disallows any program without the CAP_SYSLOG capability to get the addresses of kernel pointers by replacing them with "0". diff --git a/linux_os/guide/system/permissions/restrictions/enable_execshield_settings/sysctl_kernel_randomize_va_space/policy/stig/shared.yml b/linux_os/guide/system/permissions/restrictions/enable_execshield_settings/sysctl_kernel_randomize_va_space/policy/stig/shared.yml index 089946b3acb6..cae7e5c8d250 100644 --- a/linux_os/guide/system/permissions/restrictions/enable_execshield_settings/sysctl_kernel_randomize_va_space/policy/stig/shared.yml +++ b/linux_os/guide/system/permissions/restrictions/enable_execshield_settings/sysctl_kernel_randomize_va_space/policy/stig/shared.yml @@ -2,9 +2,7 @@ srg_requirement: |- {{{ full_name }}} must implement address space layout randomization (ASLR) to protect its memory from unauthorized code execution. vuldiscussion: |- - Address space layout randomization (ASLR) makes it more difficult for an attacker to predict the location of attack code they have introduced into a - process's address space during an attempt at exploitation. Additionally, ASLR makes it more difficult for an attacker to know the location of - existing code in order to re-purpose it using return oriented programming (ROP) techniques. + Address space layout randomization (ASLR) makes it more difficult for an attacker to predict the location of attack code they have introduced into a process' address space during an attempt at exploitation. Additionally, ASLR makes it more difficult for an attacker to know the location of existing code in order to repurpose it using return oriented programming (ROP) techniques. checktext: |- Verify {{{ full_name }}} is implementing ASLR with the following command: @@ -31,5 +29,3 @@ fixtext: |- $ sudo sysctl --system -vuln_discussion: |- - Address space layout randomization (ASLR) makes it more difficult for an attacker to predict the location of attack code they have introduced into a process' address space during an attempt at exploitation. Additionally, ASLR makes it more difficult for an attacker to know the location of existing code in order to repurpose it using return oriented programming (ROP) techniques. diff --git a/linux_os/guide/system/permissions/restrictions/poisoning/grub2_page_poison_argument/policy/stig/shared.yml b/linux_os/guide/system/permissions/restrictions/poisoning/grub2_page_poison_argument/policy/stig/shared.yml index a74f34dde3cc..4389f79c4a10 100644 --- a/linux_os/guide/system/permissions/restrictions/poisoning/grub2_page_poison_argument/policy/stig/shared.yml +++ b/linux_os/guide/system/permissions/restrictions/poisoning/grub2_page_poison_argument/policy/stig/shared.yml @@ -2,11 +2,7 @@ srg_requirement: |- {{{ full_name }}} must clear the page allocator to prevent use-after-free attacks. vuldiscussion: |- - Poisoning writes an arbitrary value to freed pages, so any modification or - reference to that page after being freed or before being initialized will be - detected and prevented. - This prevents many types of use-after-free vulnerabilities at little performance cost. - Also prevents leak of data and detection of corrupted memory. + Poisoning writes an arbitrary value to freed pages, so any modification or reference to that page after being freed or before being initialized will be detected and prevented. This prevents many types of use-after-free vulnerabilities at little performance cost. Also prevents leak of data and detection of corrupted memory. checktext: |- Verify that GRUB 2 is configured to enable page poisoning to mitigate use-after-free vulnerabilities. @@ -34,5 +30,3 @@ fixtext: |- GRUB_CMDLINE_LINUX="page_poison=1" -vuln_discussion: |- - Poisoning writes an arbitrary value to freed pages, so any modification or reference to that page after being freed or before being initialized will be detected and prevented. This prevents many types of use-after-free vulnerabilities at little performance cost. Also prevents leak of data and detection of corrupted memory. diff --git a/linux_os/guide/system/permissions/restrictions/poisoning/grub2_slub_debug_argument/policy/stig/shared.yml b/linux_os/guide/system/permissions/restrictions/poisoning/grub2_slub_debug_argument/policy/stig/shared.yml index e8561b89c14d..22655f1d428b 100644 --- a/linux_os/guide/system/permissions/restrictions/poisoning/grub2_slub_debug_argument/policy/stig/shared.yml +++ b/linux_os/guide/system/permissions/restrictions/poisoning/grub2_slub_debug_argument/policy/stig/shared.yml @@ -2,11 +2,11 @@ srg_requirement: |- {{{ full_name }}} must clear SLUB/SLAB objects to prevent use-after-free attacks. vuldiscussion: |- - Some adversaries launch attacks with the intent of executing code in non-executable regions of memory or in memory locations that are prohibited. Security safeguards employed to protect memory include, for example, data execution prevention and address space layout randomization. Data execution prevention safeguards can be either hardware-enforced or software-enforced with hardware providing the greater strength of mechanism. + Some adversaries launch attacks with the intent of executing code in nonexecutable regions of memory or in memory locations that are prohibited. Security safeguards employed to protect memory include, for example, data execution prevention and address space layout randomization. Data execution prevention safeguards can be either hardware-enforced or software-enforced with hardware providing the greater strength of mechanism. Poisoning writes an arbitrary value to freed pages, so any modification or reference to that page after being freed or before being initialized will be detected and prevented. This prevents many types of use-after-free vulnerabilities at little performance cost. Also prevents leak of data and detection of corrupted memory. - SLAB objects are blocks of physically-contiguous memory. SLUB is the unqueued SLAB allocator. + SLAB objects are blocks of physically contiguous memory. SLUB is the unqueued SLAB allocator. checktext: |- Verify that GRUB 2 is configured to enable poisoning of SLUB/SLAB objects to mitigate use-after-free vulnerabilities with the following commands: @@ -34,9 +34,3 @@ fixtext: |- GRUB_CMDLINE_LINUX="slub_debug=P" -vuln_discussion: |- - Some adversaries launch attacks with the intent of executing code in nonexecutable regions of memory or in memory locations that are prohibited. Security safeguards employed to protect memory include, for example, data execution prevention and address space layout randomization. Data execution prevention safeguards can be either hardware-enforced or software-enforced with hardware providing the greater strength of mechanism. - - Poisoning writes an arbitrary value to freed pages, so any modification or reference to that page after being freed or before being initialized will be detected and prevented. This prevents many types of use-after-free vulnerabilities at little performance cost. Also prevents leak of data and detection of corrupted memory. - - SLAB objects are blocks of physically contiguous memory. SLUB is the unqueued SLAB allocator. diff --git a/linux_os/guide/system/permissions/restrictions/sysctl_kernel_core_pattern/policy/stig/shared.yml b/linux_os/guide/system/permissions/restrictions/sysctl_kernel_core_pattern/policy/stig/shared.yml index a26e89927a3f..6a537be562ea 100644 --- a/linux_os/guide/system/permissions/restrictions/sysctl_kernel_core_pattern/policy/stig/shared.yml +++ b/linux_os/guide/system/permissions/restrictions/sysctl_kernel_core_pattern/policy/stig/shared.yml @@ -2,9 +2,7 @@ srg_requirement: |- {{{ full_name }}} must disable the kernel.core_pattern. vuldiscussion: |- - A core dump includes a memory image taken at the time the operating system - terminates an application. The memory image could contain sensitive data - and is generally useful only for developers trying to debug problems. + A core dump includes a memory image taken at the time the operating system terminates an application. The memory image could contain sensitive data and is generally useful only for developers trying to debug problems. checktext: |- Verify {{{ full_name }}} disables storing core dumps with the following commands: @@ -34,5 +32,3 @@ fixtext: |- $ sudo sysctl --system -vuln_discussion: |- - A core dump includes a memory image taken at the time the operating system terminates an application. The memory image could contain sensitive data and is generally useful only for developers trying to debug problems. diff --git a/linux_os/guide/system/permissions/restrictions/sysctl_kernel_dmesg_restrict/policy/stig/shared.yml b/linux_os/guide/system/permissions/restrictions/sysctl_kernel_dmesg_restrict/policy/stig/shared.yml index 8db0c0aded47..d3558a57cff0 100644 --- a/linux_os/guide/system/permissions/restrictions/sysctl_kernel_dmesg_restrict/policy/stig/shared.yml +++ b/linux_os/guide/system/permissions/restrictions/sysctl_kernel_dmesg_restrict/policy/stig/shared.yml @@ -4,11 +4,11 @@ srg_requirement: |- vuldiscussion: |- Preventing unauthorized information transfers mitigates the risk of information, including encrypted representations of information, produced by the actions of prior users/roles (or the actions of processes acting on behalf of prior users/roles) from being available to any current users/roles (or current processes) that obtain access to shared system resources (e.g., registers, main memory, hard disks) after those resources have been released back to information systems. The control of information in shared resources is also commonly referred to as object reuse and residual information protection. - This requirement generally applies to the design of an information technology product, but it can also apply to the configuration of particular information system components that are, or use, such products. This can be verified by acceptance/validation processes in DoD or other government agencies. + This requirement generally applies to the design of an information technology product, but it can also apply to the configuration of particular information system components that are, or use, such products. This can be verified by acceptance/validation processes in DOD or other government agencies. There may be shared resources with configurable protections (e.g., files in storage) that may be assessed on specific information system components. - Restricting access to the kernel message buffer limits access to only root. This prevents attackers from gaining additional system information as a non-privileged user. + Restricting access to the kernel message buffer limits access to only root. This prevents attackers from gaining additional system information as a nonprivileged user. checktext: |- Verify {{{ full_name }}} is configured to restrict access to the kernel message buffer with the following commands: @@ -40,11 +40,3 @@ fixtext: |- $ sudo sysctl --system -vuln_discussion: |- - Preventing unauthorized information transfers mitigates the risk of information, including encrypted representations of information, produced by the actions of prior users/roles (or the actions of processes acting on behalf of prior users/roles) from being available to any current users/roles (or current processes) that obtain access to shared system resources (e.g., registers, main memory, hard disks) after those resources have been released back to information systems. The control of information in shared resources is also commonly referred to as object reuse and residual information protection. - - This requirement generally applies to the design of an information technology product, but it can also apply to the configuration of particular information system components that are, or use, such products. This can be verified by acceptance/validation processes in DOD or other government agencies. - - There may be shared resources with configurable protections (e.g., files in storage) that may be assessed on specific information system components. - - Restricting access to the kernel message buffer limits access to only root. This prevents attackers from gaining additional system information as a nonprivileged user. diff --git a/linux_os/guide/system/permissions/restrictions/sysctl_kernel_kexec_load_disabled/policy/stig/shared.yml b/linux_os/guide/system/permissions/restrictions/sysctl_kernel_kexec_load_disabled/policy/stig/shared.yml index 82a3eb1fc092..2360d3ee8059 100644 --- a/linux_os/guide/system/permissions/restrictions/sysctl_kernel_kexec_load_disabled/policy/stig/shared.yml +++ b/linux_os/guide/system/permissions/restrictions/sysctl_kernel_kexec_load_disabled/policy/stig/shared.yml @@ -34,7 +34,3 @@ fixtext: |- $ sudo sysctl --system -vuln_discussion: |- - 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. - - Disabling kexec_load prevents an unsigned kernel image (that could be a windows kernel or modified vulnerable kernel) from being loaded. Kexec can be used subvert the entire secureboot process and should be avoided at all costs especially since it can load unsigned kernel images. diff --git a/linux_os/guide/system/permissions/restrictions/sysctl_kernel_perf_event_paranoid/policy/stig/shared.yml b/linux_os/guide/system/permissions/restrictions/sysctl_kernel_perf_event_paranoid/policy/stig/shared.yml index 625b77d51aa8..b4dbd2ae586f 100644 --- a/linux_os/guide/system/permissions/restrictions/sysctl_kernel_perf_event_paranoid/policy/stig/shared.yml +++ b/linux_os/guide/system/permissions/restrictions/sysctl_kernel_perf_event_paranoid/policy/stig/shared.yml @@ -4,11 +4,11 @@ srg_requirement: |- vuldiscussion: |- Preventing unauthorized information transfers mitigates the risk of information, including encrypted representations of information, produced by the actions of prior users/roles (or the actions of processes acting on behalf of prior users/roles) from being available to any current users/roles (or current processes) that obtain access to shared system resources (e.g., registers, main memory, hard disks) after those resources have been released back to information systems. The control of information in shared resources is also commonly referred to as object reuse and residual information protection. - This requirement generally applies to the design of an information technology product, but it can also apply to the configuration of particular information system components that are, or use, such products. This can be verified by acceptance/validation processes in DoD or other government agencies. + This requirement generally applies to the design of an information technology product, but it can also apply to the configuration of particular information system components that are, or use, such products. This can be verified by acceptance/validation processes in DOD or other government agencies. There may be shared resources with configurable protections (e.g., files in storage) that may be assessed on specific information system components. - Setting the kernel.perf_event_paranoid kernel parameter to "2" prevents attackers from gaining additional system information as a non-privileged user. + Setting the kernel.perf_event_paranoid kernel parameter to "2" prevents attackers from gaining additional system information as a nonprivileged user. checktext: |- Verify {{{ full_name }}} is configured to prevent kernel profiling by nonprivileged users with the following commands: @@ -39,11 +39,3 @@ fixtext: |- $ sudo sysctl --system -vuln_discussion: |- - Preventing unauthorized information transfers mitigates the risk of information, including encrypted representations of information, produced by the actions of prior users/roles (or the actions of processes acting on behalf of prior users/roles) from being available to any current users/roles (or current processes) that obtain access to shared system resources (e.g., registers, main memory, hard disks) after those resources have been released back to information systems. The control of information in shared resources is also commonly referred to as object reuse and residual information protection. - - This requirement generally applies to the design of an information technology product, but it can also apply to the configuration of particular information system components that are, or use, such products. This can be verified by acceptance/validation processes in DOD or other government agencies. - - There may be shared resources with configurable protections (e.g., files in storage) that may be assessed on specific information system components. - - Setting the kernel.perf_event_paranoid kernel parameter to "2" prevents attackers from gaining additional system information as a nonprivileged user. diff --git a/linux_os/guide/system/permissions/restrictions/sysctl_kernel_unprivileged_bpf_disabled/policy/stig/shared.yml b/linux_os/guide/system/permissions/restrictions/sysctl_kernel_unprivileged_bpf_disabled/policy/stig/shared.yml index 3433474a31e7..68a40ccbef87 100644 --- a/linux_os/guide/system/permissions/restrictions/sysctl_kernel_unprivileged_bpf_disabled/policy/stig/shared.yml +++ b/linux_os/guide/system/permissions/restrictions/sysctl_kernel_unprivileged_bpf_disabled/policy/stig/shared.yml @@ -2,8 +2,7 @@ srg_requirement: |- {{{ full_name }}} must disable access to network bpf system call from nonprivileged processes. vuldiscussion: |- - Loading and accessing the packet filters programs and maps using the bpf() - syscall has the potential of revealing sensitive information about the kernel state. + Loading and accessing the packet filters programs and maps using the bpf() system call has the potential of revealing sensitive information about the kernel state. checktext: |- Verify {{{ full_name }}} prevents privilege escalation thru the kernel by disabling access to the bpf system call with the following commands: @@ -30,5 +29,3 @@ fixtext: |- $ sudo sysctl --system -vuln_discussion: |- - Loading and accessing the packet filters programs and maps using the bpf() system call has the potential of revealing sensitive information about the kernel state. diff --git a/linux_os/guide/system/permissions/restrictions/sysctl_kernel_yama_ptrace_scope/policy/stig/shared.yml b/linux_os/guide/system/permissions/restrictions/sysctl_kernel_yama_ptrace_scope/policy/stig/shared.yml index 355dc48ba635..8445ee3a3beb 100644 --- a/linux_os/guide/system/permissions/restrictions/sysctl_kernel_yama_ptrace_scope/policy/stig/shared.yml +++ b/linux_os/guide/system/permissions/restrictions/sysctl_kernel_yama_ptrace_scope/policy/stig/shared.yml @@ -2,9 +2,7 @@ srg_requirement: |- {{{ full_name }}} must restrict usage of ptrace to descendant processes. vuldiscussion: |- - Unrestricted usage of ptrace allows compromised binaries to run ptrace on another processes of the user. Like this, the attacker can steal - sensitive information from the target processes (e.g. SSH sessions, web browser, etc) without any additional assistance from the user (i.e. without resorting to phishing). - + Unrestricted usage of ptrace allows compromised binaries to run ptrace on other processes of the user. Like this, the attacker can steal sensitive information from the target processes (e.g., SSH sessions, web browser, etc.) without any additional assistance from the user (i.e., without resorting to phishing). checktext: |- Verify {{{ full_name }}} restricts usage of ptrace to descendant processes with the following commands: @@ -31,5 +29,3 @@ fixtext: |- $ sudo sysctl --system -vuln_discussion: |- - Unrestricted usage of ptrace allows compromised binaries to run ptrace on other processes of the user. Like this, the attacker can steal sensitive information from the target processes (e.g., SSH sessions, web browser, etc.) without any additional assistance from the user (i.e., without resorting to phishing). diff --git a/linux_os/guide/system/permissions/restrictions/sysctl_net_core_bpf_jit_harden/policy/stig/shared.yml b/linux_os/guide/system/permissions/restrictions/sysctl_net_core_bpf_jit_harden/policy/stig/shared.yml index ad321c7f7419..fe2409c92b11 100644 --- a/linux_os/guide/system/permissions/restrictions/sysctl_net_core_bpf_jit_harden/policy/stig/shared.yml +++ b/linux_os/guide/system/permissions/restrictions/sysctl_net_core_bpf_jit_harden/policy/stig/shared.yml @@ -2,9 +2,7 @@ srg_requirement: |- {{{ full_name }}} must enable hardening for the Berkeley Packet Filter just-in-time compiler. vuldiscussion: |- - When hardened, the extended Berkeley Packet Filter just-in-time compiler - will randomize any kernel addresses in the BPF programs and maps, - and will not expose the JIT addresses in "/proc/kallsyms". + When hardened, the extended Berkeley Packet Filter (BPF) just-in-time (JIT) compiler will randomize any kernel addresses in the BPF programs and maps, and will not expose the JIT addresses in "/proc/kallsyms". checktext: |- Verify {{{ full_name }}} enables hardening for the BPF JIT with the following commands: @@ -31,5 +29,3 @@ fixtext: |- $ sudo sysctl --system -vuln_discussion: |- - When hardened, the extended Berkeley Packet Filter (BPF) just-in-time (JIT) compiler will randomize any kernel addresses in the BPF programs and maps, and will not expose the JIT addresses in "/proc/kallsyms". diff --git a/linux_os/guide/system/permissions/restrictions/sysctl_user_max_user_namespaces/policy/stig/shared.yml b/linux_os/guide/system/permissions/restrictions/sysctl_user_max_user_namespaces/policy/stig/shared.yml index 18b6963d91c5..6c3823c91bb4 100644 --- a/linux_os/guide/system/permissions/restrictions/sysctl_user_max_user_namespaces/policy/stig/shared.yml +++ b/linux_os/guide/system/permissions/restrictions/sysctl_user_max_user_namespaces/policy/stig/shared.yml @@ -2,8 +2,7 @@ srg_requirement: |- {{{ full_name }}} must disable the use of user namespaces. vuldiscussion: |- - User namespaces are used primarily for Linux containers. The value 0 - disallows the use of user namespaces. + User namespaces are used primarily for Linux containers. The value "0" disallows the use of user namespaces. checktext: |- Verify {{{ full_name }}} disables the use of user namespaces with the following commands: @@ -34,5 +33,3 @@ fixtext: |- $ sudo sysctl --system -vuln_discussion: |- - User namespaces are used primarily for Linux containers. The value "0" disallows the use of user namespaces. diff --git a/linux_os/guide/system/selinux/package_policycoreutils-python-utils_installed/policy/stig/shared.yml b/linux_os/guide/system/selinux/package_policycoreutils-python-utils_installed/policy/stig/shared.yml index 8219b3608a6d..86e6bb914f19 100644 --- a/linux_os/guide/system/selinux/package_policycoreutils-python-utils_installed/policy/stig/shared.yml +++ b/linux_os/guide/system/selinux/package_policycoreutils-python-utils_installed/policy/stig/shared.yml @@ -2,7 +2,7 @@ srg_requirement: |- {{{ full_name }}} policycoreutils-python-utils package must be installed. vuldiscussion: |- - The policycoreutils-python-utils package is required to operate and manage an SELinux environment and its policies. It provides utilities such as semanage, audit2allow, audit2why, chcat and sandbox. + The policycoreutils-python-utils package is required to operate and manage an SELinux environment and its policies. It provides utilities such as semanage, audit2allow, audit2why, chcat, and sandbox. checktext: |- Verify that {{{ full_name }}} policycoreutils-python-utils service package is installed with the following command: @@ -20,5 +20,3 @@ fixtext: |- $ sudo dnf install policycoreutils-python-utils -vuln_discussion: |- - The policycoreutils-python-utils package is required to operate and manage an SELinux environment and its policies. It provides utilities such as semanage, audit2allow, audit2why, chcat, and sandbox. diff --git a/linux_os/guide/system/selinux/package_policycoreutils_installed/policy/stig/shared.yml b/linux_os/guide/system/selinux/package_policycoreutils_installed/policy/stig/shared.yml index 25d256ed67cc..63ebc8a55eb6 100644 --- a/linux_os/guide/system/selinux/package_policycoreutils_installed/policy/stig/shared.yml +++ b/linux_os/guide/system/selinux/package_policycoreutils_installed/policy/stig/shared.yml @@ -22,7 +22,3 @@ fixtext: |- $ sudo dnf install policycoreutils -vuln_discussion: |- - 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. diff --git a/linux_os/guide/system/selinux/selinux_all_devicefiles_labeled/policy/stig/shared.yml b/linux_os/guide/system/selinux/selinux_all_devicefiles_labeled/policy/stig/shared.yml index ca8e03379b4a..d2a4d8fd6701 100644 --- a/linux_os/guide/system/selinux/selinux_all_devicefiles_labeled/policy/stig/shared.yml +++ b/linux_os/guide/system/selinux/selinux_all_devicefiles_labeled/policy/stig/shared.yml @@ -27,5 +27,3 @@ checktext: |- If there is output from either of these commands, other than already noted, this is a finding. -vuln_discussion: |- - If an unauthorized or modified device is allowed to exist on the system, there is the possibility the system may perform unintended or unauthorized operations. diff --git a/linux_os/guide/system/software/disk_partitioning/encrypt_partitions/policy/stig/shared.yml b/linux_os/guide/system/software/disk_partitioning/encrypt_partitions/policy/stig/shared.yml index ab9ba43949b5..49cdf73b6809 100644 --- a/linux_os/guide/system/software/disk_partitioning/encrypt_partitions/policy/stig/shared.yml +++ b/linux_os/guide/system/software/disk_partitioning/encrypt_partitions/policy/stig/shared.yml @@ -26,7 +26,3 @@ fixtext: |- To encrypt an entire partition, dedicate a partition for encryption in the partition layout. -vuln_discussion: |- - {{{ full_name }}} systems handling data requiring "data at rest" protections must employ cryptographic mechanisms to prevent unauthorized disclosure and modification of the information at rest. - - Selection of a cryptographic mechanism is based on the need to protect the integrity of organizational information. The strength of the mechanism is commensurate with the security category and/or classification of the information. Organizations have the flexibility to either encrypt all information on storage devices (i.e., full disk encryption) or encrypt specific data structures (e.g., files, records, or fields). diff --git a/linux_os/guide/system/software/disk_partitioning/partition_for_home/policy/stig/shared.yml b/linux_os/guide/system/software/disk_partitioning/partition_for_home/policy/stig/shared.yml index 7df3221a585d..768420fe6b56 100644 --- a/linux_os/guide/system/software/disk_partitioning/partition_for_home/policy/stig/shared.yml +++ b/linux_os/guide/system/software/disk_partitioning/partition_for_home/policy/stig/shared.yml @@ -2,9 +2,7 @@ srg_requirement: |- A separate {{{ full_name }}} file system must be used for user home directories (such as /home or an equivalent). vuldiscussion: |- - Ensuring that "/home" is mounted on its own partition enables the - setting of more restrictive mount options, and also helps ensure that - users cannot trivially fill partitions used for log or audit data storage. + Ensuring that "/home" is mounted on its own partition enables the setting of more restrictive mount options, and also helps ensure that users cannot trivially fill partitions used for log or audit data storage. checktext: |- Verify that a separate file system/partition has been created for "/home" with the following command: @@ -18,5 +16,3 @@ checktext: |- fixtext: |- Migrate the "/home" directory onto a separate file system/partition. -vuln_discussion: |- - Ensuring that "/home" is mounted on its own partition enables the setting of more restrictive mount options, and also helps ensure that users cannot trivially fill partitions used for log or audit data storage. diff --git a/linux_os/guide/system/software/disk_partitioning/partition_for_tmp/policy/stig/shared.yml b/linux_os/guide/system/software/disk_partitioning/partition_for_tmp/policy/stig/shared.yml index ec49745f377b..2482f3668962 100644 --- a/linux_os/guide/system/software/disk_partitioning/partition_for_tmp/policy/stig/shared.yml +++ b/linux_os/guide/system/software/disk_partitioning/partition_for_tmp/policy/stig/shared.yml @@ -2,9 +2,7 @@ srg_requirement: |- {{{ full_name }}} must use a separate file system for /tmp. vuldiscussion: |- - The "/tmp" partition is used as temporary storage by many programs. - Placing "/tmp" in its own partition enables the setting of more - restrictive mount options, which can help protect programs which use it. + The "/tmp" partition is used as temporary storage by many programs. Placing "/tmp" in its own partition enables the setting of more restrictive mount options, which can help protect programs that use it. checktext: |- Verify that a separate file system/partition has been created for "/tmp" with the following command: @@ -18,5 +16,3 @@ checktext: |- fixtext: |- Migrate the "/tmp" path onto a separate file system. -vuln_discussion: |- - The "/tmp" partition is used as temporary storage by many programs. Placing "/tmp" in its own partition enables the setting of more restrictive mount options, which can help protect programs that use it. diff --git a/linux_os/guide/system/software/disk_partitioning/partition_for_var/policy/stig/shared.yml b/linux_os/guide/system/software/disk_partitioning/partition_for_var/policy/stig/shared.yml index 2b27ea401510..b6d120dece32 100644 --- a/linux_os/guide/system/software/disk_partitioning/partition_for_var/policy/stig/shared.yml +++ b/linux_os/guide/system/software/disk_partitioning/partition_for_var/policy/stig/shared.yml @@ -2,11 +2,7 @@ srg_requirement: |- {{{ full_name }}} must use a separate file system for /var. vuldiscussion: |- - Ensuring that "/var" is mounted on its own partition enables the - setting of more restrictive mount options. This helps protect - system services such as daemons or other programs which use it. - It is not uncommon for the "/var" directory to contain - world-writable directories installed by other software packages. + Ensuring that "/var" is mounted on its own partition enables the setting of more restrictive mount options. This helps protect system services such as daemons or other programs which use it. It is not uncommon for the "/var" directory to contain world-writable directories installed by other software packages. checktext: |- Verify that a separate file system/partition has been created for "/var" with the following command: @@ -20,5 +16,3 @@ checktext: |- fixtext: |- Migrate the "/var" path onto a separate file system. -vuln_discussion: |- - Ensuring that "/var" is mounted on its own partition enables the setting of more restrictive mount options. This helps protect system services such as daemons or other programs which use it. It is not uncommon for the "/var" directory to contain world-writable directories installed by other software packages. diff --git a/linux_os/guide/system/software/disk_partitioning/partition_for_var_log/policy/stig/shared.yml b/linux_os/guide/system/software/disk_partitioning/partition_for_var_log/policy/stig/shared.yml index def6363f8c03..1926c8e65c95 100644 --- a/linux_os/guide/system/software/disk_partitioning/partition_for_var_log/policy/stig/shared.yml +++ b/linux_os/guide/system/software/disk_partitioning/partition_for_var_log/policy/stig/shared.yml @@ -2,9 +2,7 @@ srg_requirement: |- {{{ full_name }}} must use a separate file system for /var/log. vuldiscussion: |- - Placing "/var/log" in its own partition - enables better separation between log files - and other files in "/var/". + Placing "/var/log" in its own partition enables better separation between log files and other files in "/var/". checktext: |- Verify that a separate file system/partition has been created for "/var/log" with the following command: @@ -18,5 +16,3 @@ checktext: |- fixtext: |- Migrate the "/var/log" path onto a separate file system. -vuln_discussion: |- - Placing "/var/log" in its own partition enables better separation between log files and other files in "/var/". diff --git a/linux_os/guide/system/software/disk_partitioning/partition_for_var_log_audit/policy/stig/shared.yml b/linux_os/guide/system/software/disk_partitioning/partition_for_var_log_audit/policy/stig/shared.yml index c59469217502..0aa06310a8d1 100644 --- a/linux_os/guide/system/software/disk_partitioning/partition_for_var_log_audit/policy/stig/shared.yml +++ b/linux_os/guide/system/software/disk_partitioning/partition_for_var_log_audit/policy/stig/shared.yml @@ -2,8 +2,7 @@ srg_requirement: |- {{{ full_name }}} must use a separate file system for the system audit data path. vuldiscussion: |- - Placing "/var/log/audit" in its own partition enables better separation between audit files and other system files, and helps ensure that - auditing cannot be halted due to the partition running out of space. + Placing "/var/log/audit" in its own partition enables better separation between audit files and other system files, and helps ensure that auditing cannot be halted due to the partition running out of space. checktext: |- Verify that a separate file system/partition has been created for the system audit data path with the following command: @@ -19,5 +18,3 @@ checktext: |- fixtext: |- Migrate the system audit data path onto a separate file system. -vuln_discussion: |- - Placing "/var/log/audit" in its own partition enables better separation between audit files and other system files, and helps ensure that auditing cannot be halted due to the partition running out of space. diff --git a/linux_os/guide/system/software/disk_partitioning/partition_for_var_tmp/policy/stig/shared.yml b/linux_os/guide/system/software/disk_partitioning/partition_for_var_tmp/policy/stig/shared.yml index a5b5a8fa842f..c1ca2110c2be 100644 --- a/linux_os/guide/system/software/disk_partitioning/partition_for_var_tmp/policy/stig/shared.yml +++ b/linux_os/guide/system/software/disk_partitioning/partition_for_var_tmp/policy/stig/shared.yml @@ -2,9 +2,7 @@ srg_requirement: |- {{{ full_name }}} must use a separate file system for /var/tmp. vuldiscussion: |- - The "/var/tmp" partition is used as temporary storage by many programs. - Placing "/var/tmp" in its own partition enables the setting of more - restrictive mount options, which can help protect programs which use it. + The "/var/tmp" partition is used as temporary storage by many programs. Placing "/var/tmp" in its own partition enables the setting of more restrictive mount options, which can help protect programs that use it. checktext: |- Verify that a separate file system/partition has been created for "/var/tmp" with the following command: @@ -18,5 +16,3 @@ checktext: |- fixtext: |- Migrate the "/var/tmp" path onto a separate file system. -vuln_discussion: |- - The "/var/tmp" partition is used as temporary storage by many programs. Placing "/var/tmp" in its own partition enables the setting of more restrictive mount options, which can help protect programs that use it. diff --git a/linux_os/guide/system/software/gnome/dconf_db_up_to_date/policy/stig/shared.yml b/linux_os/guide/system/software/gnome/dconf_db_up_to_date/policy/stig/shared.yml index 30b46a2ff041..935923f3de82 100644 --- a/linux_os/guide/system/software/gnome/dconf_db_up_to_date/policy/stig/shared.yml +++ b/linux_os/guide/system/software/gnome/dconf_db_up_to_date/policy/stig/shared.yml @@ -2,8 +2,7 @@ srg_requirement: |- {{{ full_name }}} effective dconf policy must match the policy keyfiles. vuldiscussion: |- - Unlike text-based keyfiles, the binary database is impossible to check through most automated and all manual means. - Therefore, in order to evaluate dconf configuration, both have to be true at the same time - configuration files have to be compliant, and the database needs to be more recent than those keyfiles, which gives confidence that it reflects them. + Unlike text-based keyfiles, the binary database is impossible to check through most automated and all manual means; therefore, in order to evaluate dconf configuration, both have to be true at the same time - configuration files have to be compliant, and the database needs to be more recent than those keyfiles, which gives confidence that it reflects them. checktext: |- Check the last modification time of the local databases, comparing it to the last modification time of the related keyfiles. The following command will check every dconf database and compare its modification time to the related system keyfiles: @@ -19,5 +18,3 @@ fixtext: |- $ sudo dconf update -vuln_discussion: |- - Unlike text-based keyfiles, the binary database is impossible to check through most automated and all manual means; therefore, in order to evaluate dconf configuration, both have to be true at the same time - configuration files have to be compliant, and the database needs to be more recent than those keyfiles, which gives confidence that it reflects them. diff --git a/linux_os/guide/system/software/gnome/gnome_login_screen/dconf_gnome_disable_restart_shutdown/policy/stig/shared.yml b/linux_os/guide/system/software/gnome/gnome_login_screen/dconf_gnome_disable_restart_shutdown/policy/stig/shared.yml index bcf808ce111f..3706223ff205 100644 --- a/linux_os/guide/system/software/gnome/gnome_login_screen/dconf_gnome_disable_restart_shutdown/policy/stig/shared.yml +++ b/linux_os/guide/system/software/gnome/gnome_login_screen/dconf_gnome_disable_restart_shutdown/policy/stig/shared.yml @@ -2,8 +2,7 @@ srg_requirement: |- {{{ full_name }}} must prevent a user from overriding the disable-restart-buttons setting for the graphical user interface. vuldiscussion: |- - A user who is at the console can reboot the system at the login screen. If restart or shutdown buttons are pressed at the login screen, this can create the risk of short-term loss of availability of systems - due to reboot. + A user who is at the console can reboot the system at the login screen. If restart or shutdown buttons are pressed at the login screen, this can create the risk of short-term loss of availability of systems due to reboot. checktext: |- Verify {{{ full_name }}} prevents a user from overriding the disable-restart-buttons setting for graphical user interfaces. @@ -40,5 +39,3 @@ fixtext: |- Run the following command to update the database: $ sudo dconf update -vuln_discussion: |- - A user who is at the console can reboot the system at the login screen. If restart or shutdown buttons are pressed at the login screen, this can create the risk of short-term loss of availability of systems due to reboot. diff --git a/linux_os/guide/system/software/gnome/gnome_login_screen/dconf_gnome_disable_user_list/policy/stig/shared.yml b/linux_os/guide/system/software/gnome/gnome_login_screen/dconf_gnome_disable_user_list/policy/stig/shared.yml index 2e460274c51a..21d2799f4c3b 100644 --- a/linux_os/guide/system/software/gnome/gnome_login_screen/dconf_gnome_disable_user_list/policy/stig/shared.yml +++ b/linux_os/guide/system/software/gnome/gnome_login_screen/dconf_gnome_disable_user_list/policy/stig/shared.yml @@ -29,5 +29,3 @@ fixtext: |- $ sudo dconf update -vuln_discussion: |- - Leaving the user list enabled is a security risk since it allows anyone with physical access to the system to enumerate known user accounts without authenticated access to the system. diff --git a/linux_os/guide/system/software/gnome/gnome_login_screen/dconf_gnome_lock_screen_on_smartcard_removal/policy/stig/shared.yml b/linux_os/guide/system/software/gnome/gnome_login_screen/dconf_gnome_lock_screen_on_smartcard_removal/policy/stig/shared.yml index 1d69bd0533cf..e45faf935119 100644 --- a/linux_os/guide/system/software/gnome/gnome_login_screen/dconf_gnome_lock_screen_on_smartcard_removal/policy/stig/shared.yml +++ b/linux_os/guide/system/software/gnome/gnome_login_screen/dconf_gnome_lock_screen_on_smartcard_removal/policy/stig/shared.yml @@ -35,7 +35,3 @@ fixtext: |- Then update the dconf system databases: $ sudo dconf update -vuln_discussion: |- - A session lock is a temporary action taken when a user stops work and moves away from the immediate physical vicinity of the information system but does not want to log out because of the temporary nature of the absence. - - The session lock is implemented at the point where session activity can be determined. Rather than be forced to wait for a period of time to expire before the user session can be locked, {{{ full_name }}} needs to provide users with the ability to manually invoke a session lock so users can secure their session if it is necessary to temporarily vacate the immediate physical vicinity. diff --git a/linux_os/guide/system/software/gnome/gnome_login_screen/gnome_gdm_disable_automatic_login/policy/stig/shared.yml b/linux_os/guide/system/software/gnome/gnome_login_screen/gnome_gdm_disable_automatic_login/policy/stig/shared.yml index e24619d756b4..eca02ea735a9 100644 --- a/linux_os/guide/system/software/gnome/gnome_login_screen/gnome_gdm_disable_automatic_login/policy/stig/shared.yml +++ b/linux_os/guide/system/software/gnome/gnome_login_screen/gnome_gdm_disable_automatic_login/policy/stig/shared.yml @@ -26,5 +26,3 @@ fixtext: |- [daemon] AutomaticLoginEnable=false -vuln_discussion: |- - Failure to restrict system access to authenticated users negatively impacts operating system security. diff --git a/linux_os/guide/system/software/gnome/gnome_media_settings/dconf_gnome_disable_automount_open/policy/stig/shared.yml b/linux_os/guide/system/software/gnome/gnome_media_settings/dconf_gnome_disable_automount_open/policy/stig/shared.yml index a69bed77b708..65ec6e8176d0 100644 --- a/linux_os/guide/system/software/gnome/gnome_media_settings/dconf_gnome_disable_automount_open/policy/stig/shared.yml +++ b/linux_os/guide/system/software/gnome/gnome_media_settings/dconf_gnome_disable_automount_open/policy/stig/shared.yml @@ -2,7 +2,7 @@ srg_requirement: |- {{{ full_name }}} must prevent a user from overriding the disabling of the graphical user interface automount function. vuldiscussion: |- - Automatically mounting file systems permits easy introduction of unknown devices, thereby facilitating malicious activity. + A nonprivileged account is any operating system account with authorizations of a nonprivileged user. checktext: |- Verify {{{ full_name }}} disables ability of the user to override the graphical user interface automount setting. @@ -35,5 +35,3 @@ fixtext: |- Then update the dconf system databases: $ sudo dconf update -vuln_discussion: |- - A nonprivileged account is any operating system account with authorizations of a nonprivileged user. diff --git a/linux_os/guide/system/software/gnome/gnome_media_settings/dconf_gnome_disable_autorun/policy/stig/shared.yml b/linux_os/guide/system/software/gnome/gnome_media_settings/dconf_gnome_disable_autorun/policy/stig/shared.yml index a259c4b7b7fe..ca1d61318f7a 100644 --- a/linux_os/guide/system/software/gnome/gnome_media_settings/dconf_gnome_disable_autorun/policy/stig/shared.yml +++ b/linux_os/guide/system/software/gnome/gnome_media_settings/dconf_gnome_disable_autorun/policy/stig/shared.yml @@ -2,7 +2,7 @@ srg_requirement: |- {{{ full_name }}} must prevent a user from overriding the disabling of the graphical user interface autorun function. vuldiscussion: |- - Automatically running applications when media is inserted allows for the easy introduction of unknown data, thereby facilitating malicious activity. + Techniques used to address this include protocols using nonces (e.g., numbers generated for a specific one-time use) or challenges (e.g., TLS, WS_Security). Additional techniques include time-synchronous or challenge-response one-time authenticators. checktext: |- Verify {{{ full_name }}} disables ability of the user to override the graphical user interface autorun setting. @@ -35,5 +35,3 @@ fixtext: |- Then update the dconf system databases: $ sudo dconf update -vuln_discussion: |- - Techniques used to address this include protocols using nonces (e.g., numbers generated for a specific one-time use) or challenges (e.g., TLS, WS_Security). Additional techniques include time-synchronous or challenge-response one-time authenticators. diff --git a/linux_os/guide/system/software/gnome/gnome_screen_locking/dconf_gnome_screensaver_idle_delay/policy/stig/shared.yml b/linux_os/guide/system/software/gnome/gnome_screen_locking/dconf_gnome_screensaver_idle_delay/policy/stig/shared.yml index 7d89150a7756..29e2adbb1755 100644 --- a/linux_os/guide/system/software/gnome/gnome_screen_locking/dconf_gnome_screensaver_idle_delay/policy/stig/shared.yml +++ b/linux_os/guide/system/software/gnome/gnome_screen_locking/dconf_gnome_screensaver_idle_delay/policy/stig/shared.yml @@ -2,11 +2,7 @@ srg_requirement: |- {{{ full_name }}} must automatically lock graphical user sessions after 15 minutes of inactivity. vuldiscussion: |- - A session time-out lock is a temporary action taken when a user stops work and moves away from - the immediate physical vicinity of the information system but does not logout because of the - temporary nature of the absence. Rather than relying on the user to manually lock their operating - system session prior to vacating the vicinity, GNOME3 can be configured to identify when - a user's session has idled and take action to initiate a session lock. + A session time-out lock is a temporary action taken when a user stops work and moves away from the immediate physical vicinity of the information system but does not logout because of the temporary nature of the absence. Rather than relying on the user to manually lock their operating system session prior to vacating the vicinity, the GNOME desktop can be configured to identify when a user's session has idled and take action to initiate a session lock. checktext: |- Verify {{{ full_name }}} initiates a session lock after a 15-minute period of inactivity for graphical user interfaces with the following command: @@ -36,5 +32,3 @@ fixtext: |- $ sudo dconf update -vuln_discussion: |- - A session time-out lock is a temporary action taken when a user stops work and moves away from the immediate physical vicinity of the information system but does not logout because of the temporary nature of the absence. Rather than relying on the user to manually lock their operating system session prior to vacating the vicinity, the GNOME desktop can be configured to identify when a user's session has idled and take action to initiate a session lock. diff --git a/linux_os/guide/system/software/gnome/gnome_screen_locking/dconf_gnome_screensaver_lock_delay/policy/stig/shared.yml b/linux_os/guide/system/software/gnome/gnome_screen_locking/dconf_gnome_screensaver_lock_delay/policy/stig/shared.yml index b66a88f60b05..a45c2cb9ee46 100644 --- a/linux_os/guide/system/software/gnome/gnome_screen_locking/dconf_gnome_screensaver_lock_delay/policy/stig/shared.yml +++ b/linux_os/guide/system/software/gnome/gnome_screen_locking/dconf_gnome_screensaver_lock_delay/policy/stig/shared.yml @@ -2,8 +2,7 @@ srg_requirement: |- {{{ full_name }}} must initiate a session lock for graphical user interfaces when the screensaver is activated. vuldiscussion: |- - A session lock is a temporary action taken when a user stops work and moves away from the immediate physical vicinity - of the information system but does not want to logout because of the temporary nature of the absense. + A session lock is a temporary action taken when a user stops work and moves away from the immediate physical vicinity of the information system but does not want to logout because of the temporary nature of the absence. checktext: |- Verify {{{ full_name }}} initiates a session lock for graphical user interfaces when the screensaver is activated with the following command: @@ -34,5 +33,3 @@ fixtext: |- $ sudo dconf update -vuln_discussion: |- - A session lock is a temporary action taken when a user stops work and moves away from the immediate physical vicinity of the information system but does not want to logout because of the temporary nature of the absence. diff --git a/linux_os/guide/system/software/gnome/gnome_screen_locking/dconf_gnome_screensaver_lock_enabled/policy/stig/shared.yml b/linux_os/guide/system/software/gnome/gnome_screen_locking/dconf_gnome_screensaver_lock_enabled/policy/stig/shared.yml index 0f4b823d1359..abcafb31de69 100644 --- a/linux_os/guide/system/software/gnome/gnome_screen_locking/dconf_gnome_screensaver_lock_enabled/policy/stig/shared.yml +++ b/linux_os/guide/system/software/gnome/gnome_screen_locking/dconf_gnome_screensaver_lock_enabled/policy/stig/shared.yml @@ -2,11 +2,11 @@ srg_requirement: |- {{{ full_name }}} must prevent a user from overriding the screensaver lock-enabled setting for the graphical user interface. vuldiscussion: |- - A session lock is a temporary action taken when a user stops work and moves away from the immediate physical vicinity of the information system but does not want to log out because of the temporary nature of the absence. + A session time-out lock is a temporary action taken when a user stops work and moves away from the immediate physical vicinity of the information system but does not log out because of the temporary nature of the absence. Rather than relying on the user to manually lock their operating system session prior to vacating the vicinity, operating systems need to be able to identify when a user's session has idled and take action to initiate the session lock. - The session lock is implemented at the point where session activity can be determined. + The session lock is implemented at the point where session activity can be determined and/or controlled. - Regardless of where the session lock is determined and implemented, once invoked, the session lock must remain in place until the user reauthenticates. No other activity aside from reauthentication must unlock the system. + Implementing session settings will have little value if a user is able to manipulate these settings from the defaults prescribed in the other requirements of this implementation guide. checktext: |- Verify {{{ full_name }}} prevents a user from overriding settings for graphical user interfaces. @@ -41,9 +41,3 @@ fixtext: |- Add the following setting to prevent nonprivileged users from modifying it: /org/gnome/desktop/screensaver/lock-enabled -vuln_discussion: |- - A session time-out lock is a temporary action taken when a user stops work and moves away from the immediate physical vicinity of the information system but does not log out because of the temporary nature of the absence. Rather than relying on the user to manually lock their operating system session prior to vacating the vicinity, operating systems need to be able to identify when a user's session has idled and take action to initiate the session lock. - - The session lock is implemented at the point where session activity can be determined and/or controlled. - - Implementing session settings will have little value if a user is able to manipulate these settings from the defaults prescribed in the other requirements of this implementation guide. diff --git a/linux_os/guide/system/software/gnome/gnome_screen_locking/dconf_gnome_screensaver_mode_blank/policy/stig/shared.yml b/linux_os/guide/system/software/gnome/gnome_screen_locking/dconf_gnome_screensaver_mode_blank/policy/stig/shared.yml index 3d3982153638..ee08a8a8b5d5 100644 --- a/linux_os/guide/system/software/gnome/gnome_screen_locking/dconf_gnome_screensaver_mode_blank/policy/stig/shared.yml +++ b/linux_os/guide/system/software/gnome/gnome_screen_locking/dconf_gnome_screensaver_mode_blank/policy/stig/shared.yml @@ -34,5 +34,3 @@ checktext: |- If it is not set or configured properly, this is a finding. -vuln_discussion: |- - Setting the screensaver mode to blank-only conceals the contents of the display from passersby. diff --git a/linux_os/guide/system/software/gnome/gnome_screen_locking/dconf_gnome_screensaver_user_locks/policy/stig/shared.yml b/linux_os/guide/system/software/gnome/gnome_screen_locking/dconf_gnome_screensaver_user_locks/policy/stig/shared.yml index f5451329ad2a..1a5648d17667 100644 --- a/linux_os/guide/system/software/gnome/gnome_screen_locking/dconf_gnome_screensaver_user_locks/policy/stig/shared.yml +++ b/linux_os/guide/system/software/gnome/gnome_screen_locking/dconf_gnome_screensaver_user_locks/policy/stig/shared.yml @@ -2,11 +2,7 @@ srg_requirement: |- {{{ full_name }}} must prevent a user from overriding the session lock-delay setting for the graphical user interface. vuldiscussion: |- - A session time-out lock is a temporary action taken when a user stops work and moves away from the immediate - physical vicinity of the information system but does not logout because of the temporary nature of the absence. - Rather than relying on the user to manually lock their operating system session prior to vacating the vicinity, - GNOME desktops can be configured to identify when a user's session has idled and take action to initiate the - session lock. As such, users should not be allowed to change session settings. + A session time-out lock is a temporary action taken when a user stops work and moves away from the immediate physical vicinity of the information system but does not logout because of the temporary nature of the absence. Rather than relying on the user to manually lock their operating system session prior to vacating the vicinity, the GNOME desktop can be configured to identify when a user's session has idled and take action to initiate the session lock. As such, users should not be allowed to change session settings. checktext: |- Verify {{{ full_name }}} prevents a user from overriding settings for graphical user interfaces. @@ -42,5 +38,3 @@ fixtext: |- /org/gnome/desktop/screensaver/lock-delay -vuln_discussion: |- - A session time-out lock is a temporary action taken when a user stops work and moves away from the immediate physical vicinity of the information system but does not logout because of the temporary nature of the absence. Rather than relying on the user to manually lock their operating system session prior to vacating the vicinity, the GNOME desktop can be configured to identify when a user's session has idled and take action to initiate the session lock. As such, users should not be allowed to change session settings. diff --git a/linux_os/guide/system/software/gnome/gnome_screen_locking/dconf_gnome_session_idle_user_locks/policy/stig/shared.yml b/linux_os/guide/system/software/gnome/gnome_screen_locking/dconf_gnome_session_idle_user_locks/policy/stig/shared.yml index f6c2ae60e208..bb9356b7b3d6 100644 --- a/linux_os/guide/system/software/gnome/gnome_screen_locking/dconf_gnome_session_idle_user_locks/policy/stig/shared.yml +++ b/linux_os/guide/system/software/gnome/gnome_screen_locking/dconf_gnome_session_idle_user_locks/policy/stig/shared.yml @@ -2,11 +2,7 @@ srg_requirement: |- {{{ full_name }}} must prevent a user from overriding the session idle-delay setting for the graphical user interface. vuldiscussion: |- - A session time-out lock is a temporary action taken when a user stops work and moves away from the immediate - physical vicinity of the information system but does not logout because of the temporary nature of the absence. - Rather than relying on the user to manually lock their operating system session prior to vacating the vicinity, - GNOME desktops can be configured to identify when a user's session has idled and take action to initiate the - session lock. As such, users should not be allowed to change session settings. + A session time-out lock is a temporary action taken when a user stops work and moves away from the immediate physical vicinity of the information system but does not logout because of the temporary nature of the absence. Rather than relying on the user to manually lock their operating system session prior to vacating the vicinity, the GNOME desktop can be configured to identify when a user's session has idled and take action to initiate the session lock. As such, users should not be allowed to change session settings. checktext: |- Verify {{{ full_name }}} prevents a user from overriding settings for graphical user interfaces. @@ -42,5 +38,3 @@ fixtext: |- /org/gnome/desktop/session/idle-delay -vuln_discussion: |- - A session time-out lock is a temporary action taken when a user stops work and moves away from the immediate physical vicinity of the information system but does not logout because of the temporary nature of the absence. Rather than relying on the user to manually lock their operating system session prior to vacating the vicinity, the GNOME desktop can be configured to identify when a user's session has idled and take action to initiate the session lock. As such, users should not be allowed to change session settings. diff --git a/linux_os/guide/system/software/gnome/gnome_system_settings/dconf_gnome_disable_ctrlaltdel_reboot/policy/stig/shared.yml b/linux_os/guide/system/software/gnome/gnome_system_settings/dconf_gnome_disable_ctrlaltdel_reboot/policy/stig/shared.yml index 4aa735ff94cc..8f85965fc7af 100644 --- a/linux_os/guide/system/software/gnome/gnome_system_settings/dconf_gnome_disable_ctrlaltdel_reboot/policy/stig/shared.yml +++ b/linux_os/guide/system/software/gnome/gnome_system_settings/dconf_gnome_disable_ctrlaltdel_reboot/policy/stig/shared.yml @@ -2,10 +2,7 @@ srg_requirement: |- {{{ full_name }}} must prevent a user from overriding the Ctrl-Alt-Del sequence settings for the graphical user interface. vuldiscussion: |- - A locally logged-in user who presses Ctrl-Alt-Del, when at the console, - can reboot the system. If accidentally pressed, as could happen in - the case of mixed OS environment, this can create the risk of short-term - loss of availability of systems due to unintentional reboot. + A locally logged-in user who presses Ctrl-Alt-Del, when at the console, can reboot the system. If accidentally pressed, as could happen in the case of mixed OS environment, this can create the risk of short-term loss of availability of systems due to unintentional reboot. checktext: |- Verify that users cannot enable the Ctrl-Alt-Del sequence in the GNOME desktop with the following command: @@ -32,5 +29,3 @@ fixtext: |- Run the following command to update the database: $ sudo dconf update -vuln_discussion: |- - A locally logged-in user who presses Ctrl-Alt-Del, when at the console, can reboot the system. If accidentally pressed, as could happen in the case of mixed OS environment, this can create the risk of short-term loss of availability of systems due to unintentional reboot. diff --git a/linux_os/guide/system/software/integrity/certified-vendor/installed_OS_is_vendor_supported/policy/stig/shared.yml b/linux_os/guide/system/software/integrity/certified-vendor/installed_OS_is_vendor_supported/policy/stig/shared.yml index 669c1862d8c0..3be91d207377 100644 --- a/linux_os/guide/system/software/integrity/certified-vendor/installed_OS_is_vendor_supported/policy/stig/shared.yml +++ b/linux_os/guide/system/software/integrity/certified-vendor/installed_OS_is_vendor_supported/policy/stig/shared.yml @@ -4,9 +4,7 @@ srg_requirement: |- vuldiscussion: |- 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. - {{% if "Red Hat" in full_name %}} - Red Hat offers the Extended Update Support (EUS) ad-on to a Red Hat Enterprise Linux subscription, for a fee, for those customers who wish to standardize on a specific minor release for an extended period. - {{% endif %}} + Red Hat offers the Extended Update Support (EUS) add-on to a Red Hat Enterprise Linux subscription, for a fee, for those customers who wish to standardize on a specific minor release for an extended period. checktext: |- Verify that the version or {{{ full_name }}} is vendor supported with the following command: @@ -20,7 +18,3 @@ checktext: |- fixtext: |- Upgrade to a supported version of {{{ full_name }}}. -vuln_discussion: |- - 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. - - Red Hat offers the Extended Update Support (EUS) add-on to a Red Hat Enterprise Linux subscription, for a fee, for those customers who wish to standardize on a specific minor release for an extended period. diff --git a/linux_os/guide/system/software/integrity/crypto/configure_bind_crypto_policy/policy/stig/shared.yml b/linux_os/guide/system/software/integrity/crypto/configure_bind_crypto_policy/policy/stig/shared.yml index d6aa0476ee15..e34abfe6e9f2 100644 --- a/linux_os/guide/system/software/integrity/crypto/configure_bind_crypto_policy/policy/stig/shared.yml +++ b/linux_os/guide/system/software/integrity/crypto/configure_bind_crypto_policy/policy/stig/shared.yml @@ -26,9 +26,3 @@ fixtext: |- include "/etc/crypto-policies/back-ends/bind.config"; -vuln_discussion: |- - Without cryptographic integrity protections, information can be altered by unauthorized users without detection. - - 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. - - {{{ full_name }}} incorporates system-wide crypto policies by default. The employed algorithms can be viewed in the /etc/crypto-policies/back-ends/ directory. diff --git a/linux_os/guide/system/software/integrity/crypto/configure_crypto_policy/policy/stig/shared.yml b/linux_os/guide/system/software/integrity/crypto/configure_crypto_policy/policy/stig/shared.yml index 1388e726bf4c..7ab6eacd44f2 100644 --- a/linux_os/guide/system/software/integrity/crypto/configure_crypto_policy/policy/stig/shared.yml +++ b/linux_os/guide/system/software/integrity/crypto/configure_crypto_policy/policy/stig/shared.yml @@ -2,9 +2,7 @@ srg_requirement: |- {{{ full_name }}} must implement a system-wide encryption policy. vuldiscussion: |- - Centralized cryptographic policies simplify applying secure ciphers across an operating system and - the applications that run on that operating system. Use of weak or untested encryption algorithms - undermines the purposes of utilizing encryption to protect data. + Centralized cryptographic policies simplify applying secure ciphers across an operating system and the applications that run on that operating system. Use of weak or untested encryption algorithms undermines the purposes of utilizing encryption to protect data. checktext: |- Verify that the {{{ full_name }}} cryptography policy has been configured correctly with the following commands: @@ -28,5 +26,3 @@ fixtext: |- Reboot the system for the changes to take effect. -vuln_discussion: |- - Centralized cryptographic policies simplify applying secure ciphers across an operating system and the applications that run on that operating system. Use of weak or untested encryption algorithms undermines the purposes of utilizing encryption to protect data. diff --git a/linux_os/guide/system/software/integrity/crypto/configure_kerberos_crypto_policy/policy/stig/shared.yml b/linux_os/guide/system/software/integrity/crypto/configure_kerberos_crypto_policy/policy/stig/shared.yml index ff1ceef22d6e..37aef3c0c7e1 100644 --- a/linux_os/guide/system/software/integrity/crypto/configure_kerberos_crypto_policy/policy/stig/shared.yml +++ b/linux_os/guide/system/software/integrity/crypto/configure_kerberos_crypto_policy/policy/stig/shared.yml @@ -22,5 +22,3 @@ fixtext: |- $ sudo ln -s /etc/crypto-policies/back-ends/krb5.config /usr/share/crypto-policies/FIPS/krb5.txt -vuln_discussion: |- - Overriding the system crypto policy makes the behavior of Kerberos violate expectations, and makes system configuration more fragmented. diff --git a/linux_os/guide/system/software/integrity/crypto/configure_libreswan_crypto_policy/policy/stig/shared.yml b/linux_os/guide/system/software/integrity/crypto/configure_libreswan_crypto_policy/policy/stig/shared.yml index 1364939a852b..9945d36dffda 100644 --- a/linux_os/guide/system/software/integrity/crypto/configure_libreswan_crypto_policy/policy/stig/shared.yml +++ b/linux_os/guide/system/software/integrity/crypto/configure_libreswan_crypto_policy/policy/stig/shared.yml @@ -2,9 +2,7 @@ srg_requirement: |- {{{ full_name }}} IP tunnels must use FIPS 140-2/140-3 approved cryptographic algorithms. vuldiscussion: |- - Overriding the system crypto policy makes the behavior of the Libreswan - service violate expectations, and makes system configuration more - fragmented. + Overriding the system crypto policy makes the behavior of the Libreswan service violate expectations, and makes system configuration more fragmented. checktext: |- Verify that the IPsec service uses the system crypto policy with the following command: @@ -24,5 +22,3 @@ fixtext: |- include /etc/crypto-policies/back-ends/libreswan.config -vuln_discussion: |- - Overriding the system crypto policy makes the behavior of the Libreswan service violate expectations, and makes system configuration more fragmented. diff --git a/linux_os/guide/system/software/integrity/crypto/configure_openssl_crypto_policy/policy/stig/shared.yml b/linux_os/guide/system/software/integrity/crypto/configure_openssl_crypto_policy/policy/stig/shared.yml index 2e82da519614..c646df2f2b06 100644 --- a/linux_os/guide/system/software/integrity/crypto/configure_openssl_crypto_policy/policy/stig/shared.yml +++ b/linux_os/guide/system/software/integrity/crypto/configure_openssl_crypto_policy/policy/stig/shared.yml @@ -4,7 +4,7 @@ srg_requirement: |- vuldiscussion: |- 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. + Remote access (e.g., RDP) is access to DOD nonpublic information systems by an authorized user (or an information system) communicating through an external, nonorganization-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. @@ -26,11 +26,3 @@ fixtext: |- .include = /etc/crypto-policies/back-ends/opensslcnf.config -vuln_discussion: |- - 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, nonorganization-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. - - The employed algorithms can be viewed in the /etc/crypto-policies/back-ends/openssl.config file. diff --git a/linux_os/guide/system/software/integrity/crypto/configure_openssl_tls_crypto_policy/policy/stig/shared.yml b/linux_os/guide/system/software/integrity/crypto/configure_openssl_tls_crypto_policy/policy/stig/shared.yml index 00b37c66d8f0..d24dca347a24 100644 --- a/linux_os/guide/system/software/integrity/crypto/configure_openssl_tls_crypto_policy/policy/stig/shared.yml +++ b/linux_os/guide/system/software/integrity/crypto/configure_openssl_tls_crypto_policy/policy/stig/shared.yml @@ -4,7 +4,7 @@ srg_requirement: |- vuldiscussion: |- 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. + Remote access (e.g., RDP) is access to DOD nonpublic information systems by an authorized user (or an information system) communicating through an external, nonorganization-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. @@ -28,11 +28,3 @@ fixtext: |- A reboot is required for the changes to take effect. -vuln_discussion: |- - 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, nonorganization-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. - - The employed algorithms can be viewed in the /etc/crypto-policies/back-ends/openssl.config file. diff --git a/linux_os/guide/system/software/integrity/crypto/configure_ssh_crypto_policy/policy/stig/shared.yml b/linux_os/guide/system/software/integrity/crypto/configure_ssh_crypto_policy/policy/stig/shared.yml index 51be3aef1f6e..074ebb0c870e 100644 --- a/linux_os/guide/system/software/integrity/crypto/configure_ssh_crypto_policy/policy/stig/shared.yml +++ b/linux_os/guide/system/software/integrity/crypto/configure_ssh_crypto_policy/policy/stig/shared.yml @@ -2,19 +2,11 @@ srg_requirement: |- {{{ full_name }}} SSH daemon must be configured to use system-wide crypto policies. vuldiscussion: |- - Without cryptographic integrity protections, information can be altered - by unauthorized users without detection. + 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. + Remote access (e.g., RDP) is access to DOD nonpublic information systems by an authorized user (or an information system) communicating through an external, nonorganization-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. + 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. checktext: |- Verify that system-wide crypto policies are in effect with the following command: @@ -31,9 +23,3 @@ fixtext: |- $ sudo dnf reinstall openssh-server -vuln_discussion: |- - 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, nonorganization-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. diff --git a/linux_os/guide/system/software/integrity/crypto/harden_sshd_ciphers_opensshserver_conf_crypto_policy/policy/stig/shared.yml b/linux_os/guide/system/software/integrity/crypto/harden_sshd_ciphers_opensshserver_conf_crypto_policy/policy/stig/shared.yml index 56f82838226c..c00f87f57aa3 100644 --- a/linux_os/guide/system/software/integrity/crypto/harden_sshd_ciphers_opensshserver_conf_crypto_policy/policy/stig/shared.yml +++ b/linux_os/guide/system/software/integrity/crypto/harden_sshd_ciphers_opensshserver_conf_crypto_policy/policy/stig/shared.yml @@ -4,7 +4,7 @@ srg_requirement: |- vuldiscussion: |- 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. + Remote access (e.g., RDP) is access to DOD nonpublic information systems by an authorized user (or an information system) communicating through an external, nonorganization-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. @@ -26,11 +26,3 @@ fixtext: |- A reboot is required for the changes to take effect. -vuln_discussion: |- - 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, nonorganization-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. - - {{{ full_name }}} 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/opensshserver.config file. diff --git a/linux_os/guide/system/software/integrity/crypto/package_crypto-policies_installed/policy/stig/shared.yml b/linux_os/guide/system/software/integrity/crypto/package_crypto-policies_installed/policy/stig/shared.yml index 76b98074ec56..28a6535f62f6 100644 --- a/linux_os/guide/system/software/integrity/crypto/package_crypto-policies_installed/policy/stig/shared.yml +++ b/linux_os/guide/system/software/integrity/crypto/package_crypto-policies_installed/policy/stig/shared.yml @@ -2,9 +2,7 @@ srg_requirement: |- {{{ full_name }}} must have the crypto-policies package installed. vuldiscussion: |- - Centralized cryptographic policies simplify applying secure ciphers across an operating system and - the applications that run on that operating system. Use of weak or untested encryption algorithms - undermines the purposes of utilizing encryption to protect data. + Centralized cryptographic policies simplify applying secure ciphers across an operating system and the applications that run on that operating system. Use of weak or untested encryption algorithms undermines the purposes of utilizing encryption to protect data. checktext: |- Verify that {{{ full_name }}} crypto-policies package is installed with the following command: @@ -22,5 +20,3 @@ fixtext: |- $ sudo dnf install crypto-policies -vuln_discussion: |- - Centralized cryptographic policies simplify applying secure ciphers across an operating system and the applications that run on that operating system. Use of weak or untested encryption algorithms undermines the purposes of utilizing encryption to protect data. diff --git a/linux_os/guide/system/software/integrity/software-integrity/aide/aide_check_audit_tools/policy/stig/shared.yml b/linux_os/guide/system/software/integrity/software-integrity/aide/aide_check_audit_tools/policy/stig/shared.yml index 1375e79f4dd5..c1eede674742 100644 --- a/linux_os/guide/system/software/integrity/software-integrity/aide/aide_check_audit_tools/policy/stig/shared.yml +++ b/linux_os/guide/system/software/integrity/software-integrity/aide/aide_check_audit_tools/policy/stig/shared.yml @@ -2,25 +2,13 @@ srg_requirement: |- {{{ full_name }}} must use cryptographic mechanisms to protect the integrity of audit tools. vuldiscussion: |- - Protecting the integrity of the tools used for auditing purposes is a - critical step toward ensuring the integrity of audit information. Audit - information includes all information (e.g., audit records, audit settings, - and audit reports) needed to successfully audit information system - activity. - - Audit tools include, but are not limited to, vendor-provided and open-source - audit tools needed to successfully view and manipulate audit information - system activity and records. Audit tools include custom queries and report - generators. - - It is not uncommon for attackers to replace the audit tools or inject code - into the existing tools to provide the capability to hide or erase system - activity from the audit logs. - - To address this risk, audit tools must be cryptographically signed to - provide the capability to identify when the audit tools have been modified, - manipulated, or replaced. An example is a checksum hash of the file or - files. + Protecting the integrity of the tools used for auditing purposes is a critical step toward ensuring the integrity of audit information. Audit information includes all information (e.g., audit records, audit settings, and audit reports) needed to successfully audit information system activity. + + Audit tools include, but are not limited to, vendor-provided and open-source audit tools needed to successfully view and manipulate audit information system activity and records. Audit tools include custom queries and report generators. + + It is not uncommon for attackers to replace the audit tools or inject code into the existing tools to provide the capability to hide or erase system activity from the audit logs. + + To address this risk, audit tools must be cryptographically signed to provide the capability to identify when the audit tools have been modified, manipulated, or replaced. An example is a checksum hash of the file or files. checktext: |- Check that AIDE is properly configured to protect the integrity of the audit tools with the following command: @@ -48,11 +36,3 @@ fixtext: |- /usr/sbin/autrace p+i+n+u+g+s+b+acl+xattrs+sha512 /usr/sbin/augenrules p+i+n+u+g+s+b+acl+xattrs+sha512 -vuln_discussion: |- - Protecting the integrity of the tools used for auditing purposes is a critical step toward ensuring the integrity of audit information. Audit information includes all information (e.g., audit records, audit settings, and audit reports) needed to successfully audit information system activity. - - Audit tools include, but are not limited to, vendor-provided and open-source audit tools needed to successfully view and manipulate audit information system activity and records. Audit tools include custom queries and report generators. - - It is not uncommon for attackers to replace the audit tools or inject code into the existing tools to provide the capability to hide or erase system activity from the audit logs. - - To address this risk, audit tools must be cryptographically signed to provide the capability to identify when the audit tools have been modified, manipulated, or replaced. An example is a checksum hash of the file or files. diff --git a/linux_os/guide/system/software/integrity/software-integrity/aide/aide_use_fips_hashes/policy/stig/shared.yml b/linux_os/guide/system/software/integrity/software-integrity/aide/aide_use_fips_hashes/policy/stig/shared.yml index 44cb0f149e2d..47b0b6353d97 100644 --- a/linux_os/guide/system/software/integrity/software-integrity/aide/aide_use_fips_hashes/policy/stig/shared.yml +++ b/linux_os/guide/system/software/integrity/software-integrity/aide/aide_use_fips_hashes/policy/stig/shared.yml @@ -15,7 +15,3 @@ checktext: |- If the "sha512" rule is not being used on all uncommented selection lines in the "/etc/aide.conf" file, or another file integrity tool is not using FIPS 140-2/140-3-approved cryptographic hashes for validating file contents and directories, this is a finding. -vuln_discussion: |- - {{{ full_name }}} installation media ships with an optional file integrity tool called Advanced Intrusion Detection Environment (AIDE). AIDE is highly configurable at install time. This requirement assumes the "aide.conf" file is under the "/etc" directory. - - File integrity tools use cryptographic hashes for verifying file contents and directories have not been altered. These hashes must be FIPS 140-2/140-3-approved cryptographic hashes. diff --git a/linux_os/guide/system/software/integrity/software-integrity/aide/aide_verify_acls/policy/stig/shared.yml b/linux_os/guide/system/software/integrity/software-integrity/aide/aide_verify_acls/policy/stig/shared.yml index 753ab0dde3b2..f13728a42e2d 100644 --- a/linux_os/guide/system/software/integrity/software-integrity/aide/aide_verify_acls/policy/stig/shared.yml +++ b/linux_os/guide/system/software/integrity/software-integrity/aide/aide_verify_acls/policy/stig/shared.yml @@ -4,8 +4,7 @@ srg_requirement: |- vuldiscussion: |- {{{ full_name }}} installation media ships with an optional file integrity tool called Advanced Intrusion Detection Environment (AIDE). AIDE is highly configurable at install time. This requirement assumes the "aide.conf" file is under the "/etc" directory. - ACLs can provide permissions beyond those permitted through the file mode and must be - verified by the file integrity tools. + ACLs can provide permissions beyond those permitted through the file mode and must be verified by the file integrity tools. checktext: |- Verify that that AIDE is verifying ACLs with the following command: @@ -21,7 +20,3 @@ fixtext: |- If AIDE is installed, ensure the "acl" rule is present on all uncommented file and directory selection lists. -vuln_discussion: |- - {{{ full_name }}} installation media ships with an optional file integrity tool called Advanced Intrusion Detection Environment (AIDE). AIDE is highly configurable at install time. This requirement assumes the "aide.conf" file is under the "/etc" directory. - - ACLs can provide permissions beyond those permitted through the file mode and must be verified by the file integrity tools. diff --git a/linux_os/guide/system/software/integrity/software-integrity/aide/aide_verify_ext_attributes/policy/stig/shared.yml b/linux_os/guide/system/software/integrity/software-integrity/aide/aide_verify_ext_attributes/policy/stig/shared.yml index 50284b7ee266..1dfc08ad0a42 100644 --- a/linux_os/guide/system/software/integrity/software-integrity/aide/aide_verify_ext_attributes/policy/stig/shared.yml +++ b/linux_os/guide/system/software/integrity/software-integrity/aide/aide_verify_ext_attributes/policy/stig/shared.yml @@ -4,8 +4,7 @@ srg_requirement: |- vuldiscussion: |- {{{ full_name }}} installation media ships with an optional file integrity tool called Advanced Intrusion Detection Environment (AIDE). AIDE is highly configurable at install time. This requirement assumes the "aide.conf" file is under the "/etc" directory. - Extended attributes in file systems are used to contain arbitrary data and file metadata - with security implications. + Extended attributes in file systems are used to contain arbitrary data and file metadata with security implications. checktext: |- Verify that AIDE is configured to verify extended attributes with the following command: @@ -21,7 +20,3 @@ fixtext: |- If AIDE is installed, ensure the "xattrs" rule is present on all uncommented file and directory selection lists. -vuln_discussion: |- - {{{ full_name }}} installation media ships with an optional file integrity tool called Advanced Intrusion Detection Environment (AIDE). AIDE is highly configurable at install time. This requirement assumes the "aide.conf" file is under the "/etc" directory. - - Extended attributes in file systems are used to contain arbitrary data and file metadata with security implications. diff --git a/linux_os/guide/system/software/integrity/software-integrity/aide/file_audit_tools_group_ownership/policy/stig/shared.yml b/linux_os/guide/system/software/integrity/software-integrity/aide/file_audit_tools_group_ownership/policy/stig/shared.yml index 0af2d23c3780..770683389b4f 100644 --- a/linux_os/guide/system/software/integrity/software-integrity/aide/file_audit_tools_group_ownership/policy/stig/shared.yml +++ b/linux_os/guide/system/software/integrity/software-integrity/aide/file_audit_tools_group_ownership/policy/stig/shared.yml @@ -2,7 +2,7 @@ srg_requirement: |- {{{ full_name }}} audit tools must be group-owned by root. vuldiscussion: |- - 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. + 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. {{{ full_name }}} systems providing tools to interface with audit information will leverage user permissions and roles identifying the user accessing the tools, and the corresponding rights the user enjoys, to make access decisions regarding the access to audit tools. @@ -30,9 +30,3 @@ fixtext: |- Replace "[audit_tool]" with each audit tool not group-owned by "root". -vuln_discussion: |- - 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. - - {{{ full_name }}} systems providing tools to interface with audit information will leverage user permissions and roles identifying the user accessing the tools, and the corresponding rights the user enjoys, to make access decisions regarding the access to audit tools. - - Audit tools include, but are not limited to, vendor-provided and open source audit tools needed to successfully view and manipulate audit information system activity and records. Audit tools include custom queries and report generators. diff --git a/linux_os/guide/system/software/integrity/software-integrity/aide/file_audit_tools_ownership/policy/stig/shared.yml b/linux_os/guide/system/software/integrity/software-integrity/aide/file_audit_tools_ownership/policy/stig/shared.yml index 76a27c14c1a7..a89e56e2c760 100644 --- a/linux_os/guide/system/software/integrity/software-integrity/aide/file_audit_tools_ownership/policy/stig/shared.yml +++ b/linux_os/guide/system/software/integrity/software-integrity/aide/file_audit_tools_ownership/policy/stig/shared.yml @@ -30,9 +30,3 @@ fixtext: |- Replace "[audit_tool]" with each audit tool not owned by "root". -vuln_discussion: |- - 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. - - {{{ full_name }}} systems providing tools to interface with audit information will leverage user permissions and roles identifying the user accessing the tools, and the corresponding rights the user enjoys, to make access decisions regarding the access to audit tools. - - Audit tools include, but are not limited to, vendor-provided and open source audit tools needed to successfully view and manipulate audit information system activity and records. Audit tools include custom queries and report generators. diff --git a/linux_os/guide/system/software/integrity/software-integrity/aide/file_audit_tools_permissions/policy/stig/shared.yml b/linux_os/guide/system/software/integrity/software-integrity/aide/file_audit_tools_permissions/policy/stig/shared.yml index c9650f9ed39b..3f18c1a91111 100644 --- a/linux_os/guide/system/software/integrity/software-integrity/aide/file_audit_tools_permissions/policy/stig/shared.yml +++ b/linux_os/guide/system/software/integrity/software-integrity/aide/file_audit_tools_permissions/policy/stig/shared.yml @@ -30,9 +30,3 @@ fixtext: |- Replace "[audit_tool]" with each audit tool that has a more permissive mode than 0755. -vuln_discussion: |- - 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. - - {{{ full_name }}} systems providing tools to interface with audit information will leverage user permissions and roles identifying the user accessing the tools, and the corresponding rights the user enjoys, to make access decisions regarding the access to audit tools. - - Audit tools include, but are not limited to, vendor-provided and open source audit tools needed to successfully view and manipulate audit information system activity and records. Audit tools include custom queries and report generators. diff --git a/linux_os/guide/system/software/integrity/software-integrity/aide/package_aide_installed/policy/stig/shared.yml b/linux_os/guide/system/software/integrity/software-integrity/aide/package_aide_installed/policy/stig/shared.yml index bd291214bc94..b54ed6f014ae 100644 --- a/linux_os/guide/system/software/integrity/software-integrity/aide/package_aide_installed/policy/stig/shared.yml +++ b/linux_os/guide/system/software/integrity/software-integrity/aide/package_aide_installed/policy/stig/shared.yml @@ -71,5 +71,3 @@ fixtext: |- ... -vuln_discussion: |- - 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. diff --git a/linux_os/guide/system/software/sudo/package_sudo_installed/policy/stig/shared.yml b/linux_os/guide/system/software/sudo/package_sudo_installed/policy/stig/shared.yml index 21772bb6844b..6898fbb87809 100644 --- a/linux_os/guide/system/software/sudo/package_sudo_installed/policy/stig/shared.yml +++ b/linux_os/guide/system/software/sudo/package_sudo_installed/policy/stig/shared.yml @@ -2,10 +2,7 @@ srg_requirement: |- {{{ full_name }}} must have the sudo package installed. vuldiscussion: |- - "sudo" is a program designed to allow a system administrator to give - limited root privileges to users and log root activity. The basic philosophy - is to give as few privileges as possible but still allow system users to - get their work done. + "sudo" is a program designed to allow a system administrator to give limited root privileges to users and log root activity. The basic philosophy is to give as few privileges as possible but still allow system users to get their work done. checktext: |- Verify that {{{ full_name }}} sudo package is installed with the following command: @@ -23,5 +20,3 @@ fixtext: |- $ sudo dnf install sudo -vuln_discussion: |- - "sudo" is a program designed to allow a system administrator to give limited root privileges to users and log root activity. The basic philosophy is to give as few privileges as possible but still allow system users to get their work done. diff --git a/linux_os/guide/system/software/sudo/sudo_remove_no_authenticate/policy/stig/shared.yml b/linux_os/guide/system/software/sudo/sudo_remove_no_authenticate/policy/stig/shared.yml index 6b7030fb8bdf..09b736fd38f9 100644 --- a/linux_os/guide/system/software/sudo/sudo_remove_no_authenticate/policy/stig/shared.yml +++ b/linux_os/guide/system/software/sudo/sudo_remove_no_authenticate/policy/stig/shared.yml @@ -2,11 +2,9 @@ srg_requirement: |- {{{ full_name }}} must require users to reauthenticate for privilege escalation. vuldiscussion: |- - Without re-authentication, users may access resources or perform tasks for which they - do not have authorization. + 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 that the user re-authenticate. + When operating systems provide the capability to escalate a functional capability, it is critical that the user reauthenticate. checktext: |- Verify that "/etc/sudoers" has no occurrences of "!authenticate" with the following command: @@ -22,7 +20,3 @@ fixtext: |- $ sudo sed -i '/\!authenticate/ s/^/# /g' /etc/sudoers /etc/sudoers.d/* -vuln_discussion: |- - 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 that the user reauthenticate. diff --git a/linux_os/guide/system/software/sudo/sudo_remove_nopasswd/policy/stig/shared.yml b/linux_os/guide/system/software/sudo/sudo_remove_nopasswd/policy/stig/shared.yml index 404d85b84d90..68501345a743 100644 --- a/linux_os/guide/system/software/sudo/sudo_remove_nopasswd/policy/stig/shared.yml +++ b/linux_os/guide/system/software/sudo/sudo_remove_nopasswd/policy/stig/shared.yml @@ -2,11 +2,9 @@ srg_requirement: |- {{{ full_name }}} must require users to provide a password for privilege escalation. vuldiscussion: |- - Without re-authentication, users may access resources or perform tasks for which they - do not have authorization. + 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 that the user re-authenticate. + When operating systems provide the capability to escalate a functional capability, it is critical that the user reauthenticate. checktext: |- Verify that "/etc/sudoers" has no occurrences of "NOPASSWD" with the following command: @@ -22,7 +20,3 @@ fixtext: |- $ sudo sed -i '/NOPASSWD/ s/^/# /g' /etc/sudoers /etc/sudoers.d/* -vuln_discussion: |- - 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 that the user reauthenticate. diff --git a/linux_os/guide/system/software/sudo/sudo_require_reauthentication/policy/stig/shared.yml b/linux_os/guide/system/software/sudo/sudo_require_reauthentication/policy/stig/shared.yml index cca74b5dc572..34f0de1b9690 100644 --- a/linux_os/guide/system/software/sudo/sudo_require_reauthentication/policy/stig/shared.yml +++ b/linux_os/guide/system/software/sudo/sudo_require_reauthentication/policy/stig/shared.yml @@ -2,11 +2,11 @@ srg_requirement: |- {{{ full_name }}} must require reauthentication when using the "sudo" command. vuldiscussion: |- - Without re-authentication, users may access resources or perform tasks for which they do not have authorization. + 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 re-authenticate when using the "sudo" command. + 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 re-authenticate for privileged actions until the user's session is terminated. + 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. checktext: |- Verify {{{ full_name }}} requires reauthentication when using the "sudo" command to elevate privileges with the following command: @@ -26,9 +26,3 @@ fixtext: |- Defaults timestamp_timeout=0 -vuln_discussion: |- - 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. diff --git a/linux_os/guide/system/software/sudo/sudo_restrict_privilege_elevation_to_authorized/policy/stig/shared.yml b/linux_os/guide/system/software/sudo/sudo_restrict_privilege_elevation_to_authorized/policy/stig/shared.yml index 221c99695af9..4e0810f6d89d 100644 --- a/linux_os/guide/system/software/sudo/sudo_restrict_privilege_elevation_to_authorized/policy/stig/shared.yml +++ b/linux_os/guide/system/software/sudo/sudo_restrict_privilege_elevation_to_authorized/policy/stig/shared.yml @@ -2,8 +2,7 @@ srg_requirement: |- {{{ full_name }}} must restrict privilege elevation to authorized personnel. vuldiscussion: |- - If the "sudoers" file is not configured correctly, any user defined - on the system can initiate privileged actions on the target system. + If the "sudoers" file is not configured correctly, any user defined on the system can initiate privileged actions on the target system. checktext: |- Verify {{{ full_name }}} restricts privilege elevation to authorized personnel with the following command: @@ -20,5 +19,3 @@ fixtext: |- ALL ALL=(ALL) ALL ALL ALL=(ALL:ALL) ALL -vuln_discussion: |- - If the "sudoers" file is not configured correctly, any user defined on the system can initiate privileged actions on the target system. diff --git a/linux_os/guide/system/software/sudo/sudoers_validate_passwd/policy/stig/shared.yml b/linux_os/guide/system/software/sudo/sudoers_validate_passwd/policy/stig/shared.yml index 1a04f177893c..c47391bf88bd 100644 --- a/linux_os/guide/system/software/sudo/sudoers_validate_passwd/policy/stig/shared.yml +++ b/linux_os/guide/system/software/sudo/sudoers_validate_passwd/policy/stig/shared.yml @@ -2,8 +2,7 @@ srg_requirement: |- {{{ full_name }}} must use the invoking user's password for privilege escalation when using "sudo". vuldiscussion: |- - If the rootpw, targetpw, or runaspw flags are defined and not disabled, by default the operating system will prompt - the invoking user for the "root" user password. + If the rootpw, targetpw, or runaspw flags are defined and not disabled, by default the operating system will prompt the invoking user for the "root" user password. checktext: |- Verify that the sudoers security policy is configured to use the invoking user's password for privilege escalation with the following command: @@ -31,5 +30,3 @@ fixtext: |- Defaults !rootpw Defaults !runaspw -vuln_discussion: |- - If the rootpw, targetpw, or runaspw flags are defined and not disabled, by default the operating system will prompt the invoking user for the "root" user password. diff --git a/linux_os/guide/system/software/system-tools/package_gnutls-utils_installed/policy/stig/shared.yml b/linux_os/guide/system/software/system-tools/package_gnutls-utils_installed/policy/stig/shared.yml index 6fd27f149d63..89e16597f4a1 100644 --- a/linux_os/guide/system/software/system-tools/package_gnutls-utils_installed/policy/stig/shared.yml +++ b/linux_os/guide/system/software/system-tools/package_gnutls-utils_installed/policy/stig/shared.yml @@ -2,13 +2,7 @@ srg_requirement: |- {{{ full_name }}} must have the gnutls-utils package installed. vuldiscussion: |- - GnuTLS is a secure communications library implementing the SSL, TLS and DTLS - protocols and technologies around them. It provides a simple C language - application programming interface (API) to access the secure communications - protocols as well as APIs to parse and write X.509, PKCS #12, OpenPGP and - other required structures. - This package contains command line TLS client and server and certificate - manipulation tools. + GnuTLS is a secure communications library implementing the SSL, TLS and DTLS protocols and technologies around them. It provides a simple C language application programming interface (API) to access the secure communications protocols as well as APIs to parse and write X.509, PKCS #12, OpenPGP and other required structures. This package contains command line TLS client and server and certificate manipulation tools. checktext: |- Verify that {{{ full_name }}} has the gnutls-utils package installed with the following command: @@ -26,5 +20,3 @@ fixtext: |- $ sudo dnf install gnutls-utils -vuln_discussion: |- - GnuTLS is a secure communications library implementing the SSL, TLS and DTLS protocols and technologies around them. It provides a simple C language application programming interface (API) to access the secure communications protocols as well as APIs to parse and write X.509, PKCS #12, OpenPGP and other required structures. This package contains command line TLS client and server and certificate manipulation tools. diff --git a/linux_os/guide/system/software/system-tools/package_gssproxy_removed/policy/stig/shared.yml b/linux_os/guide/system/software/system-tools/package_gssproxy_removed/policy/stig/shared.yml index b4cd2faa2aba..68d8b6d4d0d4 100644 --- a/linux_os/guide/system/software/system-tools/package_gssproxy_removed/policy/stig/shared.yml +++ b/linux_os/guide/system/software/system-tools/package_gssproxy_removed/policy/stig/shared.yml @@ -2,9 +2,9 @@ srg_requirement: |- {{{ full_name }}} must not have the gssproxy package installed. vuldiscussion: |- - 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. + 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). + 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). The gssproxy package is a proxy for GSS API credential handling and could expose secrets on some networks. It is not needed for normal function of the OS. @@ -22,9 +22,3 @@ fixtext: |- $ sudo dnf remove gssproxy -vuln_discussion: |- - 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). - - The gssproxy package is a proxy for GSS API credential handling and could expose secrets on some networks. It is not needed for normal function of the OS. diff --git a/linux_os/guide/system/software/system-tools/package_iprutils_removed/policy/stig/shared.yml b/linux_os/guide/system/software/system-tools/package_iprutils_removed/policy/stig/shared.yml index fb44fc8b8b87..dcce9a5d9f4a 100644 --- a/linux_os/guide/system/software/system-tools/package_iprutils_removed/policy/stig/shared.yml +++ b/linux_os/guide/system/software/system-tools/package_iprutils_removed/policy/stig/shared.yml @@ -22,9 +22,3 @@ fixtext: |- $ sudo dnf remove iprutils -vuln_discussion: |- - 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). - - The iprutils package provides a suite of utilities to manage and configure SCSI devices supported by the ipr SCSI storage device driver. diff --git a/linux_os/guide/system/software/system-tools/package_nss-tools_installed/policy/stig/shared.yml b/linux_os/guide/system/software/system-tools/package_nss-tools_installed/policy/stig/shared.yml index c21865111696..79bb7802e5e4 100644 --- a/linux_os/guide/system/software/system-tools/package_nss-tools_installed/policy/stig/shared.yml +++ b/linux_os/guide/system/software/system-tools/package_nss-tools_installed/policy/stig/shared.yml @@ -2,11 +2,7 @@ srg_requirement: |- {{{ full_name }}} must have the nss-tools package installed. vuldiscussion: |- - Network Security Services (NSS) is a set of libraries designed to - support cross-platform development of security-enabled client and - server applications. Install the "nss-tools" package - to install command-line tools to manipulate the NSS certificate - and key database. + Network Security Services (NSS) is a set of libraries designed to support cross-platform development of security-enabled client and server applications. Install the "nss-tools" package to install command-line tools to manipulate the NSS certificate and key database. checktext: |- Verify that {{{ full_name }}} has the nss-tools package installed with the following command: @@ -24,5 +20,3 @@ fixtext: |- $ sudo dnf install nss-tools -vuln_discussion: |- - Network Security Services (NSS) is a set of libraries designed to support cross-platform development of security-enabled client and server applications. Install the "nss-tools" package to install command-line tools to manipulate the NSS certificate and key database. diff --git a/linux_os/guide/system/software/system-tools/package_rng-tools_installed/policy/stig/shared.yml b/linux_os/guide/system/software/system-tools/package_rng-tools_installed/policy/stig/shared.yml index ea72ff587e4d..3ff219938cc6 100644 --- a/linux_os/guide/system/software/system-tools/package_rng-tools_installed/policy/stig/shared.yml +++ b/linux_os/guide/system/software/system-tools/package_rng-tools_installed/policy/stig/shared.yml @@ -2,8 +2,7 @@ srg_requirement: |- {{{ full_name }}} must have the rng-tools package installed. vuldiscussion: |- - "rng-tools" provides hardware random number generator tools, - such as those used in the formation of x509/PKI certificates. + "rng-tools" provides hardware random number generator tools, such as those used in the formation of x509/PKI certificates. checktext: |- Verify that {{{ full_name }}} has the rng-tools package installed with the following command: @@ -21,5 +20,3 @@ fixtext: |- $ sudo dnf install rng-tools -vuln_discussion: |- - "rng-tools" provides hardware random number generator tools, such as those used in the formation of x509/PKI certificates. diff --git a/linux_os/guide/system/software/system-tools/package_subscription-manager_installed/policy/stig/shared.yml b/linux_os/guide/system/software/system-tools/package_subscription-manager_installed/policy/stig/shared.yml index 489333fef364..ed2a7da665c9 100644 --- a/linux_os/guide/system/software/system-tools/package_subscription-manager_installed/policy/stig/shared.yml +++ b/linux_os/guide/system/software/system-tools/package_subscription-manager_installed/policy/stig/shared.yml @@ -2,17 +2,7 @@ srg_requirement: |- {{{ full_name }}} subscription-manager package must be installed. vuldiscussion: |- - Red Hat Subscription Manager is a local service which tracks installed products - and subscriptions on a local system to help manage subscription assignments. - It communicates with the backend subscription service (the Customer Portal - or an on-premise server such as Subscription Asset Manager) and works with - content management tools such as . - - - The package provides, among other things, plugins - to interact with repositories and subscriptions - from the Red Hat entitlement platform - the subscription-manager and - product-id plugins. + The Red Hat Subscription Manager application manages software subscriptions and software repositories for installed software products on the local system. It communicates with backend servers, such as the Red Hat Customer Portal or an on-premise instance of Subscription Asset Manager, to register the local system and grant access to software resources determined by the subscription entitlement. checktext: |- Verify that {{{ full_name }}} subscription-manager package is installed with the following command: @@ -30,5 +20,3 @@ fixtext: |- $ sudo dnf install subscription-manager -vuln_discussion: |- - The Red Hat Subscription Manager application manages software subscriptions and software repositories for installed software products on the local system. It communicates with backend servers, such as the Red Hat Customer Portal or an on-premise instance of Subscription Asset Manager, to register the local system and grant access to software resources determined by the subscription entitlement. diff --git a/linux_os/guide/system/software/system-tools/package_tuned_removed/policy/stig/shared.yml b/linux_os/guide/system/software/system-tools/package_tuned_removed/policy/stig/shared.yml index d2b7d58f3282..008ec50ef7d0 100644 --- a/linux_os/guide/system/software/system-tools/package_tuned_removed/policy/stig/shared.yml +++ b/linux_os/guide/system/software/system-tools/package_tuned_removed/policy/stig/shared.yml @@ -22,9 +22,3 @@ fixtext: |- $ sudo dnf remove tuned -vuln_discussion: |- - 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). - - The tuned package contains a daemon that tunes the system settings dynamically. It does so by monitoring the usage of several system components periodically. Based on that information, components will then be put into lower or higher power savings modes to adapt to the current usage. The tuned package is not needed for normal OS operations. diff --git a/linux_os/guide/system/software/updating/clean_components_post_updating/policy/stig/shared.yml b/linux_os/guide/system/software/updating/clean_components_post_updating/policy/stig/shared.yml index a6b5d52b4e2e..f8765e202505 100644 --- a/linux_os/guide/system/software/updating/clean_components_post_updating/policy/stig/shared.yml +++ b/linux_os/guide/system/software/updating/clean_components_post_updating/policy/stig/shared.yml @@ -20,5 +20,3 @@ fixtext: |- clean_requirements_on_remove=1 -vuln_discussion: |- - Previous versions of software components that are not removed from the information system after updates have been installed may be exploited by some adversaries. diff --git a/linux_os/guide/system/software/updating/ensure_gpgcheck_globally_activated/policy/stig/shared.yml b/linux_os/guide/system/software/updating/ensure_gpgcheck_globally_activated/policy/stig/shared.yml index b4aec6f33beb..b4b2d0980969 100644 --- a/linux_os/guide/system/software/updating/ensure_gpgcheck_globally_activated/policy/stig/shared.yml +++ b/linux_os/guide/system/software/updating/ensure_gpgcheck_globally_activated/policy/stig/shared.yml @@ -4,9 +4,9 @@ srg_requirement: |- vuldiscussion: |- 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. + All software packages must be signed with a cryptographic key 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 verifies 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 CA. + Verifying the authenticity of software prior to installation validates the integrity of the software package received from a vendor. This verifies the software has not been tampered with and that it has been provided by a trusted vendor. checktext: |- Verify that dnf always checks the GPG signature of software packages originating from external software repositories before installation: @@ -26,9 +26,3 @@ fixtext: |- gpgcheck=1 -vuln_discussion: |- - 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. - - All software packages must be signed with a cryptographic key recognized and approved by the organization. - - Verifying the authenticity of software prior to installation validates the integrity of the software package received from a vendor. This verifies the software has not been tampered with and that it has been provided by a trusted vendor. diff --git a/linux_os/guide/system/software/updating/ensure_gpgcheck_local_packages/policy/stig/shared.yml b/linux_os/guide/system/software/updating/ensure_gpgcheck_local_packages/policy/stig/shared.yml index ec796b00b6bf..42d535534ee3 100644 --- a/linux_os/guide/system/software/updating/ensure_gpgcheck_local_packages/policy/stig/shared.yml +++ b/linux_os/guide/system/software/updating/ensure_gpgcheck_local_packages/policy/stig/shared.yml @@ -4,9 +4,9 @@ srg_requirement: |- vuldiscussion: |- 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. + All software packages must be signed with a cryptographic key 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 verifies 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 CA. + Verifying the authenticity of software prior to installation validates the integrity of the software package received from a vendor. This verifies the software has not been tampered with and that it has been provided by a trusted vendor. checktext: |- Verify that dnf always checks the GPG signature of locally installed software packages before installation: @@ -26,9 +26,3 @@ fixtext: |- localpkg_gpgcheck=1 -vuln_discussion: |- - 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. - - All software packages must be signed with a cryptographic key recognized and approved by the organization. - - Verifying the authenticity of software prior to installation validates the integrity of the software package received from a vendor. This verifies the software has not been tampered with and that it has been provided by a trusted vendor. diff --git a/linux_os/guide/system/software/updating/ensure_gpgcheck_never_disabled/policy/stig/shared.yml b/linux_os/guide/system/software/updating/ensure_gpgcheck_never_disabled/policy/stig/shared.yml index 11d76cafc784..b6ac3cc313bc 100644 --- a/linux_os/guide/system/software/updating/ensure_gpgcheck_never_disabled/policy/stig/shared.yml +++ b/linux_os/guide/system/software/updating/ensure_gpgcheck_never_disabled/policy/stig/shared.yml @@ -4,9 +4,9 @@ srg_requirement: |- vuldiscussion: |- 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. + All software packages must be signed with a cryptographic key 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 verifies 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 CA. + Verifying the authenticity of software prior to installation validates the integrity of the software package received from a vendor. This verifies the software has not been tampered with and that it has been provided by a trusted vendor. checktext: |- Verify that all software repositories defined in "/etc/yum.repos.d/" have been configured with "gpgcheck" enabled: @@ -22,9 +22,3 @@ fixtext: |- $ sudo sed -i 's/gpgcheck\s*=.*/gpgcheck=1/g' /etc/yum.repos.d/* -vuln_discussion: |- - 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. - - All software packages must be signed with a cryptographic key recognized and approved by the organization. - - Verifying the authenticity of software prior to installation validates the integrity of the software package received from a vendor. This verifies the software has not been tampered with and that it has been provided by a trusted vendor. diff --git a/linux_os/guide/system/software/updating/ensure_redhat_gpgkey_installed/policy/stig/shared.yml b/linux_os/guide/system/software/updating/ensure_redhat_gpgkey_installed/policy/stig/shared.yml index 115873b3d2b1..732fbafc1254 100644 --- a/linux_os/guide/system/software/updating/ensure_redhat_gpgkey_installed/policy/stig/shared.yml +++ b/linux_os/guide/system/software/updating/ensure_redhat_gpgkey_installed/policy/stig/shared.yml @@ -2,11 +2,7 @@ srg_requirement: |- {{{ full_name }}} must ensure cryptographic verification of vendor software packages. vuldiscussion: |- - 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 verifies 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 Red Hat. + Cryptographic verification of vendor software packages ensures that all software packages are obtained from a valid source and protects against spoofing that could lead to installation of malware on the system. Red Hat cryptographically signs all software packages, which includes updates, with a GPG key to verify that they are valid. checktext: |- Confirm Red Hat package-signing keys are installed on the system and verify their fingerprints match vendor values. @@ -56,5 +52,3 @@ fixtext: |- Using the steps listed in the Check Text, confirm the newly imported keys show as installed on the system and verify their fingerprints match vendor values. -vuln_discussion: |- - Cryptographic verification of vendor software packages ensures that all software packages are obtained from a valid source and protects against spoofing that could lead to installation of malware on the system. Red Hat cryptographically signs all software packages, which includes updates, with a GPG key to verify that they are valid. diff --git a/linux_os/guide/system/software/updating/security_patches_up_to_date/policy/stig/shared.yml b/linux_os/guide/system/software/updating/security_patches_up_to_date/policy/stig/shared.yml index c90f4f7819fc..df3ff4eedce2 100644 --- a/linux_os/guide/system/software/updating/security_patches_up_to_date/policy/stig/shared.yml +++ b/linux_os/guide/system/software/updating/security_patches_up_to_date/policy/stig/shared.yml @@ -9,11 +9,7 @@ srg_requirement: |- {{{ full_name }}} vendor packaged system security patches and updates must be installed and up to date. vuldiscussion: |- - Installing software updates is a fundamental mitigation against - the exploitation of publicly-known vulnerabilities. If the most - recent security patches and updates are not installed, unauthorized - users may take advantage of weaknesses in the unpatched software. The - lack of prompt attention to patching could result in a system compromise. + Installing software updates is a fundamental mitigation against the exploitation of publicly known vulnerabilities. If the most recent security patches and updates are not installed, unauthorized users may take advantage of weaknesses in the unpatched software. The lack of prompt attention to patching could result in a system compromise. checktext: |- Verify {{{ full_name }}} security patches and updates are installed and up to date. Updates are required to be applied with a frequency determined by organizational policy. @@ -40,5 +36,3 @@ fixtext: |- $ sudo dnf update -vuln_discussion: |- - Installing software updates is a fundamental mitigation against the exploitation of publicly known vulnerabilities. If the most recent security patches and updates are not installed, unauthorized users may take advantage of weaknesses in the unpatched software. The lack of prompt attention to patching could result in a system compromise.