Group
Guide to the Secure Configuration of Red Hat Enterprise Linux 9
Group contains 46 groups and 144 rules |
Group
System Settings
Group contains 37 groups and 124 rules |
[ref]
Contains rules that check correct system settings. |
Group
Installing and Maintaining Software
Group contains 7 groups and 19 rules |
[ref]
The following sections contain information on
security-relevant choices during the initial operating system
installation process and the setup of software
updates. |
Group
System and Software Integrity
Group contains 2 groups and 6 rules |
[ref]
System and software integrity can be gained by installing antivirus, increasing
system encryption strength with FIPS, verifying installed software, enabling SELinux,
installing an Intrusion Prevention System, etc. However, installing or enabling integrity
checking tools cannot prevent intrusions, but they can detect that an intrusion
may have occurred. Requirements for integrity checking may be highly dependent on
the environment in which the system will be used. Snapshot-based approaches such
as AIDE may induce considerable overhead in the presence of frequent software updates. |
Group
Federal Information Processing Standard (FIPS)
Group contains 2 rules |
[ref]
The Federal Information Processing Standard (FIPS) is a computer security standard which
is developed by the U.S. Government and industry working groups to validate the quality
of cryptographic modules. The FIPS standard provides four security levels to ensure
adequate coverage of different industries, implementation of cryptographic modules, and
organizational sizes and requirements.
FIPS 140-2 is the current standard for validating that mechanisms used to access cryptographic modules
utilize authentication that meets industry and government requirements. For government systems, this allows
Security Levels 1, 2, 3, or 4 for use on Red Hat Enterprise Linux 9.
See http://csrc.nist.gov/publications/PubsFIPS.html for more information. |
Rule
Enable Dracut FIPS Module
[ref] | To enable FIPS mode, run the following command:
fips-mode-setup --enable
To enable FIPS, the system requires that the fips module is added in dracut configuration.
Check if /etc/dracut.conf.d/40-fips.conf contain add_dracutmodules+=" fips " Warning:
The system needs to be rebooted for these changes to take effect. Warning:
System Crypto Modules must be provided by a vendor that undergoes FIPS-140 certifications.
FIPS-140 is applicable to all Federal agencies that use cryptographic-based security
systems to protect sensitive information in computer and telecommunication systems
(including voice systems) as defined in Section 5131 of the Information Technology
Management Reform Act of 1996, Public Law 104-106. This standard shall be used in designing
and implementing cryptographic modules that Federal departments and agencies operate or are
operated for them under contract.
See https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.140-2.pdf
To meet this, the system has to have cryptographic software provided by a vendor that has
undergone this certification. This means providing documentation, test results, design
information, and independent third party review by an accredited lab. While open source
software is capable of meeting this, it does not meet FIPS-140 unless the vendor submits to
this process. | Rationale: | Use of weak or untested encryption algorithms undermines the purposes of utilizing encryption to
protect data. The operating system must implement cryptographic modules adhering to the higher
standards approved by the federal government since this provides assurance they have been tested
and validated. | Severity: | high | Rule ID: | xccdf_org.ssgproject.content_rule_enable_dracut_fips_module | Identifiers and References | Identifiers:
CCE-86547-7 References:
CCI-000068, CCI-000803, CCI-002450, 1446, CIP-003-8 R4.2, CIP-007-3 R5.1, SC-12(2), SC-12(3), IA-7, SC-13, CM-6(a), SC-12, FCS_RBG_EXT.1, SRG-OS-000478-GPOS-00223 | |
|
Rule
Enable FIPS Mode
[ref] |
To enable FIPS mode, run the following command:
fips-mode-setup --enable
The fips-mode-setup command will configure the system in
FIPS mode by automatically configuring the following:
- Setting the kernel FIPS mode flag (
/proc/sys/crypto/fips_enabled ) to 1 - Creating
/etc/system-fips - Setting the system crypto policy in
/etc/crypto-policies/config to FIPS:OSPP - Loading the Dracut
fips module
Warning:
The system needs to be rebooted for these changes to take effect. | Rationale: | Use of weak or untested encryption algorithms undermines the purposes of utilizing encryption to
protect data. The operating system must implement cryptographic modules adhering to the higher
standards approved by the federal government since this provides assurance they have been tested
and validated. | Severity: | high | Rule ID: | xccdf_org.ssgproject.content_rule_enable_fips_mode | Identifiers and References | Identifiers:
CCE-88742-2 References:
CCI-000068, CCI-000803, CCI-002450, 1446, CIP-003-8 R4.2, CIP-007-3 R5.1, CM-3(6), SC-12(2), SC-12(3), IA-7, SC-13, CM-6(a), SC-12, FCS_COP.1(1), FCS_COP.1(2), FCS_COP.1(3), FCS_COP.1(4), FCS_CKM.1, FCS_CKM.2, FCS_TLSC_EXT.1, FCS_RBG_EXT.1, SRG-OS-000478-GPOS-00223, SRG-OS-000396-GPOS-00176 | |
|
Group
System Cryptographic Policies
Group contains 4 rules |
[ref]
Linux has the capability to centrally configure cryptographic polices. The command
update-crypto-policies is used to set the policy applicable for the various
cryptographic back-ends, such as SSL/TLS libraries. The configured cryptographic
policies will be the default policy used by these backends unless the application
user configures them otherwise. When the system has been configured to use the
centralized cryptographic policies, the administrator is assured that any application
that utilizes the supported backends will follow a policy that adheres to the
configured profile.
Currently the supported backends are:
- GnuTLS library
- OpenSSL library
- NSS library
- OpenJDK
- Libkrb5
- BIND
- OpenSSH
Applications and languages which rely on any of these backends will follow the
system policies as well. Examples are apache httpd, nginx, php, and others. |
|
Rule
Configure System Cryptography Policy
[ref] | To configure the system cryptography policy to use ciphers only from the FIPS:OSPP
policy, run the following command:
$ sudo update-crypto-policies --set FIPS:OSPP
The rule checks if settings for selected crypto policy are configured as expected. Configuration files in the /etc/crypto-policies/back-ends are either symlinks to correct files provided by Crypto-policies package or they are regular files in case crypto policy customizations are applied.
Crypto policies may be customized by crypto policy modules, in which case it is delimited from the base policy using a colon. Warning:
The system needs to be rebooted for these changes to take effect. Warning:
System Crypto Modules must be provided by a vendor that undergoes
FIPS-140 certifications.
FIPS-140 is applicable to all Federal agencies that use
cryptographic-based security systems to protect sensitive information
in computer and telecommunication systems (including voice systems) as
defined in Section 5131 of the Information Technology Management Reform
Act of 1996, Public Law 104-106. This standard shall be used in
designing and implementing cryptographic modules that Federal
departments and agencies operate or are operated for them under
contract. See https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.140-2.pdf
To meet this, the system has to have cryptographic software provided by
a vendor that has undergone this certification. This means providing
documentation, test results, design information, and independent third
party review by an accredited lab. While open source software is
capable of meeting this, it does not meet FIPS-140 unless the vendor
submits to this process. | Rationale: | 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. | Severity: | high | Rule ID: | xccdf_org.ssgproject.content_rule_configure_crypto_policy | Identifiers and References | Identifiers:
CCE-83450-7 References:
164.308(a)(4)(i), 164.308(b)(1), 164.308(b)(3), 164.312(e)(1), 164.312(e)(2)(ii), 1446, CIP-003-8 R4.2, CIP-007-3 R5.1, CIP-007-3 R7.1, AC-17(a), AC-17(2), CM-6(a), MA-4(6), SC-13, SC-12(2), SC-12(3), FCS_COP.1(1), FCS_COP.1(2), FCS_COP.1(3), FCS_COP.1(4), FCS_CKM.1, FCS_CKM.2, FCS_TLSC_EXT.1, SRG-OS-000396-GPOS-00176, SRG-OS-000393-GPOS-00173, SRG-OS-000394-GPOS-00174, 1.10 | |
|
Rule
Configure OpenSSL library to use System Crypto Policy
[ref] | Crypto Policies provide a centralized control over crypto algorithms usage of many packages.
OpenSSL is supported by crypto policy, but the OpenSSL configuration may be
set up to ignore it.
To check that Crypto Policies settings are configured correctly, you have to examine the OpenSSL config file
available under /etc/pki/tls/openssl.cnf .
This file has the ini format, and it enables crypto policy support
if there is a [ crypto_policy ] section that contains the .include = /etc/crypto-policies/back-ends/opensslcnf.config directive. | Rationale: | Overriding the system crypto policy makes the behavior of the Java runtime violates expectations,
and makes system configuration more fragmented. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_configure_openssl_crypto_policy | Identifiers and References | Identifiers:
CCE-83452-3 References:
CCI-001453, CIP-003-8 R4.2, CIP-007-3 R5.1, CIP-007-3 R7.1, AC-17(a), AC-17(2), CM-6(a), MA-4(6), SC-13, SC-12(2), SC-12(3), Req-2.2, 2.2, SRG-OS-000250-GPOS-00093 | |
|
Rule
Configure SSH to use System Crypto Policy
[ref] | Crypto Policies provide a centralized control over crypto algorithms usage of many packages.
SSH is supported by crypto policy, but the SSH configuration may be
set up to ignore it.
To check that Crypto Policies settings are configured correctly, ensure that
the CRYPTO_POLICY variable is either commented or not set at all
in the /etc/sysconfig/sshd . | Rationale: | Overriding the system crypto policy makes the behavior of the SSH service violate expectations,
and makes system configuration more fragmented. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_configure_ssh_crypto_policy | Identifiers and References | Identifiers:
CCE-83445-7 References:
CCI-001453, 164.308(a)(4)(i), 164.308(b)(1), 164.308(b)(3), 164.312(e)(1), 164.312(e)(2)(ii), CIP-003-8 R4.2, CIP-007-3 R5.1, CIP-007-3 R7.1, AC-17(a), AC-17(2), CM-6(a), MA-4(6), SC-13, FCS_SSH_EXT.1, FCS_SSHS_EXT.1, FCS_SSHC_EXT.1, Req-2.2, 2.2, SRG-OS-000250-GPOS-00093, 5.2.14 | |
|
Group
Disk Partitioning
Group contains 1 rule |
[ref]
To ensure separation and protection of data, there
are top-level system directories which should be placed on their
own physical partition or logical volume. The installer's default
partitioning scheme creates separate logical volumes for
/ , /boot , and swap .
- If starting with any of the default layouts, check the box to
\"Review and modify partitioning.\" This allows for the easy creation
of additional logical volumes inside the volume group already
created, though it may require making
/ 's logical volume smaller to
create space. In general, using logical volumes is preferable to
using partitions because they can be more easily adjusted
later. - If creating a custom layout, create the partitions mentioned in
the previous paragraph (which the installer will require anyway),
as well as separate ones described in the following sections.
If a system has already been installed, and the default
partitioning
scheme was used, it is possible but nontrivial to
modify it to create separate logical volumes for the directories
listed above. The Logical Volume Manager (LVM) makes this possible.
See the LVM HOWTO at
http://tldp.org/HOWTO/LVM-HOWTO/
for more detailed information on LVM. |
Rule
Ensure /var/log/audit Located On Separate Partition
[ref] | Audit logs are stored in the /var/log/audit directory.
Ensure that /var/log/audit has its own partition or logical
volume at installation time, or migrate it using LVM.
Make absolutely certain that it is large enough to store all
audit logs that will be created by the auditing daemon. | Rationale: | Placing /var/log/audit in its own partition
enables better separation between audit files
and other files, and helps ensure that
auditing cannot be halted due to the partition running out
of space. | Severity: | low | Rule ID: | xccdf_org.ssgproject.content_rule_partition_for_var_log_audit | Identifiers and References | Identifiers:
CCE-90847-5 References:
BP28(R43), 1, 12, 13, 14, 15, 16, 2, 3, 5, 6, 8, APO11.04, APO13.01, BAI03.05, BAI04.04, DSS05.02, DSS05.04, DSS05.07, MEA02.01, CCI-000366, CCI-001849, 164.312(a)(2)(ii), 4.3.3.3.9, 4.3.3.5.8, 4.3.4.4.7, 4.4.2.1, 4.4.2.2, 4.4.2.4, SR 2.10, SR 2.11, SR 2.12, SR 2.8, SR 2.9, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 7.1, SR 7.2, SR 7.6, A.12.1.3, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, A.13.1.1, A.13.2.1, A.14.1.3, A.17.2.1, CIP-007-3 R6.5, CM-6(a), AU-4, SC-5(2), PR.DS-4, PR.PT-1, PR.PT-4, FMT_SMF_EXT.1, SRG-OS-000341-GPOS-00132, SRG-OS-000480-GPOS-00227, 1.1.6.1 | |
|
Group
Sudo
Group contains 1 rule |
[ref]
Sudo , which stands for "su 'do'", provides the ability to delegate authority
to certain users, groups of users, or system administrators. When configured for system
users and/or groups, Sudo can allow a user or group to execute privileged commands
that normally only root is allowed to execute.
For more information on Sudo and addition Sudo configuration options, see
https://www.sudo.ws. |
Rule
Install sudo Package
[ref] | The sudo package can be installed with the following command:
$ sudo dnf install sudo | Rationale: | 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.
| Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_package_sudo_installed | Identifiers and References | Identifiers:
CCE-83523-1 References:
BP28(R19), 1382, 1384, 1386, CM-6(a), FMT_MOF_EXT.1, 10.2.1.5, SRG-OS-000324-GPOS-00125, 5.3.1 | |
|
Group
System Tooling / Utilities
Group contains 4 rules |
[ref]
The following checks evaluate the system for recommended base packages -- both for installation
and removal. |
Rule
Ensure gnutls-utils is installed
[ref] | The gnutls-utils package can be installed with the following command:
$ sudo dnf install gnutls-utils | Rationale: | 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. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_package_gnutls-utils_installed | Identifiers and References | Identifiers:
CCE-83494-5 References:
FIA_X509_EXT.1, FIA_X509_EXT.2, SRG-OS-000480-GPOS-00227 | |
|
Rule
Install openscap-scanner Package
[ref] | The openscap-scanner package can be installed with the following command:
$ sudo dnf install openscap-scanner | Rationale: | openscap-scanner contains the oscap command line tool. This tool is a
configuration and vulnerability scanner, capable of performing compliance checking using
SCAP content.
| Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_package_openscap-scanner_installed | Identifiers and References | Identifiers:
CCE-83502-5 References:
AGD_PRE.1, AGD_OPE.1, SRG-OS-000480-GPOS-00227, SRG-OS-000191-GPOS-00080 | |
|
Rule
Install scap-security-guide Package
[ref] | The scap-security-guide package can be installed with the following command:
$ sudo dnf install scap-security-guide | Rationale: | The scap-security-guide package provides a guide for configuration of the system
from the final system's security point of view. The guidance is specified in the Security
Content Automation Protocol (SCAP) format and constitutes a catalog of practical hardening
advice, linked to government requirements where applicable. The SCAP Security Guide project
bridges the gap between generalized policy requirements and specific implementation guidelines.
A system administrator can use the oscap CLI tool from the openscap-scanner
package, or the SCAP Workbench GUI tool from the scap-workbench package, to verify
that the system conforms to provided guidelines. Refer to the scap-security-guide(8) manual
page for futher information. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_package_scap-security-guide_installed | Identifiers and References | Identifiers:
CCE-83505-8 References:
AGD_PRE.1, AGD_OPE.1, SRG-OS-000480-GPOS-00227 | |
|
Rule
Install subscription-manager Package
[ref] | The subscription-manager package can be installed with the following command:
$ sudo dnf install subscription-manager | Rationale: | 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. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_package_subscription-manager_installed | Identifiers and References | Identifiers:
CCE-83506-6 References:
0940, 1144, 1467, 1472, 1483, 1493, 1494, 1495, FPT_TUD_EXT.1, FPT_TUD_EXT.2, SRG-OS-000366-GPOS-00153 | |
|
Group
Updating Software
Group contains 7 rules |
[ref]
The dnf command line tool is used to install and
update software packages. The system also provides a graphical
software update tool in the System menu, in the Administration submenu,
called Software Update.
Red Hat Enterprise Linux 9 systems contain an installed software catalog called
the RPM database, which records metadata of installed packages. Consistently using
dnf or the graphical Software Update for all software installation
allows for insight into the current inventory of installed software on the system.
|
Rule
Install dnf-automatic Package
[ref] | The dnf-automatic package can be installed with the following command:
$ sudo dnf install dnf-automatic | Rationale: | dnf-automatic is an alternative command line interface (CLI)
to dnf upgrade suitable for automatic, regular execution.
| Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_package_dnf-automatic_installed | Identifiers and References | Identifiers:
CCE-83454-9 References:
BP28(R8), SRG-OS-000191-GPOS-00080 | |
|
Rule
Configure dnf-automatic to Install Available Updates Automatically
[ref] | To ensure that the packages comprising the available updates will be automatically installed by dnf-automatic , set apply_updates to yes under [commands] section in /etc/dnf/automatic.conf . | Rationale: | 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.
The automated installation of updates ensures that recent security patches
are applied in a timely manner. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_dnf-automatic_apply_updates | Identifiers and References | Identifiers:
CCE-83456-4 References:
BP28(R8), 0940, 1144, 1467, 1472, 1483, 1493, 1494, 1495, SI-2(5), CM-6(a), SI-2(c), FMT_SMF_EXT.1, SRG-OS-000191-GPOS-00080 | |
|
Rule
Ensure gpgcheck Enabled In Main dnf Configuration
[ref] | The gpgcheck option controls whether
RPM packages' signatures are always checked prior to installation.
To configure dnf to check package signatures before installing
them, ensure the following line appears in /etc/dnf/dnf.conf in
the [main] section:
gpgcheck=1 | Rationale: | Changes to any software components can have significant effects on the
overall security of the operating system. This requirement ensures the
software has not been tampered with and that it has been provided by a
trusted vendor.
Accordingly, patches, service packs, device drivers, or operating system
components must be signed with a certificate recognized and approved by the
organization.
Verifying the authenticity of the software prior to installation
validates the integrity of the patch or upgrade received from a vendor.
This ensures the software has not been tampered with and that it has been
provided by a trusted vendor. Self-signed certificates are disallowed by
this requirement. Certificates used to verify the software must be from an
approved Certificate Authority (CA). | Severity: | high | Rule ID: | xccdf_org.ssgproject.content_rule_ensure_gpgcheck_globally_activated | Identifiers and References | Identifiers:
CCE-83457-2 References:
BP28(R15), 11, 2, 3, 9, 5.10.4.1, APO01.06, BAI03.05, BAI06.01, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS06.02, 3.4.8, CCI-001749, 164.308(a)(1)(ii)(D), 164.312(b), 164.312(c)(1), 164.312(c)(2), 164.312(e)(2)(i), 4.3.4.3.2, 4.3.4.3.3, 4.3.4.4.4, SR 3.1, SR 3.3, SR 3.4, SR 3.8, SR 7.6, A.11.2.4, A.12.1.2, A.12.2.1, A.12.5.1, A.12.6.2, A.14.1.2, A.14.1.3, A.14.2.2, A.14.2.3, A.14.2.4, CM-5(3), SI-7, SC-12, SC-12(3), CM-6(a), SA-12, SA-12(10), CM-11(a), CM-11(b), PR.DS-6, PR.DS-8, PR.IP-1, FPT_TUD_EXT.1, FPT_TUD_EXT.2, Req-6.2, 6.3.3, SRG-OS-000366-GPOS-00153, 1.2.2 | |
|
Rule
Ensure gpgcheck Enabled for Local Packages
[ref] | dnf should be configured to verify the signature(s) of local packages
prior to installation. To configure dnf to verify signatures of local
packages, set the localpkg_gpgcheck to 1 in /etc/dnf/dnf.conf .
| Rationale: | Changes to any software components can have significant effects to the overall security
of the operating system. This requirement ensures the software has not been tampered and
has been provided by a trusted vendor.
Accordingly, patches, service packs, device drivers, or operating system components must
be signed with a certificate recognized and approved by the organization. | Severity: | high | Rule ID: | xccdf_org.ssgproject.content_rule_ensure_gpgcheck_local_packages | Identifiers and References | Identifiers:
CCE-83463-0 References:
BP28(R15), 11, 3, 9, BAI10.01, BAI10.02, BAI10.03, BAI10.05, 3.4.8, CCI-001749, 164.308(a)(1)(ii)(D), 164.312(b), 164.312(c)(1), 164.312(c)(2), 164.312(e)(2)(i), 4.3.4.3.2, 4.3.4.3.3, SR 7.6, A.12.1.2, A.12.5.1, A.12.6.2, A.14.2.2, A.14.2.3, A.14.2.4, CM-11(a), CM-11(b), CM-6(a), CM-5(3), SA-12, SA-12(10), PR.IP-1, FPT_TUD_EXT.1, FPT_TUD_EXT.2, SRG-OS-000366-GPOS-00153 | |
|
Rule
Ensure gpgcheck Enabled for All dnf Package Repositories
[ref] | To ensure signature checking is not disabled for
any repos, remove any lines from files in /etc/yum.repos.d of the form:
gpgcheck=0 | Rationale: | Verifying the authenticity of the software prior to installation validates
the integrity of the patch or upgrade received from a vendor. This ensures
the software has not been tampered with and that it has been provided by a
trusted vendor. Self-signed certificates are disallowed by this
requirement. Certificates used to verify the software must be from an
approved Certificate Authority (CA)." | Severity: | high | Rule ID: | xccdf_org.ssgproject.content_rule_ensure_gpgcheck_never_disabled | Identifiers and References | Identifiers:
CCE-83464-8 References:
BP28(R15), 11, 2, 3, 9, 5.10.4.1, APO01.06, BAI03.05, BAI06.01, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS06.02, 3.4.8, CCI-001749, 164.308(a)(1)(ii)(D), 164.312(b), 164.312(c)(1), 164.312(c)(2), 164.312(e)(2)(i), 4.3.4.3.2, 4.3.4.3.3, 4.3.4.4.4, SR 3.1, SR 3.3, SR 3.4, SR 3.8, SR 7.6, A.11.2.4, A.12.1.2, A.12.2.1, A.12.5.1, A.12.6.2, A.14.1.2, A.14.1.3, A.14.2.2, A.14.2.3, A.14.2.4, CM-5(3), SI-7, SC-12, SC-12(3), CM-6(a), SA-12, SA-12(10), CM-11(a), CM-11(b), PR.DS-6, PR.DS-8, PR.IP-1, FPT_TUD_EXT.1, FPT_TUD_EXT.2, Req-6.2, 6.3.3, SRG-OS-000366-GPOS-00153 | |
|
Rule
Ensure Red Hat GPG Key Installed
[ref] | To ensure the system can cryptographically verify base software packages
come from Red Hat (and to connect to the Red Hat Network to receive them),
the Red Hat GPG key must properly be installed. To install the Red Hat GPG
key, run:
$ sudo subscription-manager register
If the system is not connected to the Internet or an RHN Satellite, then
install the Red Hat GPG key from trusted media such as the Red Hat
installation CD-ROM or DVD. Assuming the disc is mounted in
/media/cdrom , use the following command as the root user to import
it into the keyring:
$ sudo rpm --import /media/cdrom/RPM-GPG-KEY
Alternatively, the key may be pre-loaded during the RHEL installation. In
such cases, the key can be installed by running the following command:
sudo rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release | Rationale: | Changes to software components can have significant effects on the overall
security of the operating system. This requirement ensures the software has
not been tampered with and that it has been provided by a trusted vendor.
The Red Hat GPG key is necessary to cryptographically verify packages are
from Red Hat. | Severity: | high | Rule ID: | xccdf_org.ssgproject.content_rule_ensure_redhat_gpgkey_installed | Identifiers and References | Identifiers:
CCE-84180-9 References:
BP28(R15), 11, 2, 3, 9, 5.10.4.1, APO01.06, BAI03.05, BAI06.01, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS06.02, 3.4.8, CCI-001749, 164.308(a)(1)(ii)(D), 164.312(b), 164.312(c)(1), 164.312(c)(2), 164.312(e)(2)(i), 4.3.4.3.2, 4.3.4.3.3, 4.3.4.4.4, SR 3.1, SR 3.3, SR 3.4, SR 3.8, SR 7.6, A.11.2.4, A.12.1.2, A.12.2.1, A.12.5.1, A.12.6.2, A.14.1.2, A.14.1.3, A.14.2.2, A.14.2.3, A.14.2.4, CIP-003-8 R4.2, CIP-003-8 R6, CIP-007-3 R4, CIP-007-3 R4.1, CIP-007-3 R4.2, CIP-007-3 R5.1, CM-5(3), SI-7, SC-12, SC-12(3), CM-6(a), PR.DS-6, PR.DS-8, PR.IP-1, FPT_TUD_EXT.1, FPT_TUD_EXT.2, Req-6.2, SRG-OS-000366-GPOS-00153, 1.2.1 | |
|
Rule
Enable dnf-automatic Timer
[ref] |
The dnf-automatic timer can be enabled with the following command:
$ sudo systemctl enable dnf-automatic.timer | Rationale: | The dnf-automatic is an alternative command line interface (CLI) to dnf upgrade with specific facilities to make it suitable to be executed automatically and regularly from systemd timers, cron jobs and similar.
The tool is controlled by dnf-automatic.timer SystemD timer. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_timer_dnf-automatic_enabled | Identifiers and References | Identifiers:
CCE-83459-8 References:
BP28(R8), SI-2(5), CM-6(a), SI-2(c), FMT_SMF_EXT.1, SRG-OS-000191-GPOS-00080 | |
|
Group
Account and Access Control
Group contains 10 groups and 20 rules |
[ref]
In traditional Unix security, if an attacker gains
shell access to a certain login account, they can perform any action
or access any file to which that account has access. Therefore,
making it more difficult for unauthorized people to gain shell
access to accounts, particularly to privileged accounts, is a
necessary part of securing a system. This section introduces
mechanisms for restricting access to accounts under
Red Hat Enterprise Linux 9. |
Group
Protect Accounts by Configuring PAM
Group contains 3 groups and 8 rules |
[ref]
PAM, or Pluggable Authentication Modules, is a system
which implements modular authentication for Linux programs. PAM provides
a flexible and configurable architecture for authentication, and it should be configured
to minimize exposure to unnecessary risk. This section contains
guidance on how to accomplish that.
PAM is implemented as a set of shared objects which are
loaded and invoked whenever an application wishes to authenticate a
user. Typically, the application must be running as root in order
to take advantage of PAM, because PAM's modules often need to be able
to access sensitive stores of account information, such as /etc/shadow.
Traditional privileged network listeners
(e.g. sshd) or SUID programs (e.g. sudo) already meet this
requirement. An SUID root application, userhelper, is provided so
that programs which are not SUID or privileged themselves can still
take advantage of PAM.
PAM looks in the directory /etc/pam.d for
application-specific configuration information. For instance, if
the program login attempts to authenticate a user, then PAM's
libraries follow the instructions in the file /etc/pam.d/login
to determine what actions should be taken.
One very important file in /etc/pam.d is
/etc/pam.d/system-auth . This file, which is included by
many other PAM configuration files, defines 'default' system authentication
measures. Modifying this file is a good way to make far-reaching
authentication changes, for instance when implementing a
centralized authentication service. Warning:
Be careful when making changes to PAM's configuration files.
The syntax for these files is complex, and modifications can
have unexpected consequences. The default configurations shipped
with applications should be sufficient for most users. |
Group
Set Lockouts for Failed Password Attempts
Group contains 3 rules |
[ref]
The pam_faillock PAM module provides the capability to
lock out user accounts after a number of failed login attempts. Its
documentation is available in
/usr/share/doc/pam-VERSION/txts/README.pam_faillock .
Warning:
Locking out user accounts presents the
risk of a denial-of-service attack. The lockout policy
must weigh whether the risk of such a
denial-of-service attack outweighs the benefits of thwarting
password guessing attacks. |
Rule
Lock Accounts After Failed Password Attempts
[ref] | This rule configures the system to lock out accounts after a number of incorrect login attempts
using pam_faillock.so .
pam_faillock.so module requires multiple entries in pam files. These entries must be carefully
defined to work as expected.
In order to avoid errors when manually editing these files, it is
recommended to use the appropriate tools, such as authselect or authconfig ,
depending on the OS version. Warning:
If the system relies on authselect tool to manage PAM settings, the remediation
will also use authselect tool. However, if any manual modification was made in
PAM files, the authselect integrity check will fail and the remediation will be
aborted in order to preserve intentional changes. In this case, an informative message will
be shown in the remediation report.
If the system supports the /etc/security/faillock.conf file, the pam_faillock
parameters should be defined in faillock.conf file. | Rationale: | 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. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_passwords_pam_faillock_deny | Identifiers and References | Identifiers:
CCE-83587-6 References:
BP28(R18), 1, 12, 15, 16, 5.5.3, DSS05.04, DSS05.10, DSS06.10, 3.1.8, CCI-000044, CCI-002236, CCI-002237, CCI-002238, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, SR 1.1, SR 1.10, SR 1.2, SR 1.5, SR 1.7, SR 1.8, SR 1.9, 0421, 0422, 0431, 0974, 1173, 1401, 1504, 1505, 1546, 1557, 1558, 1559, 1560, 1561, A.18.1.4, A.9.2.1, A.9.2.4, A.9.3.1, A.9.4.2, A.9.4.3, CM-6(a), AC-7(a), PR.AC-7, FIA_AFL.1, Req-8.1.6, 8.3.4, SRG-OS-000329-GPOS-00128, SRG-OS-000021-GPOS-00005, 5.4.2, 5.5.2 | |
|
Rule
Set Interval For Counting Failed Password Attempts
[ref] | Utilizing pam_faillock.so , the fail_interval directive configures the system
to lock out an account after a number of incorrect login attempts within a specified time
period. Warning:
If the system relies on authselect tool to manage PAM settings, the remediation
will also use authselect tool. However, if any manual modification was made in
PAM files, the authselect integrity check will fail and the remediation will be
aborted in order to preserve intentional changes. In this case, an informative message will
be shown in the remediation report.
If the system supports the /etc/security/faillock.conf file, the pam_faillock
parameters should be defined in faillock.conf file. | Rationale: | By limiting the number of failed logon attempts the risk of unauthorized system
access via user password guessing, otherwise known as brute-forcing, is reduced.
Limits are imposed by locking the account. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_passwords_pam_faillock_interval | Identifiers and References | Identifiers:
CCE-83583-5 References:
BP28(R18), 1, 12, 15, 16, DSS05.04, DSS05.10, DSS06.10, CCI-000044, CCI-002236, CCI-002237, CCI-002238, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, SR 1.1, SR 1.10, SR 1.2, SR 1.5, SR 1.7, SR 1.8, SR 1.9, 0421, 0422, 0431, 0974, 1173, 1401, 1504, 1505, 1546, 1557, 1558, 1559, 1560, 1561, A.18.1.4, A.9.2.1, A.9.2.4, A.9.3.1, A.9.4.2, A.9.4.3, CM-6(a), AC-7(a), PR.AC-7, FIA_AFL.1, SRG-OS-000329-GPOS-00128, SRG-OS-000021-GPOS-00005 | |
|
Rule
Set Lockout Time for Failed Password Attempts
[ref] | This rule configures the system to lock out accounts during a specified time period after a
number of incorrect login attempts using pam_faillock.so .
pam_faillock.so module requires multiple entries in pam files. These entries must be carefully
defined to work as expected. In order to avoid any errors when manually editing these files,
it is recommended to use the appropriate tools, such as authselect or authconfig ,
depending on the OS version.
If unlock_time is set to 0 , manual intervention by an administrator is required
to unlock a user. This should be done using the faillock tool. Warning:
If the system supports the new /etc/security/faillock.conf file but the
pam_faillock.so parameters are defined directly in /etc/pam.d/system-auth and
/etc/pam.d/password-auth , the remediation will migrate the unlock_time parameter
to /etc/security/faillock.conf to ensure compatibility with authselect tool.
The parameters deny and fail_interval , if used, also have to be migrated
by their respective remediation. Warning:
If the system relies on authselect tool to manage PAM settings, the remediation
will also use authselect tool. However, if any manual modification was made in
PAM files, the authselect integrity check will fail and the remediation will be
aborted in order to preserve intentional changes. In this case, an informative message will
be shown in the remediation report.
If the system supports the /etc/security/faillock.conf file, the pam_faillock
parameters should be defined in faillock.conf file. | Rationale: | By limiting the number of failed logon attempts the risk of unauthorized system
access via user password guessing, otherwise known as brute-forcing, is reduced.
Limits are imposed by locking the account. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_passwords_pam_faillock_unlock_time | Identifiers and References | Identifiers:
CCE-83588-4 References:
BP28(R18), 1, 12, 15, 16, 5.5.3, DSS05.04, DSS05.10, DSS06.10, 3.1.8, CCI-000044, CCI-002236, CCI-002237, CCI-002238, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, SR 1.1, SR 1.10, SR 1.2, SR 1.5, SR 1.7, SR 1.8, SR 1.9, 0421, 0422, 0431, 0974, 1173, 1401, 1504, 1505, 1546, 1557, 1558, 1559, 1560, 1561, A.18.1.4, A.9.2.1, A.9.2.4, A.9.3.1, A.9.4.2, A.9.4.3, CM-6(a), AC-7(b), PR.AC-7, FIA_AFL.1, Req-8.1.7, 8.3.4, SRG-OS-000329-GPOS-00128, SRG-OS-000021-GPOS-00005, 5.5.2 | |
|
Group
Set Password Quality Requirements
Group contains 1 group and 5 rules |
[ref]
The default pam_pwquality PAM module provides strength
checking for passwords. It performs a number of checks, such as
making sure passwords are not similar to dictionary words, are of
at least a certain length, are not the previous password reversed,
and are not simply a change of case from the previous password. It
can also require passwords to be in certain character classes. The
pam_pwquality module is the preferred way of configuring
password requirements.
The man pages pam_pwquality(8)
provide information on the capabilities and configuration of
each. |
Group
Set Password Quality Requirements with pam_pwquality
Group contains 5 rules |
[ref]
The pam_pwquality PAM module can be configured to meet
requirements for a variety of policies.
For example, to configure pam_pwquality to require at least one uppercase
character, lowercase character, digit, and other (special)
character, make sure that pam_pwquality exists in /etc/pam.d/system-auth :
password requisite pam_pwquality.so try_first_pass local_users_only retry=3 authtok_type=
If no such line exists, add one as the first line of the password section in /etc/pam.d/system-auth .
Next, modify the settings in /etc/security/pwquality.conf to match the following:
difok = 4
minlen = 14
dcredit = -1
ucredit = -1
lcredit = -1
ocredit = -1
maxrepeat = 3
The arguments can be modified to ensure compliance with
your organization's security policy. Discussion of each parameter follows. |
Rule
Ensure PAM Enforces Password Requirements - Minimum Digit Characters
[ref] | The pam_pwquality module's dcredit parameter controls requirements for
usage of digits in a password. When set to a negative number, any password will be required to
contain that many digits. When set to a positive number, pam_pwquality will grant +1 additional
length credit for each digit. Modify the dcredit setting in
/etc/security/pwquality.conf to require the use of a digit in passwords. | Rationale: | Use of a complex password helps to increase the time and resources required
to compromise the password. Password complexity, or strength, is a measure of
the effectiveness of a password in resisting attempts at guessing and brute-force
attacks.
Password complexity is one factor of several that determines how long it takes
to crack a password. The more complex the password, the greater the number of
possible combinations that need to be tested before the password is compromised.
Requiring digits makes password guessing attacks more difficult by ensuring a larger
search space. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_password_pam_dcredit | Identifiers and References | Identifiers:
CCE-83566-0 References:
BP28(R18), 1, 12, 15, 16, 5, DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.10, CCI-000194, 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.2, 4.3.3.7.4, SR 1.1, SR 1.10, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 2.1, 0421, 0422, 0431, 0974, 1173, 1401, 1504, 1505, 1546, 1557, 1558, 1559, 1560, 1561, A.18.1.4, A.7.1.1, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.2, A.9.4.3, IA-5(c), IA-5(1)(a), CM-6(a), IA-5(4), PR.AC-1, PR.AC-6, PR.AC-7, FMT_SMF_EXT.1, Req-8.2.3, 8.3.6, 8.3.9, SRG-OS-000071-GPOS-00039 | |
|
Rule
Ensure PAM Enforces Password Requirements - Minimum Lowercase Characters
[ref] | The pam_pwquality module's lcredit parameter controls requirements for
usage of lowercase letters in a password. When set to a negative number, any password will be required to
contain that many lowercase characters. When set to a positive number, pam_pwquality will grant +1 additional
length credit for each lowercase character. Modify the lcredit setting in
/etc/security/pwquality.conf to require the use of a lowercase character in passwords. | Rationale: | 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
possble combinations that need to be tested before the password is compromised.
Requiring a minimum number of lowercase characters makes password guessing attacks
more difficult by ensuring a larger search space. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_password_pam_lcredit | Identifiers and References | Identifiers:
CCE-83570-2 References:
BP28(R18), 1, 12, 15, 16, 5, DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.10, CCI-000193, 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.2, 4.3.3.7.4, SR 1.1, SR 1.10, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 2.1, 0421, 0422, 0431, 0974, 1173, 1401, 1504, 1505, 1546, 1557, 1558, 1559, 1560, 1561, A.18.1.4, A.7.1.1, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.2, A.9.4.3, IA-5(c), IA-5(1)(a), CM-6(a), IA-5(4), PR.AC-1, PR.AC-6, PR.AC-7, FMT_SMF_EXT.1, Req-8.2.3, 8.3.6, 8.3.9, SRG-OS-000070-GPOS-00038 | |
|
Rule
Ensure PAM Enforces Password Requirements - Minimum Length
[ref] | The pam_pwquality module's minlen parameter controls requirements for
minimum characters required in a password. Add minlen=12
after pam_pwquality to set minimum password length requirements. | Rationale: | The shorter the password, the lower the number of possible combinations
that need to be tested before the password is compromised.
Password complexity, or strength, is a measure of the effectiveness of a
password in resisting attempts at guessing and brute-force attacks.
Password length is one factor of several that helps to determine strength
and how long it takes to crack a password. Use of more characters in a password
helps to exponentially increase the time and/or resources required to
compromise the password. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_password_pam_minlen | Identifiers and References | Identifiers:
CCE-83579-3 References:
BP28(R18), 1, 12, 15, 16, 5, 5.6.2.1.1, DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.10, CCI-000205, 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.2, 4.3.3.7.4, SR 1.1, SR 1.10, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 2.1, 0421, 0422, 0431, 0974, 1173, 1401, 1504, 1505, 1546, 1557, 1558, 1559, 1560, 1561, A.18.1.4, A.7.1.1, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.2, A.9.4.3, IA-5(c), IA-5(1)(a), CM-6(a), IA-5(4), PR.AC-1, PR.AC-6, PR.AC-7, FMT_SMF_EXT.1, Req-8.2.3, 8.3.6, 8.3.9, SRG-OS-000078-GPOS-00046, 5.5.1 | |
|
Rule
Ensure PAM Enforces Password Requirements - Minimum Special Characters
[ref] | The pam_pwquality module's ocredit= parameter controls requirements for
usage of special (or "other") characters in a password. When set to a negative number,
any password will be required to contain that many special characters.
When set to a positive number, pam_pwquality will grant +1
additional length credit for each special character. Modify the ocredit setting
in /etc/security/pwquality.conf to equal -1
to require use of a special character in passwords. | Rationale: | Use of a complex password helps to increase the time and resources required
to compromise the password. Password complexity, or strength, is a measure of
the effectiveness of a password in resisting attempts at guessing and brute-force
attacks.
Password complexity is one factor of several that determines how long it takes
to crack a password. The more complex the password, the greater the number of
possible combinations that need to be tested before the password is compromised.
Requiring a minimum number of special characters makes password guessing attacks
more difficult by ensuring a larger search space. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_password_pam_ocredit | Identifiers and References | Identifiers:
CCE-83565-2 References:
BP28(R18), 1, 12, 15, 16, 5, DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.10, CCI-001619, 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.2, 4.3.3.7.4, SR 1.1, SR 1.10, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 2.1, 0421, 0422, 0431, 0974, 1173, 1401, 1504, 1505, 1546, 1557, 1558, 1559, 1560, 1561, A.18.1.4, A.7.1.1, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.2, A.9.4.3, IA-5(c), IA-5(1)(a), CM-6(a), IA-5(4), PR.AC-1, PR.AC-6, PR.AC-7, FMT_SMF_EXT.1, SRG-OS-000266-GPOS-00101 | |
|
Rule
Ensure PAM Enforces Password Requirements - Minimum Uppercase Characters
[ref] | The pam_pwquality module's ucredit= parameter controls requirements for
usage of uppercase letters in a password. When set to a negative number, any password will be required to
contain that many uppercase characters. When set to a positive number, pam_pwquality will grant +1 additional
length credit for each uppercase character. Modify the ucredit setting in
/etc/security/pwquality.conf to require the use of an uppercase character in passwords. | Rationale: | 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. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_password_pam_ucredit | Identifiers and References | Identifiers:
CCE-83568-6 References:
BP28(R18), 1, 12, 15, 16, 5, DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.10, CCI-000192, CCI-000193, 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.2, 4.3.3.7.4, SR 1.1, SR 1.10, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 2.1, 0421, 0422, 0431, 0974, 1173, 1401, 1504, 1505, 1546, 1557, 1558, 1559, 1560, 1561, A.18.1.4, A.7.1.1, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.2, A.9.4.3, IA-5(c), IA-5(1)(a), CM-6(a), IA-5(4), PR.AC-1, PR.AC-6, PR.AC-7, FMT_SMF_EXT.1, Req-8.2.3, 8.3.6, 8.3.9, SRG-OS-000069-GPOS-00037, SRG-OS-000070-GPOS-00038 | |
|
Group
Protect Physical Console Access
Group contains 2 groups and 9 rules |
[ref]
It is impossible to fully protect a system from an
attacker with physical access, so securing the space in which the
system is located should be considered a necessary step. However,
there are some steps which, if taken, make it more difficult for an
attacker to quickly or undetectably modify a system from its
console. |
Group
Configure Screen Locking
Group contains 1 group and 5 rules |
[ref]
When a user must temporarily leave an account
logged-in, screen locking should be employed to prevent passersby
from abusing the account. User education and training is
particularly important for screen locking to be effective, and policies
can be implemented to reinforce this.
Automatic screen locking is only meant as a safeguard for
those cases where a user forgot to lock the screen. |
Group
Configure Console Screen Locking
Group contains 5 rules |
[ref]
A console screen locking mechanism 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
operation 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. |
Rule
Install the tmux Package
[ref] | To enable console screen locking, install the tmux package.
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, Red Hat Enterprise Linux 9 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.
Instruct users to begin new terminal sessions with the following command:
$ tmux
The console can now be locked with the following key combination:
ctrl+b :lock-session | Rationale: | 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 operation 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 tmux package allows for a session lock to be implemented and configured. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_package_tmux_installed | Identifiers and References | Identifiers:
CCE-83599-1 References:
1, 12, 15, 16, DSS05.04, DSS05.10, DSS06.10, 3.1.10, CCI-000058, CCI-000056, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, SR 1.1, SR 1.10, SR 1.2, SR 1.5, SR 1.7, SR 1.8, SR 1.9, A.18.1.4, A.9.2.1, A.9.2.4, A.9.3.1, A.9.4.2, A.9.4.3, CM-6(a), PR.AC-7, FMT_SMF_EXT.1, FMT_MOF_EXT.1, FTA_SSL.1, SRG-OS-000030-GPOS-00011, SRG-OS-000028-GPOS-00009 | |
|
Rule
Support session locking with tmux
[ref] | The tmux terminal multiplexer is used to implement
automatic session locking. It should be started from
/etc/bashrc or drop-in files within /etc/profile.d/ . | Rationale: | Unlike bash itself, the tmux terminal multiplexer
provides a mechanism to lock sessions after period of inactivity.
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. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_configure_bashrc_exec_tmux | Identifiers and References | Identifiers:
CCE-90586-9 References:
CCI-000056, CCI-000058, FMT_SMF_EXT.1, FMT_MOF_EXT.1, FTA_SSL.1, SRG-OS-000031-GPOS-00012, SRG-OS-000028-GPOS-00009, SRG-OS-000030-GPOS-00011 | |
|
Rule
Configure tmux to lock session after inactivity
[ref] | To enable console screen locking in tmux terminal multiplexer
after a period of inactivity,
the lock-after-time option has to be set to a value greater than 0 and less than
or equal to 900 in /etc/tmux.conf . | Rationale: | Locking the session after a period of inactivity limits the
potential exposure if the session is left unattended. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_configure_tmux_lock_after_time | Identifiers and References | Identifiers:
CCE-89876-7 References:
CCI-000057, CCI-000060, FMT_SMF_EXT.1, FMT_MOF_EXT.1, FTA_SSL.1, SRG-OS-000029-GPOS-00010, SRG-OS-000031-GPOS-00012 | |
|
Rule
Configure the tmux Lock Command
[ref] | To enable console screen locking in tmux terminal multiplexer,
the vlock command must be configured to be used as a locking
mechanism.
Add the following line to /etc/tmux.conf :
set -g lock-command vlock .
The console can now be locked with the following key combination:
ctrl+b :lock-session | Rationale: | The tmux package allows for a session lock to be implemented and configured.
However, the session lock is implemented by an external command. The tmux
default configuration does not contain an effective session lock. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_configure_tmux_lock_command | Identifiers and References | Identifiers:
CCE-90171-0 References:
CCI-000056, CCI-000058, AC-11(a), AC-11(b), CM-6(a), FMT_SMF_EXT.1, FMT_MOF_EXT.1, FTA_SSL.1, SRG-OS-000028-GPOS-00009, SRG-OS-000030-GPOS-00011 | |
|
|
Rule
Disable debug-shell SystemD Service
[ref] | SystemD's debug-shell service is intended to
diagnose SystemD related boot issues with various systemctl
commands. Once enabled and following a system reboot, the root shell
will be available on tty9 which is access by pressing
CTRL-ALT-F9 . The debug-shell service should only be used
for SystemD related issues and should otherwise be disabled.
By default, the debug-shell SystemD service is already disabled.
The debug-shell service can be disabled with the following command:
$ sudo systemctl mask --now debug-shell.service | Rationale: | This prevents attackers with physical access from trivially bypassing security
on the machine through valid troubleshooting configurations and gaining root
access when the system is rebooted. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_service_debug-shell_disabled | Identifiers and References | Identifiers:
CCE-90724-6 References:
3.4.5, CCI-000366, 164.308(a)(1)(ii)(B), 164.308(a)(7)(i), 164.308(a)(7)(ii)(A), 164.310(a)(1), 164.310(a)(2)(i), 164.310(a)(2)(ii), 164.310(a)(2)(iii), 164.310(b), 164.310(c), 164.310(d)(1), 164.310(d)(2)(iii), CM-6, FIA_UAU.1, SRG-OS-000324-GPOS-00125, SRG-OS-000480-GPOS-00227 | |
|
Rule
Disable Ctrl-Alt-Del Burst Action
[ref] | By default, SystemD will reboot the system if the Ctrl-Alt-Del
key sequence is pressed Ctrl-Alt-Delete more than 7 times in 2 seconds.
To configure the system to ignore the CtrlAltDelBurstAction
setting, add or modify the following to /etc/systemd/system.conf :
CtrlAltDelBurstAction=none Warning:
Disabling the Ctrl-Alt-Del key sequence
in /etc/init/control-alt-delete.conf DOES NOT disable the Ctrl-Alt-Del
key sequence if running in runlevel 6 (e.g. in GNOME, KDE, etc.)! The
Ctrl-Alt-Del key sequence will only be disabled if running in
the non-graphical runlevel 3 . | Rationale: | 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. | Severity: | high | Rule ID: | xccdf_org.ssgproject.content_rule_disable_ctrlaltdel_burstaction | Identifiers and References | Identifiers:
CCE-90308-8 References:
12, 13, 14, 15, 16, 18, 3, 5, APO01.06, DSS05.04, DSS05.07, DSS06.02, 3.4.5, CCI-000366, 164.308(a)(1)(ii)(B), 164.308(a)(7)(i), 164.308(a)(7)(ii)(A), 164.310(a)(1), 164.310(a)(2)(i), 164.310(a)(2)(ii), 164.310(a)(2)(iii), 164.310(b), 164.310(c), 164.310(d)(1), 164.310(d)(2)(iii), 4.3.3.7.3, SR 2.1, SR 5.2, A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5, CIP-003-8 R5.1.1, CIP-003-8 R5.3, CIP-004-6 R2.3, CIP-007-3 R2.1, CIP-007-3 R2.2, CIP-007-3 R2.3, CIP-007-3 R5.1, CIP-007-3 R5.1.1, CIP-007-3 R5.1.2, CM-6(a), AC-6(1), CM-6(a), PR.AC-4, PR.DS-5, FAU_GEN.1.2, SRG-OS-000324-GPOS-00125, SRG-OS-000480-GPOS-00227 | |
|
Rule
Disable Ctrl-Alt-Del Reboot Activation
[ref] | By default, SystemD will reboot the system if the Ctrl-Alt-Del
key sequence is pressed.
To configure the system to ignore the Ctrl-Alt-Del key sequence from the
command line instead of rebooting the system, do either of the following:
ln -sf /dev/null /etc/systemd/system/ctrl-alt-del.target
or
systemctl mask ctrl-alt-del.target
Do not simply delete the /usr/lib/systemd/system/ctrl-alt-del.service file,
as this file may be restored during future system updates. | Rationale: | 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. | Severity: | high | Rule ID: | xccdf_org.ssgproject.content_rule_disable_ctrlaltdel_reboot | Identifiers and References | Identifiers:
CCE-86667-3 References:
12, 13, 14, 15, 16, 18, 3, 5, APO01.06, DSS05.04, DSS05.07, DSS06.02, 3.4.5, CCI-000366, 164.308(a)(1)(ii)(B), 164.308(a)(7)(i), 164.308(a)(7)(ii)(A), 164.310(a)(1), 164.310(a)(2)(i), 164.310(a)(2)(ii), 164.310(a)(2)(iii), 164.310(b), 164.310(c), 164.310(d)(1), 164.310(d)(2)(iii), 4.3.3.7.3, SR 2.1, SR 5.2, A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5, CIP-003-8 R5.1.1, CIP-003-8 R5.3, CIP-004-6 R2.3, CIP-007-3 R2.1, CIP-007-3 R2.2, CIP-007-3 R2.3, CIP-007-3 R5.1, CIP-007-3 R5.1.1, CIP-007-3 R5.1.2, CM-6(a), AC-6(1), PR.AC-4, PR.DS-5, FAU_GEN.1.2, SRG-OS-000324-GPOS-00125, SRG-OS-000480-GPOS-00227 | |
|
Rule
Require Authentication for Single User Mode
[ref] | Single-user mode is intended as a system recovery
method, providing a single user root access to the system by
providing a boot option at startup.
By default, single-user mode is protected by requiring a password and is set
in /usr/lib/systemd/system/rescue.service . | Rationale: | This prevents attackers with physical access from trivially bypassing security
on the machine and gaining root access. Such accesses are further prevented
by configuring the bootloader password. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_require_singleuser_auth | Identifiers and References | Identifiers:
CCE-83594-2 References:
1, 11, 12, 14, 15, 16, 18, 3, 5, DSS05.02, DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.06, DSS06.10, 3.1.1, 3.4.5, CCI-000213, 164.308(a)(1)(ii)(B), 164.308(a)(7)(i), 164.308(a)(7)(ii)(A), 164.310(a)(1), 164.310(a)(2)(i), 164.310(a)(2)(ii), 164.310(a)(2)(iii), 164.310(b), 164.310(c), 164.310(d)(1), 164.310(d)(2)(iii), 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.3, 4.3.3.5.4, 4.3.3.5.5, 4.3.3.5.6, 4.3.3.5.7, 4.3.3.5.8, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.1, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7, 0421, 0422, 0431, 0974, 1173, 1401, 1504, 1505, 1546, 1557, 1558, 1559, 1560, 1561, A.18.1.4, A.6.1.2, A.7.1.1, A.9.1.2, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.1, A.9.4.2, A.9.4.3, A.9.4.4, A.9.4.5, CIP-003-8 R5.1.1, CIP-003-8 R5.3, CIP-004-6 R2.2.3, CIP-004-6 R2.3, CIP-007-3 R5.1, CIP-007-3 R5.1.2, CIP-007-3 R5.2, CIP-007-3 R5.3.1, CIP-007-3 R5.3.2, CIP-007-3 R5.3.3, IA-2, AC-3, CM-6(a), PR.AC-1, PR.AC-4, PR.AC-6, PR.AC-7, PR.PT-3, FIA_UAU.1, SRG-OS-000080-GPOS-00048 | |
|
Group
Protect Accounts by Restricting Password-Based Login
Group contains 2 groups and 2 rules |
[ref]
Conventionally, Unix shell accounts are accessed by
providing a username and password to a login program, which tests
these values for correctness using the /etc/passwd and
/etc/shadow files. Password-based login is vulnerable to
guessing of weak passwords, and to sniffing and man-in-the-middle
attacks against passwords entered over a network or at an insecure
console. Therefore, mechanisms for accessing accounts by entering
usernames and passwords should be restricted to those which are
operationally necessary. |
Group
Verify Proper Storage and Existence of Password
Hashes
Group contains 1 rule |
[ref]
By default, password hashes for local accounts are stored
in the second field (colon-separated) in
/etc/shadow . This file should be readable only by
processes running with root credentials, preventing users from
casually accessing others' password hashes and attempting
to crack them.
However, it remains possible to misconfigure the system
and store password hashes
in world-readable files such as /etc/passwd , or
to even store passwords themselves in plaintext on the system.
Using system-provided tools for password change/creation
should allow administrators to avoid such misconfiguration. |
Rule
Prevent Login to Accounts With Empty Password
[ref] | If an account is configured for password authentication
but does not have an assigned password, it may be possible to log
into the account without authentication. Remove any instances of the
nullok in
/etc/pam.d/system-auth and
/etc/pam.d/password-auth
to prevent logins with empty passwords. Warning:
If the system relies on authselect tool to manage PAM settings, the remediation
will also use authselect tool. However, if any manual modification was made in
PAM files, the authselect integrity check will fail and the remediation will be
aborted in order to preserve intentional changes. In this case, an informative message will
be shown in the remediation report.
Note that this rule is not applicable for systems running within a
container. Having user with empty password within a container is not
considered a risk, because it should not be possible to directly login into
a container anyway. | Rationale: | 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. | Severity: | high | Rule ID: | xccdf_org.ssgproject.content_rule_no_empty_passwords | Identifiers and References | Identifiers:
CCE-83611-4 References:
1, 12, 13, 14, 15, 16, 18, 3, 5, 5.5.2, APO01.06, DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.02, DSS06.03, DSS06.10, 3.1.1, 3.1.5, CCI-000366, 164.308(a)(1)(ii)(B), 164.308(a)(7)(i), 164.308(a)(7)(ii)(A), 164.310(a)(1), 164.310(a)(2)(i), 164.310(a)(2)(ii), 164.310(a)(2)(iii), 164.310(b), 164.310(c), 164.310(d)(1), 164.310(d)(2)(iii), 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, SR 1.1, SR 1.10, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 5.2, A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.18.1.4, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.1, A.9.4.2, A.9.4.3, A.9.4.4, A.9.4.5, IA-5(1)(a), IA-5(c), CM-6(a), PR.AC-1, PR.AC-4, PR.AC-6, PR.AC-7, PR.DS-5, FIA_UAU.1, Req-8.2.3, 8.3.6, 8.3.9, SRG-OS-000480-GPOS-00227, 5.4.1 | |
|
Group
Restrict Root Logins
Group contains 1 rule |
[ref]
Direct root logins should be allowed only for emergency use.
In normal situations, the administrator should access the system
via a unique unprivileged account, and then use su or sudo to execute
privileged commands. Discouraging administrators from accessing the
root account directly ensures an audit trail in organizations with
multiple administrators. Locking down the channels through which
root can connect directly also reduces opportunities for
password-guessing against the root account. The login program
uses the file /etc/securetty to determine which interfaces
should allow root logins.
The virtual devices /dev/console
and /dev/tty* represent the system consoles (accessible via
the Ctrl-Alt-F1 through Ctrl-Alt-F6 keyboard sequences on a default
installation). The default securetty file also contains /dev/vc/* .
These are likely to be deprecated in most environments, but may be retained
for compatibility. Root should also be prohibited from connecting
via network protocols. Other sections of this document
include guidance describing how to prevent root from logging in via SSH. |
Rule
Enforce usage of pam_wheel for su authentication
[ref] | To ensure that only users who are members of the wheel group can
run commands with altered privileges through the su command, make
sure that the following line exists in the file /etc/pam.d/su :
auth required pam_wheel.so use_uid Warning:
Members of "wheel" or GID 0 groups are checked by default if the group option is not set
for pam_wheel.so module. Therefore, members of these groups should be manually checked or
a different group should be informed according to the site policy. | Rationale: | 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. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_use_pam_wheel_for_su | Identifiers and References | Identifiers:
CCE-90085-2 References:
FMT_SMF_EXT.1.1, 8.6.1, SRG-OS-000373-GPOS-00156, SRG-OS-000312-GPOS-00123, 5.3.7 | |
|
Rule
Enable authselect
[ref] | Configure user authentication setup to use the authselect tool.
If authselect profile is selected, the rule will enable the minimal profile. Warning:
If the sudo authselect select command returns an error informing that the chosen
profile cannot be selected, it is probably because PAM files have already been modified by
the administrator. If this is the case, in order to not overwrite the desired changes made
by the administrator, the current PAM settings should be investigated before forcing the
selection of the chosen authselect profile. | Rationale: | Authselect is a successor to authconfig.
It is a tool to select system authentication and identity sources from a list of supported
profiles instead of letting the administrator manually build the PAM stack.
That way, it avoids potential breakage of configuration, as it ships several tested profiles
that are well tested and supported to solve different use-cases. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_enable_authselect | Identifiers and References | Identifiers:
CCE-89732-2 References:
BP28(R31), CCI-000213, 164.308(a)(1)(ii)(B), 164.308(a)(7)(i), 164.308(a)(7)(ii)(A), 164.310(a)(1), 164.310(a)(2)(i), 164.310(a)(2)(ii), 164.310(a)(2)(iii), 164.310(b), 164.310(c), 164.310(d)(1), 164.310(d)(2)(iii), AC-3, FIA_UAU.1, FIA_AFL.1, SRG-OS-000480-GPOS-00227, 5.4.1 | |
|
Group
System Accounting with auditd
Group contains 2 groups and 51 rules |
[ref]
The audit service provides substantial capabilities
for recording system activities. By default, the service audits about
SELinux AVC denials and certain types of security-relevant events
such as system logins, account modifications, and authentication
events performed by programs such as sudo.
Under its default configuration, auditd has modest disk space
requirements, and should not noticeably impact system performance.
NOTE: The Linux Audit daemon auditd can be configured to use
the augenrules program to read audit rules files ( *.rules )
located in /etc/audit/rules.d location and compile them to create
the resulting form of the /etc/audit/audit.rules configuration file
during the daemon startup (default configuration). Alternatively, the auditd
daemon can use the auditctl utility to read audit rules from the
/etc/audit/audit.rules configuration file during daemon startup,
and load them into the kernel. The expected behavior is configured via the
appropriate ExecStartPost directive setting in the
/usr/lib/systemd/system/auditd.service configuration file.
To instruct the auditd daemon to use the augenrules program
to read audit rules (default configuration), use the following setting:
ExecStartPost=-/sbin/augenrules --load
in the /usr/lib/systemd/system/auditd.service configuration file.
In order to instruct the auditd daemon to use the auditctl
utility to read audit rules, use the following setting:
ExecStartPost=-/sbin/auditctl -R /etc/audit/audit.rules
in the /usr/lib/systemd/system/auditd.service configuration file.
Refer to [Service] section of the /usr/lib/systemd/system/auditd.service
configuration file for further details.
Government networks often have substantial auditing
requirements and auditd can be configured to meet these
requirements.
Examining some example audit records demonstrates how the Linux audit system
satisfies common requirements.
The following example from Red Hat Enterprise Linux 7 Documentation available at
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html-single/selinux_users_and_administrators_guide/index#sect-Security-Enhanced_Linux-Fixing_Problems-Raw_Audit_Messages
shows the substantial amount of information captured in a
two typical "raw" audit messages, followed by a breakdown of the most important
fields. In this example the message is SELinux-related and reports an AVC
denial (and the associated system call) that occurred when the Apache HTTP
Server attempted to access the /var/www/html/file1 file (labeled with
the samba_share_t type):
type=AVC msg=audit(1226874073.147:96): avc: denied { getattr } for pid=2465 comm="httpd"
path="/var/www/html/file1" dev=dm-0 ino=284133 scontext=unconfined_u:system_r:httpd_t:s0
tcontext=unconfined_u:object_r:samba_share_t:s0 tclass=file
type=SYSCALL msg=audit(1226874073.147:96): arch=40000003 syscall=196 success=no exit=-13
a0=b98df198 a1=bfec85dc a2=54dff4 a3=2008171 items=0 ppid=2463 pid=2465 auid=502 uid=48
gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none) ses=6 comm="httpd"
exe="/usr/sbin/httpd" subj=unconfined_u:system_r:httpd_t:s0 key=(null)
msg=audit(1226874073.147:96) - The number in parentheses is the unformatted time stamp (Epoch time)
for the event, which can be converted to standard time by using the
date command.
{ getattr } - The item in braces indicates the permission that was denied.
getattr
indicates the source process was trying to read the target file's status information.
This occurs before reading files. This action is denied due to the file being
accessed having the wrong label. Commonly seen permissions include getattr ,
read , and write .
comm="httpd" - The executable that launched the process. The full path of the executable is
found in the
exe= section of the system call (SYSCALL ) message,
which in this case, is exe="/usr/sbin/httpd" .
path="/var/www/html/file1" - The path to the object (target) the process attempted to access.
scontext="unconfined_u:system_r:httpd_t:s0" - The SELinux context of the process that attempted the denied action. In
this case, it is the SELinux context of the Apache HTTP Server, which is running
in the
httpd_t domain.
tcontext="unconfined_u:object_r:samba_share_t:s0" - The SELinux context of the object (target) the process attempted to access.
In this case, it is the SELinux context of
file1 . Note: the samba_share_t
type is not accessible to processes running in the httpd_t domain.
- From the system call (
SYSCALL ) message, two items are of interest:
success=no : indicates whether the denial (AVC) was enforced or not.
success=no indicates the system call was not successful (SELinux denied
access). success=yes indicates the system call was successful - this can
be seen for permissive domains or unconfined domains, such as initrc_t
and kernel_t .
exe="/usr/sbin/httpd" : the full path to the executable that launched
the process, which in this case, is exe="/usr/sbin/httpd" .
|
Group
Configure auditd Data Retention
Group contains 4 rules |
[ref]
The audit system writes data to /var/log/audit/audit.log . By default,
auditd rotates 5 logs by size (6MB), retaining a maximum of 30MB of
data in total, and refuses to write entries when the disk is too
full. This minimizes the risk of audit data filling its partition
and impacting other services. This also minimizes the risk of the audit
daemon temporarily disabling the system if it cannot write audit log (which
it can be configured to do).
For a busy
system or a system which is thoroughly auditing system activity, the default settings
for data retention may be
insufficient. The log file size needed will depend heavily on what types
of events are being audited. First configure auditing to log all the events of
interest. Then monitor the log size manually for awhile to determine what file
size will allow you to keep the required data for the correct time period.
Using a dedicated partition for /var/log/audit prevents the
auditd logs from disrupting system functionality if they fill, and,
more importantly, prevents other activity in /var from filling the
partition and stopping the audit trail. (The audit logs are size-limited and
therefore unlikely to grow without bound unless configured to do so.) Some
machines may have requirements that no actions occur which cannot be audited.
If this is the case, then auditd can be configured to halt the machine
if it runs out of space. Note: Since older logs are rotated,
configuring auditd this way does not prevent older logs from being
rotated away before they can be viewed.
If your system is configured to halt when logging cannot be performed, make
sure this can never happen under normal circumstances! Ensure that
/var/log/audit is on its own partition, and that this partition is
larger than the maximum amount of data auditd will retain
normally. |
Rule
Configure auditd flush priority
[ref] | The auditd service can be configured to
synchronously write audit event data to disk. Add or correct the following
line in /etc/audit/auditd.conf to ensure that audit event data is
fully synchronized with the log files on the disk:
flush = incremental_async | Rationale: | Audit data should be synchronously written to disk to ensure
log integrity. These parameters assure that all audit event data is fully
synchronized with the log files on the disk. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_auditd_data_retention_flush | Identifiers and References | Identifiers:
CCE-83685-8 References:
1, 12, 13, 14, 15, 16, 2, 3, 5, 6, 7, 8, 9, APO10.01, APO10.03, APO10.04, APO10.05, APO11.04, BAI03.05, DSS01.03, DSS03.05, DSS05.02, DSS05.04, DSS05.05, DSS05.07, MEA01.01, MEA01.02, MEA01.03, MEA01.04, MEA01.05, MEA02.01, 3.3.1, CCI-001576, 164.308(a)(1)(ii)(D), 164.308(a)(3)(ii)(A), 164.308(a)(5)(ii)(C), 164.312(a)(2)(i), 164.312(b), 164.312(d), 164.312(e), 4.3.2.6.7, 4.3.3.3.9, 4.3.3.5.8, 4.3.4.4.7, 4.4.2.1, 4.4.2.2, 4.4.2.4, SR 2.10, SR 2.11, SR 2.12, SR 2.8, SR 2.9, SR 6.1, SR 6.2, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, A.14.2.7, A.15.2.1, A.15.2.2, CIP-004-6 R2.2.3, CIP-004-6 R3.3, CIP-007-3 R5.2, CIP-007-3 R5.3.1, CIP-007-3 R5.3.2, CIP-007-3 R5.3.3, CIP-007-3 R6.5, AU-11, CM-6(a), DE.CM-1, DE.CM-3, DE.CM-7, ID.SC-4, PR.PT-1, SRG-OS-000480-GPOS-00227 | |
|
Rule
Set number of records to cause an explicit flush to audit logs
[ref] | To configure Audit daemon to issue an explicit flush to disk command
after writing 50 records, set freq to 50
in /etc/audit/auditd.conf . | Rationale: | If option freq isn't set to 50 , the flush to disk
may happen after higher number of records, increasing the danger
of audit loss. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_auditd_freq | Identifiers and References | Identifiers:
CCE-83704-7 References:
CM-6, FAU_GEN.1, SRG-OS-000051-GPOS-00024 | |
|
Rule
Resolve information before writing to audit logs
[ref] | To configure Audit daemon to resolve all uid, gid, syscall,
architecture, and socket address information before writing the
events to disk, set log_format to ENRICHED
in /etc/audit/auditd.conf . | Rationale: | If option log_format isn't set to ENRICHED , the
audit records will be stored in a format exactly as the kernel sends them. | Severity: | low | Rule ID: | xccdf_org.ssgproject.content_rule_auditd_log_format | Identifiers and References | Identifiers:
CCE-83696-5 References:
CCI-000366, CM-6, AU-3, FAU_GEN.1.2, SRG-OS-000255-GPOS-00096, SRG-OS-000480-GPOS-00227 | |
|
Rule
Set hostname as computer node name in audit logs
[ref] | To configure Audit daemon to use value returned by gethostname
syscall as computer node name in the audit events,
set name_format to hostname
in /etc/audit/auditd.conf . | Rationale: | If option name_format is left at its default value of
none , audit events from different computers may be hard
to distinguish. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_auditd_name_format | Identifiers and References | Identifiers:
CCE-83686-6 References:
CCI-001851, CM-6, AU-3, FAU_GEN.1.2, SRG-OS-000039-GPOS-00017, SRG-OS-000342-GPOS-00133, SRG-OS-000479-GPOS-00224 | |
|
Group
System Accounting with auditd
Group contains 43 rules |
[ref]
The auditd program can perform comprehensive
monitoring of system activity. This section makes use of recommended
configuration settings for specific policies or use cases.
The rules in this section make use of rules defined in /usr/share/doc/audit-VERSION/rules . |
Rule
Configure auditing of unsuccessful file accesses
[ref] | Ensure that unsuccessful attempts to access a file are audited.
The following rules configure audit as described above:
## Unsuccessful file access (any other opens) This has to go last.
-a always,exit -F arch=b32 -S open,openat,openat2,open_by_handle_at -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=unsuccessful-access
-a always,exit -F arch=b64 -S open,openat,openat2,open_by_handle_at -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=unsuccessful-access
-a always,exit -F arch=b32 -S open,openat,openat2,open_by_handle_at -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=unsuccessful-access
-a always,exit -F arch=b64 -S open,openat,openat2,open_by_handle_at -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=unsuccessful-access
Load new Audit rules into kernel by running:
augenrules --load
Note: This rule uses a special set of Audit rules to comply with OSPP 4.2.1. You may reuse this rule in different profiles. If you decide to do so, it is recommended that you inspect contents of the file closely and make sure that they are alligned with your needs. | Rationale: | Unsuccessful attempts to access a file might be signs of malicious activity happening within the system. Auditing of such activities helps in their monitoring and investigation. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_audit_access_failed | Identifiers and References | Identifiers:
CCE-83672-6 References:
0582, 0584, 05885, 0586, 0846, 0957, AU-2(a), FAU_GEN.1.1.c, SRG-OS-000458-GPOS-00203, SRG-OS-000474-GPOS-00219, SRG-OS-000475-GPOS-00220, SRG-OS-000463-GPOS-00207, SRG-OS-000465-GPOS-00209, SRG-OS-000461-GPOS-00205 | |
|
Rule
Configure auditing of unsuccessful file accesses (AArch64)
[ref] | Ensure that unsuccessful attempts to access a file are audited.
The following rules configure audit as described above:
## Unsuccessful file access (any other opens) This has to go last.
-a always,exit -F arch=b32 -S open,openat,openat2,open_by_handle_at -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=unsuccessful-access
-a always,exit -F arch=b64 -S openat,openat2,open_by_handle_at -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=unsuccessful-access
-a always,exit -F arch=b32 -S open,openat,openat2,open_by_handle_at -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=unsuccessful-access
-a always,exit -F arch=b64 -S openat,openat2,open_by_handle_at -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=unsuccessful-access
Load new Audit rules into kernel by running:
augenrules --load
Note: This rule uses a special set of Audit rules to comply with OSPP 4.2.1. You may reuse this rule in different profiles. If you decide to do so, it is recommended that you inspect contents of the file closely and make sure that they are alligned with your needs. | Rationale: | Unsuccessful attempts to access a file might be signs of malicious activity happening within the system. Auditing of such activities helps in their monitoring and investigation. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_audit_access_failed_aarch64 | Identifiers and References | Identifiers:
CCE-85922-3 References:
0582, 0584, 05885, 0586, 0846, 0957, AU-2(a), FAU_GEN.1.1.c, SRG-OS-000458-GPOS-00203, SRG-OS-000474-GPOS-00219, SRG-OS-000475-GPOS-00220, SRG-OS-000463-GPOS-00207, SRG-OS-000465-GPOS-00209, SRG-OS-000461-GPOS-00205 | |
|
Rule
Configure auditing of unsuccessful file accesses (ppc64le)
[ref] | Ensure that unsuccessful attempts to access a file are audited.
The following rules configure audit as described above:
## Unsuccessful file access (any other opens) This has to go last.
-a always,exit -F arch=b64 -S open,openat,openat2,open_by_handle_at -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=unsuccessful-access
-a always,exit -F arch=b64 -S open,openat,openat2,open_by_handle_at -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=unsuccessful-access
Load new Audit rules into kernel by running:
augenrules --load
Note: This rule uses a special set of Audit rules to comply with OSPP 4.2.1. You may reuse this rule in different profiles. If you decide to do so, it is recommended that you inspect contents of the file closely and make sure that they are alligned with your needs. | Rationale: | Unsuccessful attempts to access a file might be signs of malicious activity happening within the system. Auditing of such activities helps in their monitoring and investigation. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_audit_access_failed_ppc64le | Identifiers and References | Identifiers:
CCE-86001-5 References:
0582, 0584, 05885, 0586, 0846, 0957, AU-2(a), FAU_GEN.1.1.c, SRG-OS-000458-GPOS-00203, SRG-OS-000474-GPOS-00219, SRG-OS-000475-GPOS-00220, SRG-OS-000463-GPOS-00207, SRG-OS-000465-GPOS-00209, SRG-OS-000461-GPOS-00205 | |
|
Rule
Configure auditing of successful file accesses
[ref] | Ensure that successful attempts to access a file are audited.
The following rules configure audit as described above:
## Successful file access (any other opens) This has to go last.
## These next two are likely to result in a whole lot of events
-a always,exit -F arch=b32 -S open,openat,openat2,open_by_handle_at -F success=1 -F auid>=1000 -F auid!=unset -F key=successful-access
-a always,exit -F arch=b64 -S open,openat,openat2,open_by_handle_at -F success=1 -F auid>=1000 -F auid!=unset -F key=successful-access
Load new Audit rules into kernel by running:
augenrules --load
Note: This rule uses a special set of Audit rules to comply with OSPP 4.2.1. You may reuse this rule in different profiles. If you decide to do so, it is recommended that you inspect contents of the file closely and make sure that they are alligned with your needs. | Rationale: | Auditing of successful attempts to access a file helps in investigation of activities performed on the system. | Severity: | info | Rule ID: | xccdf_org.ssgproject.content_rule_audit_access_success | Identifiers and References | Identifiers:
CCE-83653-6 References:
0582, 0584, 05885, 0586, 0846, 0957, AU-2(a), FAU_GEN.1.1.c, SRG-OS-000458-GPOS-00203, SRG-OS-000474-GPOS-00219, SRG-OS-000475-GPOS-00220, SRG-OS-000463-GPOS-00207, SRG-OS-000465-GPOS-00209, SRG-OS-000461-GPOS-00205 | |
|
Rule
Configure auditing of successful file accesses (AArch64)
[ref] | Ensure that successful attempts to access a file are audited.
The following rules configure audit as described above:
## Successful file access (any other opens) This has to go last.
## These next two are likely to result in a whole lot of events
-a always,exit -F arch=b32 -S open,openat,openat2,open_by_handle_at -F success=1 -F auid>=1000 -F auid!=unset -F key=successful-access
-a always,exit -F arch=b64 -S openat,openat2,open_by_handle_at -F success=1 -F auid>=1000 -F auid!=unset -F key=successful-access
Load new Audit rules into kernel by running:
augenrules --load
Note: This rule uses a special set of Audit rules to comply with OSPP 4.2.1. You may reuse this rule in different profiles. If you decide to do so, it is recommended that you inspect contents of the file closely and make sure that they are alligned with your needs. | Rationale: | Auditing of successful attempts to access a file helps in investigation of activities performed on the system. | Severity: | info | Rule ID: | xccdf_org.ssgproject.content_rule_audit_access_success_aarch64 | Identifiers and References | Identifiers:
CCE-85924-9 References:
0582, 0584, 05885, 0586, 0846, 0957, AU-2(a), FAU_GEN.1.1.c, SRG-OS-000458-GPOS-00203, SRG-OS-000474-GPOS-00219, SRG-OS-000475-GPOS-00220, SRG-OS-000463-GPOS-00207, SRG-OS-000465-GPOS-00209, SRG-OS-000461-GPOS-00205 | |
|
Rule
Configure auditing of successful file accesses (ppc64le)
[ref] | Ensure that successful attempts to access a file are audited.
The following rules configure audit as described above:
## Successful file access (any other opens) This has to go last.
## These next two are likely to result in a whole lot of events
-a always,exit -F arch=b64 -S open,openat,openat2,open_by_handle_at -F success=1 -F auid>=1000 -F auid!=unset -F key=successful-access
Load new Audit rules into kernel by running:
augenrules --load
Note: This rule uses a special set of Audit rules to comply with OSPP 4.2.1. You may reuse this rule in different profiles. If you decide to do so, it is recommended that you inspect contents of the file closely and make sure that they are alligned with your needs. | Rationale: | Auditing of successful attempts to access a file helps in investigation of activities performed on the system. | Severity: | info | Rule ID: | xccdf_org.ssgproject.content_rule_audit_access_success_ppc64le | Identifiers and References | Identifiers:
CCE-85999-1 References:
0582, 0584, 05885, 0586, 0846, 0957, AU-2(a), FAU_GEN.1.1.c, SRG-OS-000458-GPOS-00203, SRG-OS-000474-GPOS-00219, SRG-OS-000475-GPOS-00220, SRG-OS-000463-GPOS-00207, SRG-OS-000465-GPOS-00209, SRG-OS-000461-GPOS-00205 | |
|
Rule
Configure basic parameters of Audit system
[ref] | Perform basic configuration of Audit system.
Make sure that any previously defined rules are cleared, the auditing system is configured to handle sudden bursts of events, and in cases of failure, messages are configured to be directed to system log.
The following rules configure audit as described above:
## First rule - delete all
-D
## Increase the buffers to survive stress events.
## Make this bigger for busy systems
-b 8192
## This determine how long to wait in burst of events
--backlog_wait_time 60000
## Set failure mode to syslog
-f 1
Load new Audit rules into kernel by running:
augenrules --load Warning:
It might happen that Audit buffer configured by this rule is not large enough for certain use cases. If that is the case, the buffer size can be overridden by placing -b larger_buffer_size into a file within /etc/audit/rules.d directory, replacing larger_file_size with the desired value. The file name should start with a number higher than 10 and lower than 99. | Rationale: | Without basic configurations, audit may not perform as expected. It may not be able to correctly handle events under stressful conditions, or log events in case of failure. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_audit_basic_configuration | Identifiers and References | Identifiers:
CCE-83670-0 References:
AU-2(a), FAU_GEN.1, SRG-OS-000365-GPOS-00152, SRG-OS-000475-GPOS-00220 | |
|
Rule
Configure auditing of unsuccessful file creations
[ref] | Ensure that unsuccessful attempts to create a file are audited.
The following rules configure audit as described above:
## Unsuccessful file creation (open with O_CREAT)
-a always,exit -F arch=b32 -S openat,open_by_handle_at -F a2&0100 -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=unsuccessful-create
-a always,exit -F arch=b64 -S openat,open_by_handle_at -F a2&0100 -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=unsuccessful-create
-a always,exit -F arch=b32 -S open -F a1&0100 -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=unsuccessful-create
-a always,exit -F arch=b64 -S open -F a1&0100 -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=unsuccessful-create
-a always,exit -F arch=b32 -S creat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=unsuccessful-create
-a always,exit -F arch=b64 -S creat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=unsuccessful-create
-a always,exit -F arch=b32 -S openat,open_by_handle_at -F a2&0100 -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=unsuccessful-create
-a always,exit -F arch=b64 -S openat,open_by_handle_at -F a2&0100 -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=unsuccessful-create
-a always,exit -F arch=b32 -S open -F a1&0100 -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=unsuccessful-create
-a always,exit -F arch=b64 -S open -F a1&0100 -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=unsuccessful-create
-a always,exit -F arch=b32 -S creat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=unsuccessful-create
-a always,exit -F arch=b64 -S creat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=unsuccessful-create
Load new Audit rules into kernel by running:
augenrules --load
Note: This rule uses a special set of Audit rules to comply with OSPP 4.2.1. You may reuse this rule in different profiles. If you decide to do so, it is recommended that you inspect contents of the file closely and make sure that they are alligned with your needs. | Rationale: | Unsuccessful file creations might be a sign of a malicious action being performed on the system. Keeping log of such events helps in monitoring and investigation of such actions. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_audit_create_failed | Identifiers and References | Identifiers:
CCE-83669-2 References:
AU-2(a), FAU_GEN.1.1.c, SRG-OS-000458-GPOS-00203, SRG-OS-000474-GPOS-00219, SRG-OS-000475-GPOS-00220, SRG-OS-000463-GPOS-00207, SRG-OS-000465-GPOS-00209, SRG-OS-000461-GPOS-00205 | |
|
Rule
Configure auditing of unsuccessful file creations (AArch64)
[ref] | Ensure that unsuccessful attempts to create a file are audited.
The following rules configure audit as described above:
## Unsuccessful file creation (open with O_CREAT)
-a always,exit -F arch=b32 -S openat,open_by_handle_at -F a2&0100 -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=unsuccessful-create
-a always,exit -F arch=b64 -S openat,open_by_handle_at -F a2&0100 -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=unsuccessful-create
-a always,exit -F arch=b32 -S open -F a1&0100 -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=unsuccessful-create
-a always,exit -F arch=b32 -S creat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=unsuccessful-create
-a always,exit -F arch=b32 -S openat,open_by_handle_at -F a2&0100 -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=unsuccessful-create
-a always,exit -F arch=b64 -S openat,open_by_handle_at -F a2&0100 -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=unsuccessful-create
-a always,exit -F arch=b32 -S open -F a1&0100 -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=unsuccessful-create
-a always,exit -F arch=b32 -S creat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=unsuccessful-create
Load new Audit rules into kernel by running:
augenrules --load
Note: This rule uses a special set of Audit rules to comply with OSPP 4.2.1. You may reuse this rule in different profiles. If you decide to do so, it is recommended that you inspect contents of the file closely and make sure that they are alligned with your needs. | Rationale: | Unsuccessful file creations might be a sign of a malicious action being performed on the system. Keeping log of such events helps in monitoring and investigation of such actions. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_audit_create_failed_aarch64 | Identifiers and References | Identifiers:
CCE-85898-5 References:
AU-2(a), FAU_GEN.1.1.c, SRG-OS-000458-GPOS-00203, SRG-OS-000474-GPOS-00219, SRG-OS-000475-GPOS-00220, SRG-OS-000463-GPOS-00207, SRG-OS-000465-GPOS-00209, SRG-OS-000461-GPOS-00205 | |
|
Rule
Configure auditing of unsuccessful file creations (ppc64le)
[ref] | Ensure that unsuccessful attempts to create a file are audited.
The following rules configure audit as described above:
## Unsuccessful file creation (open with O_CREAT)
-a always,exit -F arch=b64 -S openat,open_by_handle_at -F a2&0100 -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=unsuccessful-create
-a always,exit -F arch=b64 -S open -F a1&0100 -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=unsuccessful-create
-a always,exit -F arch=b64 -S creat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=unsuccessful-create
-a always,exit -F arch=b64 -S openat,open_by_handle_at -F a2&0100 -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=unsuccessful-create
-a always,exit -F arch=b64 -S open -F a1&0100 -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=unsuccessful-create
-a always,exit -F arch=b64 -S creat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=unsuccessful-create
Load new Audit rules into kernel by running:
augenrules --load
Note: This rule uses a special set of Audit rules to comply with OSPP 4.2.1. You may reuse this rule in different profiles. If you decide to do so, it is recommended that you inspect contents of the file closely and make sure that they are alligned with your needs. | Rationale: | Unsuccessful file creations might be a sign of a malicious action being performed on the system. Keeping log of such events helps in monitoring and investigation of such actions. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_audit_create_failed_ppc64le | Identifiers and References | Identifiers:
CCE-85997-5 References:
AU-2(a), FAU_GEN.1.1.c, SRG-OS-000458-GPOS-00203, SRG-OS-000474-GPOS-00219, SRG-OS-000475-GPOS-00220, SRG-OS-000463-GPOS-00207, SRG-OS-000465-GPOS-00209, SRG-OS-000461-GPOS-00205 | |
|
Rule
Configure auditing of successful file creations
[ref] | Ensure that successful attempts to create a file are audited.
The following rules configure audit as described above:
## Successful file creation (open with O_CREAT)
-a always,exit -F arch=b32 -S openat,open_by_handle_at -F a2&0100 -F success=1 -F auid>=1000 -F auid!=unset -F key=successful-create
-a always,exit -F arch=b64 -S openat,open_by_handle_at -F a2&0100 -F success=1 -F auid>=1000 -F auid!=unset -F key=successful-create
-a always,exit -F arch=b32 -S open -F a1&0100 -F success=1 -F auid>=1000 -F auid!=unset -F key=successful-create
-a always,exit -F arch=b64 -S open -F a1&0100 -F success=1 -F auid>=1000 -F auid!=unset -F key=successful-create
-a always,exit -F arch=b32 -S creat -F success=1 -F auid>=1000 -F auid!=unset -F key=successful-create
-a always,exit -F arch=b64 -S creat -F success=1 -F auid>=1000 -F auid!=unset -F key=successful-create
Load new Audit rules into kernel by running:
augenrules --load
Note: This rule uses a special set of Audit rules to comply with OSPP 4.2.1. You may reuse this rule in different profiles. If you decide to do so, it is recommended that you inspect contents of the file closely and make sure that they are alligned with your needs. | Rationale: | Auditing of successful attempts to create a file helps in investigation of actions which happened on the system. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_audit_create_success | Identifiers and References | Identifiers:
CCE-83668-4 References:
AU-2(a), FAU_GEN.1.1.c, SRG-OS-000458-GPOS-00203, SRG-OS-000474-GPOS-00219, SRG-OS-000475-GPOS-00220, SRG-OS-000463-GPOS-00207, SRG-OS-000465-GPOS-00209, SRG-OS-000461-GPOS-00205 | |
|
Rule
Configure auditing of successful file creations (AArch64)
[ref] | Ensure that successful attempts to create a file are audited.
The following rules configure audit as described above:
## Successful file creation (open with O_CREAT)
-a always,exit -F arch=b32 -S openat,open_by_handle_at -F a2&0100 -F success=1 -F auid>=1000 -F auid!=unset -F key=successful-create
-a always,exit -F arch=b64 -S openat,open_by_handle_at -F a2&0100 -F success=1 -F auid>=1000 -F auid!=unset -F key=successful-create
-a always,exit -F arch=b32 -S open -F a1&0100 -F success=1 -F auid>=1000 -F auid!=unset -F key=successful-create
-a always,exit -F arch=b32 -S creat -F success=1 -F auid>=1000 -F auid!=unset -F key=successful-create
Load new Audit rules into kernel by running:
augenrules --load
Note: This rule uses a special set of Audit rules to comply with OSPP 4.2.1. You may reuse this rule in different profiles. If you decide to do so, it is recommended that you inspect contents of the file closely and make sure that they are alligned with your needs. | Rationale: | Auditing of successful attempts to create a file helps in investigation of actions which happened on the system. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_audit_create_success_aarch64 | Identifiers and References | Identifiers:
CCE-85905-8 References:
AU-2(a), FAU_GEN.1.1.c, SRG-OS-000458-GPOS-00203, SRG-OS-000474-GPOS-00219, SRG-OS-000475-GPOS-00220, SRG-OS-000463-GPOS-00207, SRG-OS-000465-GPOS-00209, SRG-OS-000461-GPOS-00205 | |
|
Rule
Configure auditing of successful file creations (ppc64le)
[ref] | Ensure that successful attempts to create a file are audited.
The following rules configure audit as described above:
## Successful file creation (open with O_CREAT)
-a always,exit -F arch=b64 -S openat,open_by_handle_at -F a2&0100 -F success=1 -F auid>=1000 -F auid!=unset -F key=successful-create
-a always,exit -F arch=b64 -S open -F a1&0100 -F success=1 -F auid>=1000 -F auid!=unset -F key=successful-create
-a always,exit -F arch=b64 -S creat -F success=1 -F auid>=1000 -F auid!=unset -F key=successful-create
Load new Audit rules into kernel by running:
augenrules --load
Note: This rule uses a special set of Audit rules to comply with OSPP 4.2.1. You may reuse this rule in different profiles. If you decide to do so, it is recommended that you inspect contents of the file closely and make sure that they are alligned with your needs. | Rationale: | Auditing of successful attempts to create a file helps in investigation of actions which happened on the system. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_audit_create_success_ppc64le | Identifiers and References | Identifiers:
CCE-85985-0 References:
AU-2(a), FAU_GEN.1.1.c, SRG-OS-000458-GPOS-00203, SRG-OS-000474-GPOS-00219, SRG-OS-000475-GPOS-00220, SRG-OS-000463-GPOS-00207, SRG-OS-000465-GPOS-00209, SRG-OS-000461-GPOS-00205 | |
|
Rule
Configure auditing of unsuccessful file deletions
[ref] | Ensure that unsuccessful attempts to delete a file are audited.
The following rules configure audit as described above:
## Unsuccessful file delete
-a always,exit -F arch=b32 -S unlink,unlinkat,rename,renameat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=unsuccessful-delete
-a always,exit -F arch=b64 -S unlink,unlinkat,rename,renameat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=unsuccessful-delete
-a always,exit -F arch=b32 -S unlink,unlinkat,rename,renameat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=unsuccessful-delete
-a always,exit -F arch=b64 -S unlink,unlinkat,rename,renameat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=unsuccessful-delete
Load new Audit rules into kernel by running:
augenrules --load
Note: This rule uses a special set of Audit rules to comply with OSPP 4.2.1. You may reuse this rule in different profiles. If you decide to do so, it is recommended that you inspect contents of the file closely and make sure that they are alligned with your needs. | Rationale: | Unsuccessful attempts to delete a file might be signs of malicious activities. Auditing of such events help in monitoring and investigating of such activities. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_audit_delete_failed | Identifiers and References | Identifiers:
CCE-83667-6 References:
AU-2(a), FAU_GEN.1.1.c, SRG-OS-000458-GPOS-00203, SRG-OS-000474-GPOS-00219, SRG-OS-000475-GPOS-00220, SRG-OS-000463-GPOS-00207, SRG-OS-000465-GPOS-00209, SRG-OS-000461-GPOS-00205, SRG-OS-000468-GPOS-00212 | |
|
Rule
Configure auditing of unsuccessful file deletions (AArch64)
[ref] | Ensure that unsuccessful attempts to delete a file are audited.
The following rules configure audit as described above:
## Unsuccessful file delete
-a always,exit -F arch=b32 -S unlink,unlinkat,rename,renameat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=unsuccessful-delete
-a always,exit -F arch=b64 -S unlinkat,renameat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=unsuccessful-delete
-a always,exit -F arch=b32 -S unlink,unlinkat,rename,renameat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=unsuccessful-delete
-a always,exit -F arch=b64 -S unlinkat,renameat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=unsuccessful-delete
Load new Audit rules into kernel by running:
augenrules --load
Note: This rule uses a special set of Audit rules to comply with OSPP 4.2.1. You may reuse this rule in different profiles. If you decide to do so, it is recommended that you inspect contents of the file closely and make sure that they are alligned with your needs. | Rationale: | Unsuccessful attempts to delete a file might be signs of malicious activities. Auditing of such events help in monitoring and investigating of such activities. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_audit_delete_failed_aarch64 | Identifiers and References | Identifiers:
CCE-85937-1 References:
AU-2(a), FAU_GEN.1.1.c, SRG-OS-000458-GPOS-00203, SRG-OS-000474-GPOS-00219, SRG-OS-000475-GPOS-00220, SRG-OS-000463-GPOS-00207, SRG-OS-000465-GPOS-00209, SRG-OS-000461-GPOS-00205, SRG-OS-000468-GPOS-00212 | |
|
Rule
Configure auditing of unsuccessful file deletions (ppc64le)
[ref] | Ensure that unsuccessful attempts to delete a file are audited.
The following rules configure audit as described above:
## Unsuccessful file delete
-a always,exit -F arch=b64 -S unlink,unlinkat,rename,renameat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=unsuccessful-delete
-a always,exit -F arch=b64 -S unlink,unlinkat,rename,renameat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=unsuccessful-delete
Load new Audit rules into kernel by running:
augenrules --load
Note: This rule uses a special set of Audit rules to comply with OSPP 4.2.1. You may reuse this rule in different profiles. If you decide to do so, it is recommended that you inspect contents of the file closely and make sure that they are alligned with your needs. | Rationale: | Unsuccessful attempts to delete a file might be signs of malicious activities. Auditing of such events help in monitoring and investigating of such activities. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_audit_delete_failed_ppc64le | Identifiers and References | Identifiers:
CCE-90787-3 References:
AU-2(a), FAU_GEN.1.1.c, SRG-OS-000458-GPOS-00203, SRG-OS-000474-GPOS-00219, SRG-OS-000475-GPOS-00220, SRG-OS-000463-GPOS-00207, SRG-OS-000465-GPOS-00209, SRG-OS-000461-GPOS-00205, SRG-OS-000468-GPOS-00212 | |
|
Rule
Configure auditing of successful file deletions
[ref] | Ensure that successful attempts to delete a file are audited.
The following rules configure audit as described above:
## Successful file delete
-a always,exit -F arch=b32 -S unlink,unlinkat,rename,renameat -F success=1 -F auid>=1000 -F auid!=unset -F key=successful-delete
-a always,exit -F arch=b64 -S unlink,unlinkat,rename,renameat -F success=1 -F auid>=1000 -F auid!=unset -F key=successful-delete
Load new Audit rules into kernel by running:
augenrules --load
Note: This rule uses a special set of Audit rules to comply with OSPP 4.2.1. You may reuse this rule in different profiles. If you decide to do so, it is recommended that you inspect contents of the file closely and make sure that they are alligned with your needs. | Rationale: | Auditing of successful attempts to delete a file may help in monitoring and investigation of activities performed on the system. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_audit_delete_success | Identifiers and References | Identifiers:
CCE-83680-9 References:
AU-2(a), FAU_GEN.1.1.c, SRG-OS-000458-GPOS-00203, SRG-OS-000474-GPOS-00219, SRG-OS-000475-GPOS-00220, SRG-OS-000463-GPOS-00207, SRG-OS-000465-GPOS-00209, SRG-OS-000461-GPOS-00205, SRG-OS-000468-GPOS-00212 | |
|
Rule
Configure auditing of successful file deletions (AArch64)
[ref] | Ensure that successful attempts to delete a file are audited.
The following rules configure audit as described above:
## Successful file delete
-a always,exit -F arch=b32 -S unlink,unlinkat,rename,renameat -F success=1 -F auid>=1000 -F auid!=unset -F key=successful-delete
-a always,exit -F arch=b64 -S unlinkat,renameat -F success=1 -F auid>=1000 -F auid!=unset -F key=successful-delete
Load new Audit rules into kernel by running:
augenrules --load
Note: This rule uses a special set of Audit rules to comply with OSPP 4.2.1. You may reuse this rule in different profiles. If you decide to do so, it is recommended that you inspect contents of the file closely and make sure that they are alligned with your needs. | Rationale: | Auditing of successful attempts to delete a file may help in monitoring and investigation of activities performed on the system. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_audit_delete_success_aarch64 | Identifiers and References | Identifiers:
CCE-85939-7 References:
AU-2(a), FAU_GEN.1.1.c, SRG-OS-000458-GPOS-00203, SRG-OS-000474-GPOS-00219, SRG-OS-000475-GPOS-00220, SRG-OS-000463-GPOS-00207, SRG-OS-000465-GPOS-00209, SRG-OS-000461-GPOS-00205, SRG-OS-000468-GPOS-00212 | |
|
Rule
Configure auditing of successful file deletions (ppc64le)
[ref] | Ensure that successful attempts to delete a file are audited.
The following rules configure audit as described above:
## Successful file delete
-a always,exit -F arch=b64 -S unlink,unlinkat,rename,renameat -F success=1 -F auid>=1000 -F auid!=unset -F key=successful-delete
Load new Audit rules into kernel by running:
augenrules --load
Note: This rule uses a special set of Audit rules to comply with OSPP 4.2.1. You may reuse this rule in different profiles. If you decide to do so, it is recommended that you inspect contents of the file closely and make sure that they are alligned with your needs. | Rationale: | Auditing of successful attempts to delete a file may help in monitoring and investigation of activities performed on the system. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_audit_delete_success_ppc64le | Identifiers and References | Identifiers:
CCE-90789-9 References:
AU-2(a), FAU_GEN.1.1.c, SRG-OS-000458-GPOS-00203, SRG-OS-000474-GPOS-00219, SRG-OS-000475-GPOS-00220, SRG-OS-000463-GPOS-00207, SRG-OS-000465-GPOS-00209, SRG-OS-000461-GPOS-00205, SRG-OS-000468-GPOS-00212 | |
|
Rule
Configure immutable Audit login UIDs
[ref] | Configure kernel to prevent modification of login UIDs once they are set.
Changing login UIDs while this configuration is enforced requires special capabilities which
are not available to unprivileged users.
The following rules configure audit as described above:
## Make the loginuid immutable. This prevents tampering with the auid.
--loginuid-immutable
Load new Audit rules into kernel by running:
augenrules --load | Rationale: | If modification of login UIDs is not prevented, they can be changed by unprivileged users and
make auditing complicated or impossible. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_audit_immutable_login_uids | Identifiers and References | Identifiers:
CCE-83673-4 References:
CCI-000162, CCI-000163, CCI-000164, AU-2(a), FAU_GEN.1.2, SRG-OS-000462-GPOS-00206, SRG-OS-000475-GPOS-00220, SRG-OS-000057-GPOS-00027, SRG-OS-000058-GPOS-00028, SRG-OS-000059-GPOS-00029 | |
|
Rule
Configure auditing of unsuccessful file modifications
[ref] | Ensure that unsuccessful attempts to modify a file are audited.
The following rules configure audit as described above:
## Unsuccessful file modifications (open for write or truncate)
-a always,exit -F arch=b32 -S openat,open_by_handle_at -F a2&01003 -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=unsuccessful-modification
-a always,exit -F arch=b64 -S openat,open_by_handle_at -F a2&01003 -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=unsuccessful-modification
-a always,exit -F arch=b32 -S open -F a1&01003 -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=unsuccessful-modification
-a always,exit -F arch=b64 -S open -F a1&01003 -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=unsuccessful-modification
-a always,exit -F arch=b32 -S truncate,ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=unsuccessful-modification
-a always,exit -F arch=b64 -S truncate,ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=unsuccessful-modification
-a always,exit -F arch=b32 -S openat,open_by_handle_at -F a2&01003 -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=unsuccessful-modification
-a always,exit -F arch=b64 -S openat,open_by_handle_at -F a2&01003 -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=unsuccessful-modification
-a always,exit -F arch=b32 -S open -F a1&01003 -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=unsuccessful-modification
-a always,exit -F arch=b64 -S open -F a1&01003 -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=unsuccessful-modification
-a always,exit -F arch=b32 -S truncate,ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=unsuccessful-modification
-a always,exit -F arch=b64 -S truncate,ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=unsuccessful-modification
Load new Audit rules into kernel by running:
augenrules --load
Note: This rule uses a special set of Audit rules to comply with OSPP 4.2.1. You may reuse this rule in different profiles. If you decide to do so, it is recommended that you inspect contents of the file closely and make sure that they are alligned with your needs. | Rationale: | Unsuccessful file modifications might be a sign of a malicious action being performed on the system. Auditing of such events helps in detection and investigation of such actions. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_audit_modify_failed | Identifiers and References | Identifiers:
CCE-83671-8 References:
AU-2(a), FAU_GEN.1.1.c, SRG-OS-000458-GPOS-00203, SRG-OS-000474-GPOS-00219, SRG-OS-000475-GPOS-00220, SRG-OS-000463-GPOS-00207, SRG-OS-000465-GPOS-00209, SRG-OS-000461-GPOS-00205 | |
|
Rule
Configure auditing of unsuccessful file modifications (AARch64)
[ref] | Ensure that unsuccessful attempts to modify a file are audited.
The following rules configure audit as described above:
## Unsuccessful file modifications (open for write or truncate)
-a always,exit -F arch=b32 -S openat,open_by_handle_at -F a2&01003 -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=unsuccessful-modification
-a always,exit -F arch=b64 -S openat,open_by_handle_at -F a2&01003 -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=unsuccessful-modification
-a always,exit -F arch=b32 -S open -F a1&01003 -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=unsuccessful-modification
-a always,exit -F arch=b32 -S truncate,ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=unsuccessful-modification
-a always,exit -F arch=b64 -S truncate,ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=unsuccessful-modification
-a always,exit -F arch=b32 -S openat,open_by_handle_at -F a2&01003 -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=unsuccessful-modification
-a always,exit -F arch=b64 -S openat,open_by_handle_at -F a2&01003 -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=unsuccessful-modification
-a always,exit -F arch=b32 -S open -F a1&01003 -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=unsuccessful-modification
-a always,exit -F arch=b32 -S truncate,ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=unsuccessful-modification
-a always,exit -F arch=b64 -S truncate,ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=unsuccessful-modification
Load new Audit rules into kernel by running:
augenrules --load
Note: This rule uses a special set of Audit rules to comply with OSPP 4.2.1. You may reuse this rule in different profiles. If you decide to do so, it is recommended that you inspect contents of the file closely and make sure that they are alligned with your needs. | Rationale: | Unsuccessful file modifications might be a sign of a malicious action being performed on the system. Auditing of such events helps in detection and investigation of such actions. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_audit_modify_failed_aarch64 | Identifiers and References | Identifiers:
CCE-85907-4 References:
AU-2(a), FAU_GEN.1.1.c, SRG-OS-000458-GPOS-00203, SRG-OS-000474-GPOS-00219, SRG-OS-000475-GPOS-00220, SRG-OS-000463-GPOS-00207, SRG-OS-000465-GPOS-00209, SRG-OS-000461-GPOS-00205 | |
|
Rule
Configure auditing of unsuccessful file modifications (ppc64le)
[ref] | Ensure that unsuccessful attempts to modify a file are audited.
The following rules configure audit as described above:
## Unsuccessful file modifications (open for write or truncate)
-a always,exit -F arch=b64 -S openat,open_by_handle_at -F a2&01003 -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=unsuccessful-modification
-a always,exit -F arch=b64 -S open -F a1&01003 -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=unsuccessful-modification
-a always,exit -F arch=b64 -S truncate,ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=unsuccessful-modification
-a always,exit -F arch=b64 -S openat,open_by_handle_at -F a2&01003 -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=unsuccessful-modification
-a always,exit -F arch=b64 -S open -F a1&01003 -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=unsuccessful-modification
-a always,exit -F arch=b64 -S truncate,ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=unsuccessful-modification
Load new Audit rules into kernel by running:
augenrules --load
Note: This rule uses a special set of Audit rules to comply with OSPP 4.2.1. You may reuse this rule in different profiles. If you decide to do so, it is recommended that you inspect contents of the file closely and make sure that they are alligned with your needs. | Rationale: | Unsuccessful file modifications might be a sign of a malicious action being performed on the system. Auditing of such events helps in detection and investigation of such actions. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_audit_modify_failed_ppc64le | Identifiers and References | Identifiers:
CCE-90790-7 References:
AU-2(a), FAU_GEN.1.1.c, SRG-OS-000458-GPOS-00203, SRG-OS-000474-GPOS-00219, SRG-OS-000475-GPOS-00220, SRG-OS-000463-GPOS-00207, SRG-OS-000465-GPOS-00209, SRG-OS-000461-GPOS-00205 | |
|
Rule
Configure auditing of successful file modifications
[ref] | Ensure that successful attempts to modify a file are audited.
The following rules configure audit as described above:
## Successful file modifications (open for write or truncate)
-a always,exit -F arch=b32 -S openat,open_by_handle_at -F a2&01003 -F success=1 -F auid>=1000 -F auid!=unset -F key=successful-modification
-a always,exit -F arch=b64 -S openat,open_by_handle_at -F a2&01003 -F success=1 -F auid>=1000 -F auid!=unset -F key=successful-modification
-a always,exit -F arch=b32 -S open -F a1&01003 -F success=1 -F auid>=1000 -F auid!=unset -F key=successful-modification
-a always,exit -F arch=b64 -S open -F a1&01003 -F success=1 -F auid>=1000 -F auid!=unset -F key=successful-modification
-a always,exit -F arch=b32 -S truncate,ftruncate -F success=1 -F auid>=1000 -F auid!=unset -F key=successful-modification
-a always,exit -F arch=b64 -S truncate,ftruncate -F success=1 -F auid>=1000 -F auid!=unset -F key=successful-modification
Load new Audit rules into kernel by running:
augenrules --load
Note: This rule uses a special set of Audit rules to comply with OSPP 4.2.1. You may reuse this rule in different profiles. If you decide to do so, it is recommended that you inspect contents of the file closely and make sure that they are alligned with your needs. | Rationale: | Auditing of successful attempts to modify a file helps in investigation of actions which happened on the system. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_audit_modify_success | Identifiers and References | Identifiers:
CCE-83681-7 References:
AU-2(a), FAU_GEN.1.1.c, SRG-OS-000458-GPOS-00203, SRG-OS-000474-GPOS-00219, SRG-OS-000475-GPOS-00220, SRG-OS-000463-GPOS-00207, SRG-OS-000465-GPOS-00209, SRG-OS-000461-GPOS-00205 | |
|
Rule
Configure auditing of successful file modifications (AArch64)
[ref] | Ensure that successful attempts to modify a file are audited.
The following rules configure audit as described above:
## Successful file modifications (open for write or truncate)
-a always,exit -F arch=b32 -S openat,open_by_handle_at -F a2&01003 -F success=1 -F auid>=1000 -F auid!=unset -F key=successful-modification
-a always,exit -F arch=b64 -S openat,open_by_handle_at -F a2&01003 -F success=1 -F auid>=1000 -F auid!=unset -F key=successful-modification
-a always,exit -F arch=b32 -S open -F a1&01003 -F success=1 -F auid>=1000 -F auid!=unset -F key=successful-modification
-a always,exit -F arch=b32 -S truncate,ftruncate -F success=1 -F auid>=1000 -F auid!=unset -F key=successful-modification
-a always,exit -F arch=b64 -S truncate,ftruncate -F success=1 -F auid>=1000 -F auid!=unset -F key=successful-modification
Load new Audit rules into kernel by running:
augenrules --load
Note: This rule uses a special set of Audit rules to comply with OSPP 4.2.1. You may reuse this rule in different profiles. If you decide to do so, it is recommended that you inspect contents of the file closely and make sure that they are alligned with your needs. | Rationale: | Auditing of successful attempts to modify a file helps in investigation of actions which happened on the system. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_audit_modify_success_aarch64 | Identifiers and References | Identifiers:
CCE-85909-0 References:
AU-2(a), FAU_GEN.1.1.c, SRG-OS-000458-GPOS-00203, SRG-OS-000474-GPOS-00219, SRG-OS-000475-GPOS-00220, SRG-OS-000463-GPOS-00207, SRG-OS-000465-GPOS-00209, SRG-OS-000461-GPOS-00205 | |
|
Rule
Configure auditing of successful file modifications (ppc64le)
[ref] | Ensure that successful attempts to modify a file are audited.
The following rules configure audit as described above:
## Successful file modifications (open for write or truncate)
-a always,exit -F arch=b64 -S openat,open_by_handle_at -F a2&01003 -F success=1 -F auid>=1000 -F auid!=unset -F key=successful-modification
-a always,exit -F arch=b64 -S open -F a1&01003 -F success=1 -F auid>=1000 -F auid!=unset -F key=successful-modification
-a always,exit -F arch=b64 -S truncate,ftruncate -F success=1 -F auid>=1000 -F auid!=unset -F key=successful-modification
Load new Audit rules into kernel by running:
augenrules --load
Note: This rule uses a special set of Audit rules to comply with OSPP 4.2.1. You may reuse this rule in different profiles. If you decide to do so, it is recommended that you inspect contents of the file closely and make sure that they are alligned with your needs. | Rationale: | Auditing of successful attempts to modify a file helps in investigation of actions which happened on the system. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_audit_modify_success_ppc64le | Identifiers and References | Identifiers:
CCE-90791-5 References:
AU-2(a), FAU_GEN.1.1.c, SRG-OS-000458-GPOS-00203, SRG-OS-000474-GPOS-00219, SRG-OS-000475-GPOS-00220, SRG-OS-000463-GPOS-00207, SRG-OS-000465-GPOS-00209, SRG-OS-000461-GPOS-00205 | |
|
Rule
Configure auditing of loading and unloading of kernel modules
[ref] | Ensure that loading and unloading of kernel modules is audited.
The following rules configure audit as described above:
## These rules watch for kernel module insertion. By monitoring
## the syscall, we do not need any watches on programs.
-a always,exit -F arch=b32 -S init_module,finit_module -F key=module-load
-a always,exit -F arch=b64 -S init_module,finit_module -F key=module-load
-a always,exit -F arch=b32 -S delete_module -F key=module-unload
-a always,exit -F arch=b64 -S delete_module -F key=module-unload
Load new Audit rules into kernel by running:
augenrules --load | Rationale: | Loading of a malicious kernel module introduces a risk to the system, as the module has access to sensitive data and perform actions at the operating system kernel level. Having such events audited helps in monitoring and investigating of malicious activities. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_audit_module_load | Identifiers and References | Identifiers:
CCE-90814-5 References:
AU-2(a), FAU_GEN.1.1.c, SRG-OS-000471-GPOS-00216, SRG-OS-000477-GPOS-00222, SRG-OS-000475-GPOS-00220 | |
|
Rule
Configure auditing of loading and unloading of kernel modules (ppc64le)
[ref] | Ensure that loading and unloading of kernel modules is audited.
The following rules configure audit as described above:
## These rules watch for kernel module insertion. By monitoring
## the syscall, we do not need any watches on programs.
-a always,exit -F arch=b64 -S init_module,finit_module -F key=module-load
-a always,exit -F arch=b64 -S delete_module -F key=module-unload
Load new Audit rules into kernel by running:
augenrules --load | Rationale: | Loading of a malicious kernel module introduces a risk to the system, as the module has access to sensitive data and perform actions at the operating system kernel level. Having such events audited helps in monitoring and investigating of malicious activities. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_audit_module_load_ppc64le | Identifiers and References | Identifiers:
CCE-90788-1 References:
AU-2(a), FAU_GEN.1.1.c, SRG-OS-000471-GPOS-00216, SRG-OS-000477-GPOS-00222, SRG-OS-000475-GPOS-00220 | |
|
Rule
Perform general configuration of Audit for OSPP
[ref] | Configure some basic Audit parameters specific for OSPP profile.
In particular, configure Audit to watch for direct modification of files storing system user and group information, and usage of applications with special rights which can change system configuration.
Further audited events include access to audit log it self, attempts to Alter Process and Session Initiation Information, and attempts to modify MAC controls.
The following rules configure audit as described above:
## The purpose of these rules is to meet the requirements for Operating
## System Protection Profile (OSPP)v4.2. These rules depends on having
## the following rule files copied to /etc/audit/rules.d:
##
## 10-base-config.rules, 11-loginuid.rules,
## 30-ospp-v42-1-create-failed.rules, 30-ospp-v42-1-create-success.rules,
## 30-ospp-v42-2-modify-failed.rules, 30-ospp-v42-2-modify-success.rules,
## 30-ospp-v42-3-access-failed.rules, 30-ospp-v42-3-access-success.rules,
## 30-ospp-v42-4-delete-failed.rules, 30-ospp-v42-4-delete-success.rules,
## 30-ospp-v42-5-perm-change-failed.rules,
## 30-ospp-v42-5-perm-change-success.rules,
## 30-ospp-v42-6-owner-change-failed.rules,
## 30-ospp-v42-6-owner-change-success.rules
##
## original copies may be found in /usr/share/audit/sample-rules/
## User add delete modify. This is covered by pam. However, someone could
## open a file and directly create or modify a user, so we'll watch passwd and
## shadow for writes
-a always,exit -F arch=b32 -S openat,open_by_handle_at -F a2&03 -F path=/etc/passwd -F auid>=1000 -F auid!=unset -F key=user-modify
-a always,exit -F arch=b64 -S openat,open_by_handle_at -F a2&03 -F path=/etc/passwd -F auid>=1000 -F auid!=unset -F key=user-modify
-a always,exit -F arch=b32 -S open -F a1&03 -F path=/etc/passwd -F auid>=1000 -F auid!=unset -F key=user-modify
-a always,exit -F arch=b64 -S open -F a1&03 -F path=/etc/passwd -F auid>=1000 -F auid!=unset -F key=user-modify
-a always,exit -F arch=b32 -S openat,open_by_handle_at -F a2&03 -F path=/etc/shadow -F auid>=1000 -F auid!=unset -F key=user-modify
-a always,exit -F arch=b64 -S openat,open_by_handle_at -F a2&03 -F path=/etc/shadow -F auid>=1000 -F auid!=unset -F key=user-modify
-a always,exit -F arch=b32 -S open -F a1&03 -F path=/etc/shadow -F auid>=1000 -F auid!=unset -F key=user-modify
-a always,exit -F arch=b64 -S open -F a1&03 -F path=/etc/shadow -F auid>=1000 -F auid!=unset -F key=user-modify
## User enable and disable. This is entirely handled by pam.
## Group add delete modify. This is covered by pam. However, someone could
## open a file and directly create or modify a user, so we'll watch group and
## gshadow for writes
-a always,exit -F path=/etc/passwd -F perm=wa -F auid>=1000 -F auid!=unset -F key=user-modify
-a always,exit -F path=/etc/shadow -F perm=wa -F auid>=1000 -F auid!=unset -F key=user-modify
-a always,exit -F path=/etc/group -F perm=wa -F auid>=1000 -F auid!=unset -F key=group-modify
-a always,exit -F path=/etc/gshadow -F perm=wa -F auid>=1000 -F auid!=unset -F key=group-modify
## Use of special rights for config changes. This would be use of setuid
## programs that relate to user accts. This is not all setuid apps because
## requirements are only for ones that affect system configuration.
-a always,exit -F path=/usr/sbin/unix_chkpwd -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/sbin/usernetctl -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/sbin/userhelper -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/sbin/seunshare -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/bin/mount -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/bin/newgrp -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/bin/newuidmap -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/bin/gpasswd -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/bin/newgidmap -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/bin/umount -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/bin/passwd -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/bin/crontab -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/bin/at -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
## Privilege escalation via su or sudo. This is entirely handled by pam.
## Watch for configuration changes to privilege escalation.
-a always,exit -F path=/etc/sudoers -F perm=wa -F key=special-config-changes
-a always,exit -F dir=/etc/sudoers.d/ -F perm=wa -F key=special-config-changes
## Audit log access
-a always,exit -F dir=/var/log/audit/ -F perm=r -F auid>=1000 -F auid!=unset -F key=access-audit-trail
## Attempts to Alter Process and Session Initiation Information
-a always,exit -F path=/var/run/utmp -F perm=wa -F auid>=1000 -F auid!=unset -F key=session
-a always,exit -F path=/var/log/btmp -F perm=wa -F auid>=1000 -F auid!=unset -F key=session
-a always,exit -F path=/var/log/wtmp -F perm=wa -F auid>=1000 -F auid!=unset -F key=session
## Attempts to modify MAC controls
-a always,exit -F dir=/etc/selinux/ -F perm=wa -F auid>=1000 -F auid!=unset -F key=MAC-policy
## Software updates. This is entirely handled by rpm.
## System start and shutdown. This is entirely handled by systemd
## Kernel Module loading. This is handled in 43-module-load.rules
## Application invocation. The requirements list an optional requirement
## FPT_SRP_EXT.1 Software Restriction Policies. This event is intended to
## state results from that policy. This would be handled entirely by
## that daemon.
Load new Audit rules into kernel by running:
augenrules --load
Note: This rule uses a special set of Audit rules to comply with OSPP 4.2.1. You may reuse this rule in different profiles. If you decide to do so, it is recommended that you inspect contents of the file closely and make sure that they are alligned with your needs. | Rationale: | Auditing of events listed in the description provides data for monitoring and investigation of potentially malicious events e.g. tampering with Audit logs, malicious access to files storing information about system users and groups etc. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_audit_ospp_general | Identifiers and References | Identifiers:
CCE-83655-1 References:
AU-2(a), FAU_GEN.1.1.c, SRG-OS-000004-GPOS-00004, SRG-OS-000241-GPOS-00091, SRG-OS-000476-GPOS-00221, SRG-OS-000327-GPOS-00127, SRG-OS-000475-GPOS-00220, SRG-OS-000239-GPOS-00089, SRG-OS-000274-GPOS-00104, SRG-OS-000275-GPOS-00105, SRG-OS-000303-GPOS-00120, SRG-OS-000304-GPOS-00121 | Remediation Kubernetes snippet ⇲---
apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
spec:
config:
ignition:
version: 3.1.0
storage:
files:
- contents:
source: data:,%23%23%20The%20purpose%20of%20these%20rules%20is%20to%20meet%20the%20requirements%20for%20Operating%0A%23%23%20System%20Protection%20Profile%20%28OSPP%29v4.2.%20These%20rules%20depends%20on%20having%0A%23%23%20the%20following%20rule%20files%20copied%20to%20/etc/audit/rules.d%3A%0A%23%23%0A%23%23%2010-base-config.rules%2C%2011-loginuid.rules%2C%0A%23%23%2030-ospp-v42-1-create-failed.rules%2C%2030-ospp-v42-1-create-success.rules%2C%0A%23%23%2030-ospp-v42-2-modify-failed.rules%2C%2030-ospp-v42-2-modify-success.rules%2C%0A%23%23%2030-ospp-v42-3-access-failed.rules%2C%2030-ospp-v42-3-access-success.rules%2C%0A%23%23%2030-ospp-v42-4-delete-failed.rules%2C%2030-ospp-v42-4-delete-success.rules%2C%0A%23%23%2030-ospp-v42-5-perm-change-failed.rules%2C%0A%23%23%2030-ospp-v42-5-perm-change-success.rules%2C%0A%23%23%2030-ospp-v42-6-owner-change-failed.rules%2C%0A%23%23%2030-ospp-v42-6-owner-change-success.rules%0A%23%23%0A%23%23%20original%20copies%20may%20be%20found%20in%20/usr/share/audit/sample-rules/%0A%0A%0A%23%23%20User%20add%20delete%20modify.%20This%20is%20covered%20by%20pam.%20However%2C%20someone%20could%0A%23%23%20open%20a%20file%20and%20directly%20create%20or%20modify%20a%20user%2C%20so%20we%27ll%20watch%20passwd%20and%0A%23%23%20shadow%20for%20writes%0A-a%20always%2Cexit%20-F%20arch%3Db32%20-S%20openat%2Copen_by_handle_at%20-F%20a2%2603%20-F%20path%3D/etc/passwd%20-F%20auid%3E%3D1000%20-F%20auid%21%3Dunset%20-F%20key%3Duser-modify%0A-a%20always%2Cexit%20-F%20arch%3Db64%20-S%20openat%2Copen_by_handle_at%20-F%20a2%2603%20-F%20path%3D/etc/passwd%20-F%20auid%3E%3D1000%20-F%20auid%21%3Dunset%20-F%20key%3Duser-modify%0A-a%20always%2Cexit%20-F%20arch%3Db32%20-S%20open%20-F%20a1%2603%20-F%20path%3D/etc/passwd%20-F%20auid%3E%3D1000%20-F%20auid%21%3Dunset%20-F%20key%3Duser-modify%0A-a%20always%2Cexit%20-F%20arch%3Db64%20-S%20open%20-F%20a1%2603%20-F%20path%3D/etc/passwd%20-F%20auid%3E%3D1000%20-F%20auid%21%3Dunset%20-F%20key%3Duser-modify%0A-a%20always%2Cexit%20-F%20arch%3Db32%20-S%20openat%2Copen_by_handle_at%20-F%20a2%2603%20-F%20path%3D/etc/shadow%20-F%20auid%3E%3D1000%20-F%20auid%21%3Dunset%20-F%20key%3Duser-modify%0A-a%20always%2Cexit%20-F%20arch%3Db64%20-S%20openat%2Copen_by_handle_at%20-F%20a2%2603%20-F%20path%3D/etc/shadow%20-F%20auid%3E%3D1000%20-F%20auid%21%3Dunset%20-F%20key%3Duser-modify%0A-a%20always%2Cexit%20-F%20arch%3Db32%20-S%20open%20-F%20a1%2603%20-F%20path%3D/etc/shadow%20-F%20auid%3E%3D1000%20-F%20auid%21%3Dunset%20-F%20key%3Duser-modify%0A-a%20always%2Cexit%20-F%20arch%3Db64%20-S%20open%20-F%20a1%2603%20-F%20path%3D/etc/shadow%20-F%20auid%3E%3D1000%20-F%20auid%21%3Dunset%20-F%20key%3Duser-modify%0A%0A%23%23%20User%20enable%20and%20disable.%20This%20is%20entirely%20handled%20by%20pam.%0A%0A%23%23%20Group%20add%20delete%20modify.%20This%20is%20covered%20by%20pam.%20However%2C%20someone%20could%0A%23%23%20open%20a%20file%20and%20directly%20create%20or%20modify%20a%20user%2C%20so%20we%27ll%20watch%20group%20and%0A%23%23%20gshadow%20for%20writes%0A-a%20always%2Cexit%20-F%20path%3D/etc/passwd%20-F%20perm%3Dwa%20-F%20auid%3E%3D1000%20-F%20auid%21%3Dunset%20-F%20key%3Duser-modify%0A-a%20always%2Cexit%20-F%20path%3D/etc/shadow%20-F%20perm%3Dwa%20-F%20auid%3E%3D1000%20-F%20auid%21%3Dunset%20-F%20key%3Duser-modify%0A-a%20always%2Cexit%20-F%20path%3D/etc/group%20-F%20perm%3Dwa%20-F%20auid%3E%3D1000%20-F%20auid%21%3Dunset%20-F%20key%3Dgroup-modify%0A-a%20always%2Cexit%20-F%20path%3D/etc/gshadow%20-F%20perm%3Dwa%20-F%20auid%3E%3D1000%20-F%20auid%21%3Dunset%20-F%20key%3Dgroup-modify%0A%0A%0A%23%23%20Use%20of%20special%20rights%20for%20config%20changes.%20This%20would%20be%20use%20of%20setuid%0A%23%23%20programs%20that%20relate%20to%20user%20accts.%20This%20is%20not%20all%20setuid%20apps%20because%0A%23%23%20requirements%20are%20only%20for%20ones%20that%20affect%20system%20configuration.%0A-a%20always%2Cexit%20-F%20path%3D/usr/sbin/unix_chkpwd%20-F%20perm%3Dx%20-F%20auid%3E%3D1000%20-F%20auid%21%3Dunset%20-F%20key%3Dspecial-config-changes%0A-a%20always%2Cexit%20-F%20path%3D/usr/sbin/usernetctl%20-F%20perm%3Dx%20-F%20auid%3E%3D1000%20-F%20auid%21%3Dunset%20-F%20key%3Dspecial-config-changes%0A-a%20always%2Cexit%20-F%20path%3D/usr/sbin/userhelper%20-F%20perm%3Dx%20-F%20auid%3E%3D1000%20-F%20auid%21%3Dunset%20-F%20key%3Dspecial-config-changes%0A-a%20always%2Cexit%20-F%20path%3D/usr/sbin/seunshare%20-F%20perm%3Dx%20-F%20auid%3E%3D1000%20-F%20auid%21%3Dunset%20-F%20key%3Dspecial-config-changes%0A-a%20always%2Cexit%20-F%20path%3D/usr/bin/mount%20-F%20perm%3Dx%20-F%20auid%3E%3D1000%20-F%20auid%21%3Dunset%20-F%20key%3Dspecial-config-changes%0A-a%20always%2Cexit%20-F%20path%3D/usr/bin/newgrp%20-F%20perm%3Dx%20-F%20auid%3E%3D1000%20-F%20auid%21%3Dunset%20-F%20key%3Dspecial-config-changes%0A-a%20always%2Cexit%20-F%20path%3D/usr/bin/newuidmap%20-F%20perm%3Dx%20-F%20auid%3E%3D1000%20-F%20auid%21%3Dunset%20-F%20key%3Dspecial-config-changes%0A-a%20always%2Cexit%20-F%20path%3D/usr/bin/gpasswd%20-F%20perm%3Dx%20-F%20auid%3E%3D1000%20-F%20auid%21%3Dunset%20-F%20key%3Dspecial-config-changes%0A-a%20always%2Cexit%20-F%20path%3D/usr/bin/newgidmap%20-F%20perm%3Dx%20-F%20auid%3E%3D1000%20-F%20auid%21%3Dunset%20-F%20key%3Dspecial-config-changes%0A-a%20always%2Cexit%20-F%20path%3D/usr/bin/umount%20-F%20perm%3Dx%20-F%20auid%3E%3D1000%20-F%20auid%21%3Dunset%20-F%20key%3Dspecial-config-changes%0A-a%20always%2Cexit%20-F%20path%3D/usr/bin/passwd%20-F%20perm%3Dx%20-F%20auid%3E%3D1000%20-F%20auid%21%3Dunset%20-F%20key%3Dspecial-config-changes%0A-a%20always%2Cexit%20-F%20path%3D/usr/bin/crontab%20-F%20perm%3Dx%20-F%20auid%3E%3D1000%20-F%20auid%21%3Dunset%20-F%20key%3Dspecial-config-changes%0A-a%20always%2Cexit%20-F%20path%3D/usr/bin/at%20-F%20perm%3Dx%20-F%20auid%3E%3D1000%20-F%20auid%21%3Dunset%20-F%20key%3Dspecial-config-changes%0A%0A%23%23%20Privilege%20escalation%20via%20su%20or%20sudo.%20This%20is%20entirely%20handled%20by%20pam.%0A%0A%23%23%20Audit%20log%20access%0A-a%20always%2Cexit%20-F%20dir%3D/var/log/audit/%20-F%20perm%3Dr%20-F%20auid%3E%3D1000%20-F%20auid%21%3Dunset%20-F%20key%3Daccess-audit-trail%0A%23%23%20Attempts%20to%20Alter%20Process%20and%20Session%20Initiation%20Information%0A-a%20always%2Cexit%20-F%20path%3D/var/run/utmp%20-F%20perm%3Dwa%20-F%20auid%3E%3D1000%20-F%20auid%21%3Dunset%20-F%20key%3Dsession%0A-a%20always%2Cexit%20-F%20path%3D/var/log/btmp%20-F%20perm%3Dwa%20-F%20auid%3E%3D1000%20-F%20auid%21%3Dunset%20-F%20key%3Dsession%0A-a%20always%2Cexit%20-F%20path%3D/var/log/wtmp%20-F%20perm%3Dwa%20-F%20auid%3E%3D1000%20-F%20auid%21%3Dunset%20-F%20key%3Dsession%0A%0A%23%23%20Attempts%20to%20modify%20MAC%20controls%0A-a%20always%2Cexit%20-F%20dir%3D/etc/selinux/%20-F%20perm%3Dwa%20-F%20auid%3E%3D1000%20-F%20auid%21%3Dunset%20-F%20key%3DMAC-policy%0A%0A%23%23%20Software%20updates.%20This%20is%20entirely%20handled%20by%20rpm.%0A%0A%23%23%20System%20start%20and%20shutdown.%20This%20is%20entirely%20handled%20by%20systemd%0A%0A%23%23%20Kernel%20Module%20loading.%20This%20is%20handled%20in%2043-module-load.rules%0A%0A%23%23%20Application%20invocation.%20The%20requirements%20list%20an%20optional%20requirement%0A%23%23%20FPT_SRP_EXT.1%20Software%20Restriction%20Policies.%20This%20event%20is%20intended%20to%0A%23%23%20state%20results%20from%20that%20policy.%20This%20would%20be%20handled%20entirely%20by%0A%23%23%20that%20daemon.%0A
mode: 0600
path: /etc/audit/rules.d/30-ospp-v42.rules
overwrite: true
Remediation Ansible snippet ⇲Complexity: | low |
---|
Disruption: | low |
---|
Strategy: | restrict |
---|
- name: Put contents into /etc/audit/rules.d/30-ospp-v42.rules according to policy
copy:
dest: /etc/audit/rules.d/30-ospp-v42.rules
content: |+
## The purpose of these rules is to meet the requirements for Operating
## System Protection Profile (OSPP)v4.2. These rules depends on having
## the following rule files copied to /etc/audit/rules.d:
##
## 10-base-config.rules, 11-loginuid.rules,
## 30-ospp-v42-1-create-failed.rules, 30-ospp-v42-1-create-success.rules,
## 30-ospp-v42-2-modify-failed.rules, 30-ospp-v42-2-modify-success.rules,
## 30-ospp-v42-3-access-failed.rules, 30-ospp-v42-3-access-success.rules,
## 30-ospp-v42-4-delete-failed.rules, 30-ospp-v42-4-delete-success.rules,
## 30-ospp-v42-5-perm-change-failed.rules,
## 30-ospp-v42-5-perm-change-success.rules,
## 30-ospp-v42-6-owner-change-failed.rules,
## 30-ospp-v42-6-owner-change-success.rules
##
## original copies may be found in /usr/share/audit/sample-rules/
## User add delete modify. This is covered by pam. However, someone could
## open a file and directly create or modify a user, so we'll watch passwd and
## shadow for writes
-a always,exit -F arch=b32 -S openat,open_by_handle_at -F a2&03 -F path=/etc/passwd -F auid>=1000 -F auid!=unset -F key=user-modify
-a always,exit -F arch=b64 -S openat,open_by_handle_at -F a2&03 -F path=/etc/passwd -F auid>=1000 -F auid!=unset -F key=user-modify
-a always,exit -F arch=b32 -S open -F a1&03 -F path=/etc/passwd -F auid>=1000 -F auid!=unset -F key=user-modify
-a always,exit -F arch=b64 -S open -F a1&03 -F path=/etc/passwd -F auid>=1000 -F auid!=unset -F key=user-modify
-a always,exit -F arch=b32 -S openat,open_by_handle_at -F a2&03 -F path=/etc/shadow -F auid>=1000 -F auid!=unset -F key=user-modify
-a always,exit -F arch=b64 -S openat,open_by_handle_at -F a2&03 -F path=/etc/shadow -F auid>=1000 -F auid!=unset -F key=user-modify
-a always,exit -F arch=b32 -S open -F a1&03 -F path=/etc/shadow -F auid>=1000 -F auid!=unset -F key=user-modify
-a always,exit -F arch=b64 -S open -F a1&03 -F path=/etc/shadow -F auid>=1000 -F auid!=unset -F key=user-modify
## User enable and disable. This is entirely handled by pam.
## Group add delete modify. This is covered by pam. However, someone could
## open a file and directly create or modify a user, so we'll watch group and
## gshadow for writes
-a always,exit -F path=/etc/passwd -F perm=wa -F auid>=1000 -F auid!=unset -F key=user-modify
-a always,exit -F path=/etc/shadow -F perm=wa -F auid>=1000 -F auid!=unset -F key=user-modify
-a always,exit -F path=/etc/group -F perm=wa -F auid>=1000 -F auid!=unset -F key=group-modify
-a always,exit -F path=/etc/gshadow -F perm=wa -F auid>=1000 -F auid!=unset -F key=group-modify
## Use of special rights for config changes. This would be use of setuid
## programs that relate to user accts. This is not all setuid apps because
## requirements are only for ones that affect system configuration.
-a always,exit -F path=/usr/sbin/unix_chkpwd -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/sbin/usernetctl -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/sbin/userhelper -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/sbin/seunshare -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/bin/mount -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/bin/newgrp -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/bin/newuidmap -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/bin/gpasswd -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/bin/newgidmap -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/bin/umount -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/bin/passwd -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/bin/crontab -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/bin/at -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
## Privilege escalation via su or sudo. This is entirely handled by pam.
## Watch for configuration changes to privilege escalation.
-a always,exit -F path=/etc/sudoers -F perm=wa -F key=special-config-changes
-a always,exit -F dir=/etc/sudoers.d/ -F perm=wa -F key=special-config-changes
## Audit log access
-a always,exit -F dir=/var/log/audit/ -F perm=r -F auid>=1000 -F auid!=unset -F key=access-audit-trail
## Attempts to Alter Process and Session Initiation Information
-a always,exit -F path=/var/run/utmp -F perm=wa -F auid>=1000 -F auid!=unset -F key=session
-a always,exit -F path=/var/log/btmp -F perm=wa -F auid>=1000 -F auid!=unset -F key=session
-a always,exit -F path=/var/log/wtmp -F perm=wa -F auid>=1000 -F auid!=unset -F key=session
## Attempts to modify MAC controls
-a always,exit -F dir=/etc/selinux/ -F perm=wa -F auid>=1000 -F auid!=unset -F key=MAC-policy
## Software updates. This is entirely handled by rpm.
## System start and shutdown. This is entirely handled by systemd
## Kernel Module loading. This is handled in 43-module-load.rules
## Application invocation. The requirements list an optional requirement
## FPT_SRP_EXT.1 Software Restriction Policies. This event is intended to
## state results from that policy. This would be handled entirely by
## that daemon.
force: true
when:
- ansible_virtualization_type not in ["docker", "lxc", "openvz", "podman", "container"]
- ( not ( ansible_architecture == "aarch64" ) and not ( ansible_architecture ==
"ppc64le" ) )
tags:
- CCE-83655-1
- NIST-800-53-AU-2(a)
- audit_ospp_general
- low_complexity
- low_disruption
- medium_severity
- no_reboot_needed
- restrict_strategy
- name: Remove any permissions from other group
file:
path: /etc/audit/rules.d/30-ospp-v42.rules
mode: o-rwx
when:
- ansible_virtualization_type not in ["docker", "lxc", "openvz", "podman", "container"]
- ( not ( ansible_architecture == "aarch64" ) and not ( ansible_architecture ==
"ppc64le" ) )
tags:
- CCE-83655-1
- NIST-800-53-AU-2(a)
- audit_ospp_general
- low_complexity
- low_disruption
- medium_severity
- no_reboot_needed
- restrict_strategy
Remediation Shell script ⇲Complexity: | low |
---|
Disruption: | low |
---|
Strategy: | restrict |
---|
# Remediation is applicable only in certain platforms
if [ ! -f /.dockerenv ] && [ ! -f /run/.containerenv ] && { ( ! ( grep -q aarch64 /proc/sys/kernel/osrelease ) && ! ( grep -q ppc64le /proc/sys/kernel/osrelease ) ); }; then
cat << 'EOF' > /etc/audit/rules.d/30-ospp-v42.rules
## The purpose of these rules is to meet the requirements for Operating
## System Protection Profile (OSPP)v4.2. These rules depends on having
## the following rule files copied to /etc/audit/rules.d:
##
## 10-base-config.rules, 11-loginuid.rules,
## 30-ospp-v42-1-create-failed.rules, 30-ospp-v42-1-create-success.rules,
## 30-ospp-v42-2-modify-failed.rules, 30-ospp-v42-2-modify-success.rules,
## 30-ospp-v42-3-access-failed.rules, 30-ospp-v42-3-access-success.rules,
## 30-ospp-v42-4-delete-failed.rules, 30-ospp-v42-4-delete-success.rules,
## 30-ospp-v42-5-perm-change-failed.rules,
## 30-ospp-v42-5-perm-change-success.rules,
## 30-ospp-v42-6-owner-change-failed.rules,
## 30-ospp-v42-6-owner-change-success.rules
##
## original copies may be found in /usr/share/audit/sample-rules/
## User add delete modify. This is covered by pam. However, someone could
## open a file and directly create or modify a user, so we'll watch passwd and
## shadow for writes
-a always,exit -F arch=b32 -S openat,open_by_handle_at -F a2&03 -F path=/etc/passwd -F auid>=1000 -F auid!=unset -F key=user-modify
-a always,exit -F arch=b64 -S openat,open_by_handle_at -F a2&03 -F path=/etc/passwd -F auid>=1000 -F auid!=unset -F key=user-modify
-a always,exit -F arch=b32 -S open -F a1&03 -F path=/etc/passwd -F auid>=1000 -F auid!=unset -F key=user-modify
-a always,exit -F arch=b64 -S open -F a1&03 -F path=/etc/passwd -F auid>=1000 -F auid!=unset -F key=user-modify
-a always,exit -F arch=b32 -S openat,open_by_handle_at -F a2&03 -F path=/etc/shadow -F auid>=1000 -F auid!=unset -F key=user-modify
-a always,exit -F arch=b64 -S openat,open_by_handle_at -F a2&03 -F path=/etc/shadow -F auid>=1000 -F auid!=unset -F key=user-modify
-a always,exit -F arch=b32 -S open -F a1&03 -F path=/etc/shadow -F auid>=1000 -F auid!=unset -F key=user-modify
-a always,exit -F arch=b64 -S open -F a1&03 -F path=/etc/shadow -F auid>=1000 -F auid!=unset -F key=user-modify
## User enable and disable. This is entirely handled by pam.
## Group add delete modify. This is covered by pam. However, someone could
## open a file and directly create or modify a user, so we'll watch group and
## gshadow for writes
-a always,exit -F path=/etc/passwd -F perm=wa -F auid>=1000 -F auid!=unset -F key=user-modify
-a always,exit -F path=/etc/shadow -F perm=wa -F auid>=1000 -F auid!=unset -F key=user-modify
-a always,exit -F path=/etc/group -F perm=wa -F auid>=1000 -F auid!=unset -F key=group-modify
-a always,exit -F path=/etc/gshadow -F perm=wa -F auid>=1000 -F auid!=unset -F key=group-modify
## Use of special rights for config changes. This would be use of setuid
## programs that relate to user accts. This is not all setuid apps because
## requirements are only for ones that affect system configuration.
-a always,exit -F path=/usr/sbin/unix_chkpwd -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/sbin/usernetctl -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/sbin/userhelper -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/sbin/seunshare -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/bin/mount -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/bin/newgrp -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/bin/newuidmap -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/bin/gpasswd -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/bin/newgidmap -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/bin/umount -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/bin/passwd -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/bin/crontab -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/bin/at -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
## Privilege escalation via su or sudo. This is entirely handled by pam.
## Watch for configuration changes to privilege escalation.
-a always,exit -F path=/etc/sudoers -F perm=wa -F key=special-config-changes
-a always,exit -F dir=/etc/sudoers.d/ -F perm=wa -F key=special-config-changes
## Audit log access
-a always,exit -F dir=/var/log/audit/ -F perm=r -F auid>=1000 -F auid!=unset -F key=access-audit-trail
## Attempts to Alter Process and Session Initiation Information
-a always,exit -F path=/var/run/utmp -F perm=wa -F auid>=1000 -F auid!=unset -F key=session
-a always,exit -F path=/var/log/btmp -F perm=wa -F auid>=1000 -F auid!=unset -F key=session
-a always,exit -F path=/var/log/wtmp -F perm=wa -F auid>=1000 -F auid!=unset -F key=session
## Attempts to modify MAC controls
-a always,exit -F dir=/etc/selinux/ -F perm=wa -F auid>=1000 -F auid!=unset -F key=MAC-policy
## Software updates. This is entirely handled by rpm.
## System start and shutdown. This is entirely handled by systemd
## Kernel Module loading. This is handled in 43-module-load.rules
## Application invocation. The requirements list an optional requirement
## FPT_SRP_EXT.1 Software Restriction Policies. This event is intended to
## state results from that policy. This would be handled entirely by
## that daemon.
EOF
chmod o-rwx /etc/audit/rules.d/30-ospp-v42.rules
augenrules --load
else
>&2 echo 'Remediation is not applicable, nothing was done'
fi
|
|
Rule
Perform general configuration of Audit for OSPP (AArch64)
[ref] | Configure some basic Audit parameters specific for OSPP profile.
In particular, configure Audit to watch for direct modification of files storing system user and group information, and usage of applications with special rights which can change system configuration.
Further audited events include access to audit log it self, attempts to Alter Process and Session Initiation Information, and attempts to modify MAC controls.
The following rules configure audit as described above:
## The purpose of these rules is to meet the requirements for Operating
## System Protection Profile (OSPP)v4.2. These rules depends on having
## the following rule files copied to /etc/audit/rules.d:
##
## 10-base-config.rules, 11-loginuid.rules,
## 30-ospp-v42-1-create-failed.rules, 30-ospp-v42-1-create-success.rules,
## 30-ospp-v42-2-modify-failed.rules, 30-ospp-v42-2-modify-success.rules,
## 30-ospp-v42-3-access-failed.rules, 30-ospp-v42-3-access-success.rules,
## 30-ospp-v42-4-delete-failed.rules, 30-ospp-v42-4-delete-success.rules,
## 30-ospp-v42-5-perm-change-failed.rules,
## 30-ospp-v42-5-perm-change-success.rules,
## 30-ospp-v42-6-owner-change-failed.rules,
## 30-ospp-v42-6-owner-change-success.rules
##
## original copies may be found in /usr/share/audit/sample-rules/
## User add delete modify. This is covered by pam. However, someone could
## open a file and directly create or modify a user, so we'll watch passwd and
## shadow for writes
-a always,exit -F arch=b32 -S openat,open_by_handle_at -F a2&03 -F path=/etc/passwd -F auid>=1000 -F auid!=unset -F key=user-modify
-a always,exit -F arch=b64 -S openat,open_by_handle_at -F a2&03 -F path=/etc/passwd -F auid>=1000 -F auid!=unset -F key=user-modify
-a always,exit -F arch=b32 -S open -F a1&03 -F path=/etc/passwd -F auid>=1000 -F auid!=unset -F key=user-modify
-a always,exit -F arch=b32 -S openat,open_by_handle_at -F a2&03 -F path=/etc/shadow -F auid>=1000 -F auid!=unset -F key=user-modify
-a always,exit -F arch=b64 -S openat,open_by_handle_at -F a2&03 -F path=/etc/shadow -F auid>=1000 -F auid!=unset -F key=user-modify
-a always,exit -F arch=b32 -S open -F a1&03 -F path=/etc/shadow -F auid>=1000 -F auid!=unset -F key=user-modify
## User enable and disable. This is entirely handled by pam.
## Group add delete modify. This is covered by pam. However, someone could
## open a file and directly create or modify a user, so we'll watch group and
## gshadow for writes
-a always,exit -F path=/etc/passwd -F perm=wa -F auid>=1000 -F auid!=unset -F key=user-modify
-a always,exit -F path=/etc/shadow -F perm=wa -F auid>=1000 -F auid!=unset -F key=user-modify
-a always,exit -F path=/etc/group -F perm=wa -F auid>=1000 -F auid!=unset -F key=group-modify
-a always,exit -F path=/etc/gshadow -F perm=wa -F auid>=1000 -F auid!=unset -F key=group-modify
## Use of special rights for config changes. This would be use of setuid
## programs that relate to user accts. This is not all setuid apps because
## requirements are only for ones that affect system configuration.
-a always,exit -F path=/usr/sbin/unix_chkpwd -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/sbin/usernetctl -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/sbin/userhelper -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/sbin/seunshare -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/bin/mount -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/bin/newgrp -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/bin/newuidmap -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/bin/gpasswd -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/bin/newgidmap -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/bin/umount -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/bin/passwd -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/bin/crontab -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/bin/at -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
## Privilege escalation via su or sudo. This is entirely handled by pam.
## Watch for configuration changes to privilege escalation.
-a always,exit -F path=/etc/sudoers -F perm=wa -F key=special-config-changes
-a always,exit -F dir=/etc/sudoers.d/ -F perm=wa -F key=special-config-changes
## Audit log access
-a always,exit -F dir=/var/log/audit/ -F perm=r -F auid>=1000 -F auid!=unset -F key=access-audit-trail
## Attempts to Alter Process and Session Initiation Information
-a always,exit -F path=/var/run/utmp -F perm=wa -F auid>=1000 -F auid!=unset -F key=session
-a always,exit -F path=/var/log/btmp -F perm=wa -F auid>=1000 -F auid!=unset -F key=session
-a always,exit -F path=/var/log/wtmp -F perm=wa -F auid>=1000 -F auid!=unset -F key=session
## Attempts to modify MAC controls
-a always,exit -F dir=/etc/selinux/ -F perm=wa -F auid>=1000 -F auid!=unset -F key=MAC-policy
## Software updates. This is entirely handled by rpm.
## System start and shutdown. This is entirely handled by systemd
## Kernel Module loading. This is handled in 43-module-load.rules
## Application invocation. The requirements list an optional requirement
## FPT_SRP_EXT.1 Software Restriction Policies. This event is intended to
## state results from that policy. This would be handled entirely by
## that daemon.
Load new Audit rules into kernel by running:
augenrules --load
Note: This rule uses a special set of Audit rules to comply with OSPP 4.2.1. You may reuse this rule in different profiles. If you decide to do so, it is recommended that you inspect contents of the file closely and make sure that they are alligned with your needs. | Rationale: | Auditing of events listed in the description provides data for monitoring and investigation of potentially malicious events e.g. tampering with Audit logs, malicious access to files storing information about system users and groups etc. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_audit_ospp_general_aarch64 | Identifiers and References | Identifiers:
CCE-85893-6 References:
AU-2(a), FAU_GEN.1.1.c, SRG-OS-000004-GPOS-00004, SRG-OS-000241-GPOS-00091, SRG-OS-000476-GPOS-00221, SRG-OS-000327-GPOS-00127, SRG-OS-000475-GPOS-00220, SRG-OS-000239-GPOS-00089, SRG-OS-000274-GPOS-00104, SRG-OS-000275-GPOS-00105, SRG-OS-000303-GPOS-00120, SRG-OS-000304-GPOS-00121 | Remediation Kubernetes snippet ⇲---
apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
spec:
config:
ignition:
version: 3.1.0
storage:
files:
- contents:
source: data:,## The purpose of these rules is to meet the requirements for Operating
## System Protection Profile (OSPP)v4.2. These rules depends on having
## the following rule files copied to /etc/audit/rules.d:
##
## 10-base-config.rules, 11-loginuid.rules,
## 30-ospp-v42-1-create-failed.rules, 30-ospp-v42-1-create-success.rules,
## 30-ospp-v42-2-modify-failed.rules, 30-ospp-v42-2-modify-success.rules,
## 30-ospp-v42-3-access-failed.rules, 30-ospp-v42-3-access-success.rules,
## 30-ospp-v42-4-delete-failed.rules, 30-ospp-v42-4-delete-success.rules,
## 30-ospp-v42-5-perm-change-failed.rules,
## 30-ospp-v42-5-perm-change-success.rules,
## 30-ospp-v42-6-owner-change-failed.rules,
## 30-ospp-v42-6-owner-change-success.rules
##
## original copies may be found in /usr/share/audit/sample-rules/
## User add delete modify. This is covered by pam. However, someone could
## open a file and directly create or modify a user, so we'll watch passwd and
## shadow for writes
-a always,exit -F arch=b32 -S openat,open_by_handle_at -F a2&03 -F path=/etc/passwd -F auid>=1000 -F auid!=unset -F key=user-modify
-a always,exit -F arch=b64 -S openat,open_by_handle_at -F a2&03 -F path=/etc/passwd -F auid>=1000 -F auid!=unset -F key=user-modify
-a always,exit -F arch=b32 -S open -F a1&03 -F path=/etc/passwd -F auid>=1000 -F auid!=unset -F key=user-modify
-a always,exit -F arch=b32 -S openat,open_by_handle_at -F a2&03 -F path=/etc/shadow -F auid>=1000 -F auid!=unset -F key=user-modify
-a always,exit -F arch=b64 -S openat,open_by_handle_at -F a2&03 -F path=/etc/shadow -F auid>=1000 -F auid!=unset -F key=user-modify
-a always,exit -F arch=b32 -S open -F a1&03 -F path=/etc/shadow -F auid>=1000 -F auid!=unset -F key=user-modify
## User enable and disable. This is entirely handled by pam.
## Group add delete modify. This is covered by pam. However, someone could
## open a file and directly create or modify a user, so we'll watch group and
## gshadow for writes
-a always,exit -F path=/etc/passwd -F perm=wa -F auid>=1000 -F auid!=unset -F key=user-modify
-a always,exit -F path=/etc/shadow -F perm=wa -F auid>=1000 -F auid!=unset -F key=user-modify
-a always,exit -F path=/etc/group -F perm=wa -F auid>=1000 -F auid!=unset -F key=group-modify
-a always,exit -F path=/etc/gshadow -F perm=wa -F auid>=1000 -F auid!=unset -F key=group-modify
## Use of special rights for config changes. This would be use of setuid
## programs that relate to user accts. This is not all setuid apps because
## requirements are only for ones that affect system configuration.
-a always,exit -F path=/usr/sbin/unix_chkpwd -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/sbin/usernetctl -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/sbin/userhelper -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/sbin/seunshare -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/bin/mount -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/bin/newgrp -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/bin/newuidmap -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/bin/gpasswd -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/bin/newgidmap -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/bin/umount -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/bin/passwd -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/bin/crontab -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/bin/at -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
## Privilege escalation via su or sudo. This is entirely handled by pam.
## Watch for configuration changes to privilege escalation.
-a always,exit -F path=/etc/sudoers -F perm=wa -F key=special-config-changes
-a always,exit -F dir=/etc/sudoers.d/ -F perm=wa -F key=special-config-changes
## Audit log access
-a always,exit -F dir=/var/log/audit/ -F perm=r -F auid>=1000 -F auid!=unset -F key=access-audit-trail
## Attempts to Alter Process and Session Initiation Information
-a always,exit -F path=/var/run/utmp -F perm=wa -F auid>=1000 -F auid!=unset -F key=session
-a always,exit -F path=/var/log/btmp -F perm=wa -F auid>=1000 -F auid!=unset -F key=session
-a always,exit -F path=/var/log/wtmp -F perm=wa -F auid>=1000 -F auid!=unset -F key=session
## Attempts to modify MAC controls
-a always,exit -F dir=/etc/selinux/ -F perm=wa -F auid>=1000 -F auid!=unset -F key=MAC-policy
## Software updates. This is entirely handled by rpm.
## System start and shutdown. This is entirely handled by systemd
## Kernel Module loading. This is handled in 43-module-load.rules
## Application invocation. The requirements list an optional requirement
## FPT_SRP_EXT.1 Software Restriction Policies. This event is intended to
## state results from that policy. This would be handled entirely by
## that daemon.%0A
mode: 0600
path: /etc/audit/rules.d/30-ospp-v42.rules
overwrite: true
Remediation Ansible snippet ⇲Complexity: | low |
---|
Disruption: | low |
---|
Strategy: | restrict |
---|
- name: Put contents into /etc/audit/rules.d/30-ospp-v42.rules according to policy
copy:
dest: /etc/audit/rules.d/30-ospp-v42.rules
content: |+
## The purpose of these rules is to meet the requirements for Operating
## System Protection Profile (OSPP)v4.2. These rules depends on having
## the following rule files copied to /etc/audit/rules.d:
##
## 10-base-config.rules, 11-loginuid.rules,
## 30-ospp-v42-1-create-failed.rules, 30-ospp-v42-1-create-success.rules,
## 30-ospp-v42-2-modify-failed.rules, 30-ospp-v42-2-modify-success.rules,
## 30-ospp-v42-3-access-failed.rules, 30-ospp-v42-3-access-success.rules,
## 30-ospp-v42-4-delete-failed.rules, 30-ospp-v42-4-delete-success.rules,
## 30-ospp-v42-5-perm-change-failed.rules,
## 30-ospp-v42-5-perm-change-success.rules,
## 30-ospp-v42-6-owner-change-failed.rules,
## 30-ospp-v42-6-owner-change-success.rules
##
## original copies may be found in /usr/share/audit/sample-rules/
## User add delete modify. This is covered by pam. However, someone could
## open a file and directly create or modify a user, so we'll watch passwd and
## shadow for writes
-a always,exit -F arch=b32 -S openat,open_by_handle_at -F a2&03 -F path=/etc/passwd -F auid>=1000 -F auid!=unset -F key=user-modify
-a always,exit -F arch=b64 -S openat,open_by_handle_at -F a2&03 -F path=/etc/passwd -F auid>=1000 -F auid!=unset -F key=user-modify
-a always,exit -F arch=b32 -S open -F a1&03 -F path=/etc/passwd -F auid>=1000 -F auid!=unset -F key=user-modify
-a always,exit -F arch=b32 -S openat,open_by_handle_at -F a2&03 -F path=/etc/shadow -F auid>=1000 -F auid!=unset -F key=user-modify
-a always,exit -F arch=b64 -S openat,open_by_handle_at -F a2&03 -F path=/etc/shadow -F auid>=1000 -F auid!=unset -F key=user-modify
-a always,exit -F arch=b32 -S open -F a1&03 -F path=/etc/shadow -F auid>=1000 -F auid!=unset -F key=user-modify
## User enable and disable. This is entirely handled by pam.
## Group add delete modify. This is covered by pam. However, someone could
## open a file and directly create or modify a user, so we'll watch group and
## gshadow for writes
-a always,exit -F path=/etc/passwd -F perm=wa -F auid>=1000 -F auid!=unset -F key=user-modify
-a always,exit -F path=/etc/shadow -F perm=wa -F auid>=1000 -F auid!=unset -F key=user-modify
-a always,exit -F path=/etc/group -F perm=wa -F auid>=1000 -F auid!=unset -F key=group-modify
-a always,exit -F path=/etc/gshadow -F perm=wa -F auid>=1000 -F auid!=unset -F key=group-modify
## Use of special rights for config changes. This would be use of setuid
## programs that relate to user accts. This is not all setuid apps because
## requirements are only for ones that affect system configuration.
-a always,exit -F path=/usr/sbin/unix_chkpwd -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/sbin/usernetctl -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/sbin/userhelper -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/sbin/seunshare -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/bin/mount -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/bin/newgrp -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/bin/newuidmap -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/bin/gpasswd -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/bin/newgidmap -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/bin/umount -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/bin/passwd -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/bin/crontab -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/bin/at -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
## Privilege escalation via su or sudo. This is entirely handled by pam.
## Watch for configuration changes to privilege escalation.
-a always,exit -F path=/etc/sudoers -F perm=wa -F key=special-config-changes
-a always,exit -F dir=/etc/sudoers.d/ -F perm=wa -F key=special-config-changes
## Audit log access
-a always,exit -F dir=/var/log/audit/ -F perm=r -F auid>=1000 -F auid!=unset -F key=access-audit-trail
## Attempts to Alter Process and Session Initiation Information
-a always,exit -F path=/var/run/utmp -F perm=wa -F auid>=1000 -F auid!=unset -F key=session
-a always,exit -F path=/var/log/btmp -F perm=wa -F auid>=1000 -F auid!=unset -F key=session
-a always,exit -F path=/var/log/wtmp -F perm=wa -F auid>=1000 -F auid!=unset -F key=session
## Attempts to modify MAC controls
-a always,exit -F dir=/etc/selinux/ -F perm=wa -F auid>=1000 -F auid!=unset -F key=MAC-policy
## Software updates. This is entirely handled by rpm.
## System start and shutdown. This is entirely handled by systemd
## Kernel Module loading. This is handled in 43-module-load.rules
## Application invocation. The requirements list an optional requirement
## FPT_SRP_EXT.1 Software Restriction Policies. This event is intended to
## state results from that policy. This would be handled entirely by
## that daemon.
force: true
when:
- ansible_virtualization_type not in ["docker", "lxc", "openvz", "podman", "container"]
- ansible_architecture == "aarch64"
tags:
- CCE-85893-6
- NIST-800-53-AU-2(a)
- audit_ospp_general_aarch64
- low_complexity
- low_disruption
- medium_severity
- no_reboot_needed
- restrict_strategy
- name: Remove any permissions from other group
file:
path: /etc/audit/rules.d/30-ospp-v42.rules
mode: o-rwx
when:
- ansible_virtualization_type not in ["docker", "lxc", "openvz", "podman", "container"]
- ansible_architecture == "aarch64"
tags:
- CCE-85893-6
- NIST-800-53-AU-2(a)
- audit_ospp_general_aarch64
- low_complexity
- low_disruption
- medium_severity
- no_reboot_needed
- restrict_strategy
Remediation Shell script ⇲Complexity: | low |
---|
Disruption: | low |
---|
Strategy: | restrict |
---|
# Remediation is applicable only in certain platforms
if [ ! -f /.dockerenv ] && [ ! -f /run/.containerenv ] && { grep -q aarch64 /proc/sys/kernel/osrelease; }; then
cat << 'EOF' > /etc/audit/rules.d/30-ospp-v42.rules
## The purpose of these rules is to meet the requirements for Operating
## System Protection Profile (OSPP)v4.2. These rules depends on having
## the following rule files copied to /etc/audit/rules.d:
##
## 10-base-config.rules, 11-loginuid.rules,
## 30-ospp-v42-1-create-failed.rules, 30-ospp-v42-1-create-success.rules,
## 30-ospp-v42-2-modify-failed.rules, 30-ospp-v42-2-modify-success.rules,
## 30-ospp-v42-3-access-failed.rules, 30-ospp-v42-3-access-success.rules,
## 30-ospp-v42-4-delete-failed.rules, 30-ospp-v42-4-delete-success.rules,
## 30-ospp-v42-5-perm-change-failed.rules,
## 30-ospp-v42-5-perm-change-success.rules,
## 30-ospp-v42-6-owner-change-failed.rules,
## 30-ospp-v42-6-owner-change-success.rules
##
## original copies may be found in /usr/share/audit/sample-rules/
## User add delete modify. This is covered by pam. However, someone could
## open a file and directly create or modify a user, so we'll watch passwd and
## shadow for writes
-a always,exit -F arch=b32 -S openat,open_by_handle_at -F a2&03 -F path=/etc/passwd -F auid>=1000 -F auid!=unset -F key=user-modify
-a always,exit -F arch=b64 -S openat,open_by_handle_at -F a2&03 -F path=/etc/passwd -F auid>=1000 -F auid!=unset -F key=user-modify
-a always,exit -F arch=b32 -S open -F a1&03 -F path=/etc/passwd -F auid>=1000 -F auid!=unset -F key=user-modify
-a always,exit -F arch=b32 -S openat,open_by_handle_at -F a2&03 -F path=/etc/shadow -F auid>=1000 -F auid!=unset -F key=user-modify
-a always,exit -F arch=b64 -S openat,open_by_handle_at -F a2&03 -F path=/etc/shadow -F auid>=1000 -F auid!=unset -F key=user-modify
-a always,exit -F arch=b32 -S open -F a1&03 -F path=/etc/shadow -F auid>=1000 -F auid!=unset -F key=user-modify
## User enable and disable. This is entirely handled by pam.
## Group add delete modify. This is covered by pam. However, someone could
## open a file and directly create or modify a user, so we'll watch group and
## gshadow for writes
-a always,exit -F path=/etc/passwd -F perm=wa -F auid>=1000 -F auid!=unset -F key=user-modify
-a always,exit -F path=/etc/shadow -F perm=wa -F auid>=1000 -F auid!=unset -F key=user-modify
-a always,exit -F path=/etc/group -F perm=wa -F auid>=1000 -F auid!=unset -F key=group-modify
-a always,exit -F path=/etc/gshadow -F perm=wa -F auid>=1000 -F auid!=unset -F key=group-modify
## Use of special rights for config changes. This would be use of setuid
## programs that relate to user accts. This is not all setuid apps because
## requirements are only for ones that affect system configuration.
-a always,exit -F path=/usr/sbin/unix_chkpwd -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/sbin/usernetctl -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/sbin/userhelper -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/sbin/seunshare -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/bin/mount -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/bin/newgrp -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/bin/newuidmap -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/bin/gpasswd -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/bin/newgidmap -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/bin/umount -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/bin/passwd -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/bin/crontab -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/bin/at -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
## Privilege escalation via su or sudo. This is entirely handled by pam.
## Watch for configuration changes to privilege escalation.
-a always,exit -F path=/etc/sudoers -F perm=wa -F key=special-config-changes
-a always,exit -F dir=/etc/sudoers.d/ -F perm=wa -F key=special-config-changes
## Audit log access
-a always,exit -F dir=/var/log/audit/ -F perm=r -F auid>=1000 -F auid!=unset -F key=access-audit-trail
## Attempts to Alter Process and Session Initiation Information
-a always,exit -F path=/var/run/utmp -F perm=wa -F auid>=1000 -F auid!=unset -F key=session
-a always,exit -F path=/var/log/btmp -F perm=wa -F auid>=1000 -F auid!=unset -F key=session
-a always,exit -F path=/var/log/wtmp -F perm=wa -F auid>=1000 -F auid!=unset -F key=session
## Attempts to modify MAC controls
-a always,exit -F dir=/etc/selinux/ -F perm=wa -F auid>=1000 -F auid!=unset -F key=MAC-policy
## Software updates. This is entirely handled by rpm.
## System start and shutdown. This is entirely handled by systemd
## Kernel Module loading. This is handled in 43-module-load.rules
## Application invocation. The requirements list an optional requirement
## FPT_SRP_EXT.1 Software Restriction Policies. This event is intended to
## state results from that policy. This would be handled entirely by
## that daemon.
EOF
chmod o-rwx /etc/audit/rules.d/30-ospp-v42.rules
augenrules --load
else
>&2 echo 'Remediation is not applicable, nothing was done'
fi
|
|
Rule
Perform general configuration of Audit for OSPP (ppc64le)
[ref] | Configure some basic Audit parameters specific for OSPP profile.
In particular, configure Audit to watch for direct modification of files storing system user and group information, and usage of applications with special rights which can change system configuration.
Further audited events include access to audit log it self, attempts to Alter Process and Session Initiation Information, and attempts to modify MAC controls.
The following rules configure audit as described above:
## The purpose of these rules is to meet the requirements for Operating
## System Protection Profile (OSPP)v4.2. These rules depends on having
## the following rule files copied to /etc/audit/rules.d:
##
## 10-base-config.rules, 11-loginuid.rules,
## 30-ospp-v42-1-create-failed.rules, 30-ospp-v42-1-create-success.rules,
## 30-ospp-v42-2-modify-failed.rules, 30-ospp-v42-2-modify-success.rules,
## 30-ospp-v42-3-access-failed.rules, 30-ospp-v42-3-access-success.rules,
## 30-ospp-v42-4-delete-failed.rules, 30-ospp-v42-4-delete-success.rules,
## 30-ospp-v42-5-perm-change-failed.rules,
## 30-ospp-v42-5-perm-change-success.rules,
## 30-ospp-v42-6-owner-change-failed.rules,
## 30-ospp-v42-6-owner-change-success.rules
##
## original copies may be found in /usr/share/audit/sample-rules/
## User add delete modify. This is covered by pam. However, someone could
## open a file and directly create or modify a user, so we'll watch passwd and
## shadow for writes
-a always,exit -F arch=b64 -S openat,open_by_handle_at -F a2&03 -F path=/etc/passwd -F auid>=1000 -F auid!=unset -F key=user-modify
-a always,exit -F arch=b64 -S open -F a1&03 -F path=/etc/passwd -F auid>=1000 -F auid!=unset -F key=user-modify
-a always,exit -F arch=b64 -S openat,open_by_handle_at -F a2&03 -F path=/etc/shadow -F auid>=1000 -F auid!=unset -F key=user-modify
-a always,exit -F arch=b64 -S open -F a1&03 -F path=/etc/shadow -F auid>=1000 -F auid!=unset -F key=user-modify
## User enable and disable. This is entirely handled by pam.
## Group add delete modify. This is covered by pam. However, someone could
## open a file and directly create or modify a user, so we'll watch group and
## gshadow for writes
-a always,exit -F path=/etc/passwd -F perm=wa -F auid>=1000 -F auid!=unset -F key=user-modify
-a always,exit -F path=/etc/shadow -F perm=wa -F auid>=1000 -F auid!=unset -F key=user-modify
-a always,exit -F path=/etc/group -F perm=wa -F auid>=1000 -F auid!=unset -F key=group-modify
-a always,exit -F path=/etc/gshadow -F perm=wa -F auid>=1000 -F auid!=unset -F key=group-modify
## Use of special rights for config changes. This would be use of setuid
## programs that relate to user accts. This is not all setuid apps because
## requirements are only for ones that affect system configuration.
-a always,exit -F path=/usr/sbin/unix_chkpwd -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/sbin/usernetctl -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/sbin/userhelper -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/sbin/seunshare -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/bin/mount -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/bin/newgrp -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/bin/newuidmap -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/bin/gpasswd -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/bin/newgidmap -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/bin/umount -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/bin/passwd -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/bin/crontab -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/bin/at -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
## Privilege escalation via su or sudo. This is entirely handled by pam.
## Watch for configuration changes to privilege escalation.
-a always,exit -F path=/etc/sudoers -F perm=wa -F key=special-config-changes
-a always,exit -F dir=/etc/sudoers.d/ -F perm=wa -F key=special-config-changes
## Audit log access
-a always,exit -F dir=/var/log/audit/ -F perm=r -F auid>=1000 -F auid!=unset -F key=access-audit-trail
## Attempts to Alter Process and Session Initiation Information
-a always,exit -F path=/var/run/utmp -F perm=wa -F auid>=1000 -F auid!=unset -F key=session
-a always,exit -F path=/var/log/btmp -F perm=wa -F auid>=1000 -F auid!=unset -F key=session
-a always,exit -F path=/var/log/wtmp -F perm=wa -F auid>=1000 -F auid!=unset -F key=session
## Attempts to modify MAC controls
-a always,exit -F dir=/etc/selinux/ -F perm=wa -F auid>=1000 -F auid!=unset -F key=MAC-policy
## Software updates. This is entirely handled by rpm.
## System start and shutdown. This is entirely handled by systemd
## Kernel Module loading. This is handled in 43-module-load.rules
## Application invocation. The requirements list an optional requirement
## FPT_SRP_EXT.1 Software Restriction Policies. This event is intended to
## state results from that policy. This would be handled entirely by
## that daemon.
Load new Audit rules into kernel by running:
augenrules --load
Note: This rule uses a special set of Audit rules to comply with OSPP 4.2.1. You may reuse this rule in different profiles. If you decide to do so, it is recommended that you inspect contents of the file closely and make sure that they are alligned with your needs. | Rationale: | Auditing of events listed in the description provides data for monitoring and investigation of potentially malicious events e.g. tampering with Audit logs, malicious access to files storing information about system users and groups etc. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_audit_ospp_general_ppc64le | Identifiers and References | Identifiers:
CCE-90786-5 References:
AU-2(a), FAU_GEN.1.1.c, SRG-OS-000004-GPOS-00004, SRG-OS-000241-GPOS-00091, SRG-OS-000476-GPOS-00221, SRG-OS-000327-GPOS-00127, SRG-OS-000475-GPOS-00220, SRG-OS-000239-GPOS-00089, SRG-OS-000274-GPOS-00104, SRG-OS-000275-GPOS-00105, SRG-OS-000303-GPOS-00120, SRG-OS-000304-GPOS-00121 | Remediation Kubernetes snippet ⇲---
apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
spec:
config:
ignition:
version: 3.1.0
storage:
files:
- contents:
source: data:,%23%23%20The%20purpose%20of%20these%20rules%20is%20to%20meet%20the%20requirements%20for%20Operating%0A%23%23%20System%20Protection%20Profile%20%28OSPP%29v4.2.%20These%20rules%20depends%20on%20having%0A%23%23%20the%20following%20rule%20files%20copied%20to%20%2Fetc%2Faudit%2Frules.d%3A%0A%23%23%0A%23%23%2010-base-config.rules%2C%2011-loginuid.rules%2C%0A%23%23%2030-ospp-v42-1-create-failed.rules%2C%2030-ospp-v42-1-create-success.rules%2C%0A%23%23%2030-ospp-v42-2-modify-failed.rules%2C%2030-ospp-v42-2-modify-success.rules%2C%0A%23%23%2030-ospp-v42-3-access-failed.rules%2C%2030-ospp-v42-3-access-success.rules%2C%0A%23%23%2030-ospp-v42-4-delete-failed.rules%2C%2030-ospp-v42-4-delete-success.rules%2C%0A%23%23%2030-ospp-v42-5-perm-change-failed.rules%2C%0A%23%23%2030-ospp-v42-5-perm-change-success.rules%2C%0A%23%23%2030-ospp-v42-6-owner-change-failed.rules%2C%0A%23%23%2030-ospp-v42-6-owner-change-success.rules%0A%23%23%0A%23%23%20original%20copies%20may%20be%20found%20in%20%2Fusr%2Fshare%2Faudit%2Fsample-rules%2F%0A%0A%0A%23%23%20User%20add%20delete%20modify.%20This%20is%20covered%20by%20pam.%20However%2C%20someone%20could%0A%23%23%20open%20a%20file%20and%20directly%20create%20or%20modify%20a%20user%2C%20so%20we%27ll%20watch%20passwd%20and%0A%23%23%20shadow%20for%20writes%0A-a%20always%2Cexit%20-F%20arch%3Db64%20-S%20openat%2Copen_by_handle_at%20-F%20a2%2603%20-F%20path%3D%2Fetc%2Fpasswd%20-F%20auid%3E%3D1000%20-F%20auid%21%3Dunset%20-F%20key%3Duser-modify%0A-a%20always%2Cexit%20-F%20arch%3Db64%20-S%20open%20-F%20a1%2603%20-F%20path%3D%2Fetc%2Fpasswd%20-F%20auid%3E%3D1000%20-F%20auid%21%3Dunset%20-F%20key%3Duser-modify%0A-a%20always%2Cexit%20-F%20arch%3Db64%20-S%20openat%2Copen_by_handle_at%20-F%20a2%2603%20-F%20path%3D%2Fetc%2Fshadow%20-F%20auid%3E%3D1000%20-F%20auid%21%3Dunset%20-F%20key%3Duser-modify%0A-a%20always%2Cexit%20-F%20arch%3Db64%20-S%20open%20-F%20a1%2603%20-F%20path%3D%2Fetc%2Fshadow%20-F%20auid%3E%3D1000%20-F%20auid%21%3Dunset%20-F%20key%3Duser-modify%0A%0A%23%23%20User%20enable%20and%20disable.%20This%20is%20entirely%20handled%20by%20pam.%0A%0A%23%23%20Group%20add%20delete%20modify.%20This%20is%20covered%20by%20pam.%20However%2C%20someone%20could%0A%23%23%20open%20a%20file%20and%20directly%20create%20or%20modify%20a%20user%2C%20so%20we%27ll%20watch%20group%20and%0A%23%23%20gshadow%20for%20writes%0A-a%20always%2Cexit%20-F%20path%3D%2Fetc%2Fpasswd%20-F%20perm%3Dwa%20-F%20auid%3E%3D1000%20-F%20auid%21%3Dunset%20-F%20key%3Duser-modify%0A-a%20always%2Cexit%20-F%20path%3D%2Fetc%2Fshadow%20-F%20perm%3Dwa%20-F%20auid%3E%3D1000%20-F%20auid%21%3Dunset%20-F%20key%3Duser-modify%0A-a%20always%2Cexit%20-F%20path%3D%2Fetc%2Fgroup%20-F%20perm%3Dwa%20-F%20auid%3E%3D1000%20-F%20auid%21%3Dunset%20-F%20key%3Dgroup-modify%0A-a%20always%2Cexit%20-F%20path%3D%2Fetc%2Fgshadow%20-F%20perm%3Dwa%20-F%20auid%3E%3D1000%20-F%20auid%21%3Dunset%20-F%20key%3Dgroup-modify%0A%0A%0A%23%23%20Use%20of%20special%20rights%20for%20config%20changes.%20This%20would%20be%20use%20of%20setuid%0A%23%23%20programs%20that%20relate%20to%20user%20accts.%20This%20is%20not%20all%20setuid%20apps%20because%0A%23%23%20requirements%20are%20only%20for%20ones%20that%20affect%20system%20configuration.%0A-a%20always%2Cexit%20-F%20path%3D%2Fusr%2Fsbin%2Funix_chkpwd%20-F%20perm%3Dx%20-F%20auid%3E%3D1000%20-F%20auid%21%3Dunset%20-F%20key%3Dspecial-config-changes%0A-a%20always%2Cexit%20-F%20path%3D%2Fusr%2Fsbin%2Fusernetctl%20-F%20perm%3Dx%20-F%20auid%3E%3D1000%20-F%20auid%21%3Dunset%20-F%20key%3Dspecial-config-changes%0A-a%20always%2Cexit%20-F%20path%3D%2Fusr%2Fsbin%2Fuserhelper%20-F%20perm%3Dx%20-F%20auid%3E%3D1000%20-F%20auid%21%3Dunset%20-F%20key%3Dspecial-config-changes%0A-a%20always%2Cexit%20-F%20path%3D%2Fusr%2Fsbin%2Fseunshare%20-F%20perm%3Dx%20-F%20auid%3E%3D1000%20-F%20auid%21%3Dunset%20-F%20key%3Dspecial-config-changes%0A-a%20always%2Cexit%20-F%20path%3D%2Fusr%2Fbin%2Fmount%20-F%20perm%3Dx%20-F%20auid%3E%3D1000%20-F%20auid%21%3Dunset%20-F%20key%3Dspecial-config-changes%0A-a%20always%2Cexit%20-F%20path%3D%2Fusr%2Fbin%2Fnewgrp%20-F%20perm%3Dx%20-F%20auid%3E%3D1000%20-F%20auid%21%3Dunset%20-F%20key%3Dspecial-config-changes%0A-a%20always%2Cexit%20-F%20path%3D%2Fusr%2Fbin%2Fnewuidmap%20-F%20perm%3Dx%20-F%20auid%3E%3D1000%20-F%20auid%21%3Dunset%20-F%20key%3Dspecial-config-changes%0A-a%20always%2Cexit%20-F%20path%3D%2Fusr%2Fbin%2Fgpasswd%20-F%20perm%3Dx%20-F%20auid%3E%3D1000%20-F%20auid%21%3Dunset%20-F%20key%3Dspecial-config-changes%0A-a%20always%2Cexit%20-F%20path%3D%2Fusr%2Fbin%2Fnewgidmap%20-F%20perm%3Dx%20-F%20auid%3E%3D1000%20-F%20auid%21%3Dunset%20-F%20key%3Dspecial-config-changes%0A-a%20always%2Cexit%20-F%20path%3D%2Fusr%2Fbin%2Fumount%20-F%20perm%3Dx%20-F%20auid%3E%3D1000%20-F%20auid%21%3Dunset%20-F%20key%3Dspecial-config-changes%0A-a%20always%2Cexit%20-F%20path%3D%2Fusr%2Fbin%2Fpasswd%20-F%20perm%3Dx%20-F%20auid%3E%3D1000%20-F%20auid%21%3Dunset%20-F%20key%3Dspecial-config-changes%0A-a%20always%2Cexit%20-F%20path%3D%2Fusr%2Fbin%2Fcrontab%20-F%20perm%3Dx%20-F%20auid%3E%3D1000%20-F%20auid%21%3Dunset%20-F%20key%3Dspecial-config-changes%0A-a%20always%2Cexit%20-F%20path%3D%2Fusr%2Fbin%2Fat%20-F%20perm%3Dx%20-F%20auid%3E%3D1000%20-F%20auid%21%3Dunset%20-F%20key%3Dspecial-config-changes%0A%0A%23%23%20Privilege%20escalation%20via%20su%20or%20sudo.%20This%20is%20entirely%20handled%20by%20pam.%0A%0A%23%23%20Watch%20for%20configuration%20changes%20to%20privilege%20escalation.%0A-a%20always%2Cexit%20-F%20path%3D%2Fetc%2Fsudoers%20-F%20perm%3Dwa%20-F%20key%3Dspecial-config-changes%0A-a%20always%2Cexit%20-F%20dir%3D%2Fetc%2Fsudoers.d%2F%20-F%20perm%3Dwa%20-F%20key%3Dspecial-config-changes%0A%0A%23%23%20Audit%20log%20access%0A-a%20always%2Cexit%20-F%20dir%3D%2Fvar%2Flog%2Faudit%2F%20-F%20perm%3Dr%20-F%20auid%3E%3D1000%20-F%20auid%21%3Dunset%20-F%20key%3Daccess-audit-trail%0A%23%23%20Attempts%20to%20Alter%20Process%20and%20Session%20Initiation%20Information%0A-a%20always%2Cexit%20-F%20path%3D%2Fvar%2Frun%2Futmp%20-F%20perm%3Dwa%20-F%20auid%3E%3D1000%20-F%20auid%21%3Dunset%20-F%20key%3Dsession%0A-a%20always%2Cexit%20-F%20path%3D%2Fvar%2Flog%2Fbtmp%20-F%20perm%3Dwa%20-F%20auid%3E%3D1000%20-F%20auid%21%3Dunset%20-F%20key%3Dsession%0A-a%20always%2Cexit%20-F%20path%3D%2Fvar%2Flog%2Fwtmp%20-F%20perm%3Dwa%20-F%20auid%3E%3D1000%20-F%20auid%21%3Dunset%20-F%20key%3Dsession%0A%0A%23%23%20Attempts%20to%20modify%20MAC%20controls%0A-a%20always%2Cexit%20-F%20dir%3D%2Fetc%2Fselinux%2F%20-F%20perm%3Dwa%20-F%20auid%3E%3D1000%20-F%20auid%21%3Dunset%20-F%20key%3DMAC-policy%0A%0A%23%23%20Software%20updates.%20This%20is%20entirely%20handled%20by%20rpm.%0A%0A%23%23%20System%20start%20and%20shutdown.%20This%20is%20entirely%20handled%20by%20systemd%0A%0A%23%23%20Kernel%20Module%20loading.%20This%20is%20handled%20in%2043-module-load.rules%0A%0A%23%23%20Application%20invocation.%20The%20requirements%20list%20an%20optional%20requirement%0A%23%23%20FPT_SRP_EXT.1%20Software%20Restriction%20Policies.%20This%20event%20is%20intended%20to%0A%23%23%20state%20results%20from%20that%20policy.%20This%20would%20be%20handled%20entirely%20by%0A%23%23%20that%20daemon.%0A
mode: 0600
path: /etc/audit/rules.d/30-ospp-v42.rules
overwrite: true
Remediation Ansible snippet ⇲Complexity: | low |
---|
Disruption: | low |
---|
Strategy: | restrict |
---|
- name: Put contents into /etc/audit/rules.d/30-ospp-v42.rules according to policy
copy:
dest: /etc/audit/rules.d/30-ospp-v42.rules
content: |+
## The purpose of these rules is to meet the requirements for Operating
## System Protection Profile (OSPP)v4.2. These rules depends on having
## the following rule files copied to /etc/audit/rules.d:
##
## 10-base-config.rules, 11-loginuid.rules,
## 30-ospp-v42-1-create-failed.rules, 30-ospp-v42-1-create-success.rules,
## 30-ospp-v42-2-modify-failed.rules, 30-ospp-v42-2-modify-success.rules,
## 30-ospp-v42-3-access-failed.rules, 30-ospp-v42-3-access-success.rules,
## 30-ospp-v42-4-delete-failed.rules, 30-ospp-v42-4-delete-success.rules,
## 30-ospp-v42-5-perm-change-failed.rules,
## 30-ospp-v42-5-perm-change-success.rules,
## 30-ospp-v42-6-owner-change-failed.rules,
## 30-ospp-v42-6-owner-change-success.rules
##
## original copies may be found in /usr/share/audit/sample-rules/
## User add delete modify. This is covered by pam. However, someone could
## open a file and directly create or modify a user, so we'll watch passwd and
## shadow for writes
-a always,exit -F arch=b64 -S openat,open_by_handle_at -F a2&03 -F path=/etc/passwd -F auid>=1000 -F auid!=unset -F key=user-modify
-a always,exit -F arch=b64 -S open -F a1&03 -F path=/etc/passwd -F auid>=1000 -F auid!=unset -F key=user-modify
-a always,exit -F arch=b64 -S openat,open_by_handle_at -F a2&03 -F path=/etc/shadow -F auid>=1000 -F auid!=unset -F key=user-modify
-a always,exit -F arch=b64 -S open -F a1&03 -F path=/etc/shadow -F auid>=1000 -F auid!=unset -F key=user-modify
## User enable and disable. This is entirely handled by pam.
## Group add delete modify. This is covered by pam. However, someone could
## open a file and directly create or modify a user, so we'll watch group and
## gshadow for writes
-a always,exit -F path=/etc/passwd -F perm=wa -F auid>=1000 -F auid!=unset -F key=user-modify
-a always,exit -F path=/etc/shadow -F perm=wa -F auid>=1000 -F auid!=unset -F key=user-modify
-a always,exit -F path=/etc/group -F perm=wa -F auid>=1000 -F auid!=unset -F key=group-modify
-a always,exit -F path=/etc/gshadow -F perm=wa -F auid>=1000 -F auid!=unset -F key=group-modify
## Use of special rights for config changes. This would be use of setuid
## programs that relate to user accts. This is not all setuid apps because
## requirements are only for ones that affect system configuration.
-a always,exit -F path=/usr/sbin/unix_chkpwd -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/sbin/usernetctl -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/sbin/userhelper -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/sbin/seunshare -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/bin/mount -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/bin/newgrp -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/bin/newuidmap -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/bin/gpasswd -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/bin/newgidmap -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/bin/umount -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/bin/passwd -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/bin/crontab -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/bin/at -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
## Privilege escalation via su or sudo. This is entirely handled by pam.
## Watch for configuration changes to privilege escalation.
-a always,exit -F path=/etc/sudoers -F perm=wa -F key=special-config-changes
-a always,exit -F dir=/etc/sudoers.d/ -F perm=wa -F key=special-config-changes
## Audit log access
-a always,exit -F dir=/var/log/audit/ -F perm=r -F auid>=1000 -F auid!=unset -F key=access-audit-trail
## Attempts to Alter Process and Session Initiation Information
-a always,exit -F path=/var/run/utmp -F perm=wa -F auid>=1000 -F auid!=unset -F key=session
-a always,exit -F path=/var/log/btmp -F perm=wa -F auid>=1000 -F auid!=unset -F key=session
-a always,exit -F path=/var/log/wtmp -F perm=wa -F auid>=1000 -F auid!=unset -F key=session
## Attempts to modify MAC controls
-a always,exit -F dir=/etc/selinux/ -F perm=wa -F auid>=1000 -F auid!=unset -F key=MAC-policy
## Software updates. This is entirely handled by rpm.
## System start and shutdown. This is entirely handled by systemd
## Kernel Module loading. This is handled in 43-module-load.rules
## Application invocation. The requirements list an optional requirement
## FPT_SRP_EXT.1 Software Restriction Policies. This event is intended to
## state results from that policy. This would be handled entirely by
## that daemon.
force: true
when:
- ansible_virtualization_type not in ["docker", "lxc", "openvz", "podman", "container"]
- ansible_architecture == "ppc64le"
tags:
- CCE-90786-5
- NIST-800-53-AU-2(a)
- audit_ospp_general_ppc64le
- low_complexity
- low_disruption
- medium_severity
- no_reboot_needed
- restrict_strategy
- name: Remove any permissions from other group
file:
path: /etc/audit/rules.d/30-ospp-v42.rules
mode: o-rwx
when:
- ansible_virtualization_type not in ["docker", "lxc", "openvz", "podman", "container"]
- ansible_architecture == "ppc64le"
tags:
- CCE-90786-5
- NIST-800-53-AU-2(a)
- audit_ospp_general_ppc64le
- low_complexity
- low_disruption
- medium_severity
- no_reboot_needed
- restrict_strategy
Remediation Shell script ⇲Complexity: | low |
---|
Disruption: | low |
---|
Strategy: | restrict |
---|
# Remediation is applicable only in certain platforms
if [ ! -f /.dockerenv ] && [ ! -f /run/.containerenv ] && { grep -q ppc64le /proc/sys/kernel/osrelease; }; then
cat << 'EOF' > /etc/audit/rules.d/30-ospp-v42.rules
## The purpose of these rules is to meet the requirements for Operating
## System Protection Profile (OSPP)v4.2. These rules depends on having
## the following rule files copied to /etc/audit/rules.d:
##
## 10-base-config.rules, 11-loginuid.rules,
## 30-ospp-v42-1-create-failed.rules, 30-ospp-v42-1-create-success.rules,
## 30-ospp-v42-2-modify-failed.rules, 30-ospp-v42-2-modify-success.rules,
## 30-ospp-v42-3-access-failed.rules, 30-ospp-v42-3-access-success.rules,
## 30-ospp-v42-4-delete-failed.rules, 30-ospp-v42-4-delete-success.rules,
## 30-ospp-v42-5-perm-change-failed.rules,
## 30-ospp-v42-5-perm-change-success.rules,
## 30-ospp-v42-6-owner-change-failed.rules,
## 30-ospp-v42-6-owner-change-success.rules
##
## original copies may be found in /usr/share/audit/sample-rules/
## User add delete modify. This is covered by pam. However, someone could
## open a file and directly create or modify a user, so we'll watch passwd and
## shadow for writes
-a always,exit -F arch=b64 -S openat,open_by_handle_at -F a2&03 -F path=/etc/passwd -F auid>=1000 -F auid!=unset -F key=user-modify
-a always,exit -F arch=b64 -S open -F a1&03 -F path=/etc/passwd -F auid>=1000 -F auid!=unset -F key=user-modify
-a always,exit -F arch=b64 -S openat,open_by_handle_at -F a2&03 -F path=/etc/shadow -F auid>=1000 -F auid!=unset -F key=user-modify
-a always,exit -F arch=b64 -S open -F a1&03 -F path=/etc/shadow -F auid>=1000 -F auid!=unset -F key=user-modify
## User enable and disable. This is entirely handled by pam.
## Group add delete modify. This is covered by pam. However, someone could
## open a file and directly create or modify a user, so we'll watch group and
## gshadow for writes
-a always,exit -F path=/etc/passwd -F perm=wa -F auid>=1000 -F auid!=unset -F key=user-modify
-a always,exit -F path=/etc/shadow -F perm=wa -F auid>=1000 -F auid!=unset -F key=user-modify
-a always,exit -F path=/etc/group -F perm=wa -F auid>=1000 -F auid!=unset -F key=group-modify
-a always,exit -F path=/etc/gshadow -F perm=wa -F auid>=1000 -F auid!=unset -F key=group-modify
## Use of special rights for config changes. This would be use of setuid
## programs that relate to user accts. This is not all setuid apps because
## requirements are only for ones that affect system configuration.
-a always,exit -F path=/usr/sbin/unix_chkpwd -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/sbin/usernetctl -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/sbin/userhelper -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/sbin/seunshare -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/bin/mount -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/bin/newgrp -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/bin/newuidmap -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/bin/gpasswd -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/bin/newgidmap -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/bin/umount -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/bin/passwd -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/bin/crontab -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/bin/at -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
## Privilege escalation via su or sudo. This is entirely handled by pam.
## Watch for configuration changes to privilege escalation.
-a always,exit -F path=/etc/sudoers -F perm=wa -F key=special-config-changes
-a always,exit -F dir=/etc/sudoers.d/ -F perm=wa -F key=special-config-changes
## Audit log access
-a always,exit -F dir=/var/log/audit/ -F perm=r -F auid>=1000 -F auid!=unset -F key=access-audit-trail
## Attempts to Alter Process and Session Initiation Information
-a always,exit -F path=/var/run/utmp -F perm=wa -F auid>=1000 -F auid!=unset -F key=session
-a always,exit -F path=/var/log/btmp -F perm=wa -F auid>=1000 -F auid!=unset -F key=session
-a always,exit -F path=/var/log/wtmp -F perm=wa -F auid>=1000 -F auid!=unset -F key=session
## Attempts to modify MAC controls
-a always,exit -F dir=/etc/selinux/ -F perm=wa -F auid>=1000 -F auid!=unset -F key=MAC-policy
## Software updates. This is entirely handled by rpm.
## System start and shutdown. This is entirely handled by systemd
## Kernel Module loading. This is handled in 43-module-load.rules
## Application invocation. The requirements list an optional requirement
## FPT_SRP_EXT.1 Software Restriction Policies. This event is intended to
## state results from that policy. This would be handled entirely by
## that daemon.
EOF
chmod o-rwx /etc/audit/rules.d/30-ospp-v42.rules
augenrules --load
else
>&2 echo 'Remediation is not applicable, nothing was done'
fi
|
|
Rule
Configure auditing of unsuccessful ownership changes
[ref] | Ensure that unsuccessful attempts to change an ownership of files or directories are audited.
The following rules configure audit as described above:
## Unsuccessful ownership change
-a always,exit -F arch=b32 -S lchown,fchown,chown,fchownat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=unsuccessful-owner-change
-a always,exit -F arch=b64 -S lchown,fchown,chown,fchownat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=unsuccessful-owner-change
-a always,exit -F arch=b32 -S lchown,fchown,chown,fchownat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=unsuccessful-owner-change
-a always,exit -F arch=b64 -S lchown,fchown,chown,fchownat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=unsuccessful-owner-change
Load new Audit rules into kernel by running:
augenrules --load
Note: This rule uses a special set of Audit rules to comply with OSPP 4.2.1. You may reuse this rule in different profiles. If you decide to do so, it is recommended that you inspect contents of the file closely and make sure that they are alligned with your needs. | Rationale: | Unsuccessful attempts to change an ownership of files or directories might be signs of a malicious activity. Having such events audited helps in monitoring and investigation of such activities. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_audit_owner_change_failed | Identifiers and References | Identifiers:
CCE-83675-9 References:
AU-2(a), FAU_GEN.1.1.c, SRG-OS-000462-GPOS-00206, SRG-OS-000463-GPOS-00207, SRG-OS-000465-GPOS-00209, SRG-OS-000474-GPOS-00219, SRG-OS-000475-GPOS-00220, SRG-OS-000466-GPOS-00210, SRG-OS-000064-GPOS-00033 | |
|
Rule
Configure auditing of unsuccessful ownership changes (AArch64)
[ref] | Ensure that unsuccessful attempts to change an ownership of files or directories are audited.
The following rules configure audit as described above:
## Unsuccessful ownership change
-a always,exit -F arch=b32 -S lchown,fchown,chown,fchownat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=unsuccessful-owner-change
-a always,exit -F arch=b64 -S fchown,fchownat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=unsuccessful-owner-change
-a always,exit -F arch=b32 -S lchown,fchown,chown,fchownat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=unsuccessful-owner-change
-a always,exit -F arch=b64 -S fchown,fchownat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=unsuccessful-owner-change
Load new Audit rules into kernel by running:
augenrules --load
Note: This rule uses a special set of Audit rules to comply with OSPP 4.2.1. You may reuse this rule in different profiles. If you decide to do so, it is recommended that you inspect contents of the file closely and make sure that they are alligned with your needs. | Rationale: | Unsuccessful attempts to change an ownership of files or directories might be signs of a malicious activity. Having such events audited helps in monitoring and investigation of such activities. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_audit_owner_change_failed_aarch64 | Identifiers and References | Identifiers:
CCE-85942-1 References:
AU-2(a), FAU_GEN.1.1.c, SRG-OS-000462-GPOS-00206, SRG-OS-000463-GPOS-00207, SRG-OS-000465-GPOS-00209, SRG-OS-000474-GPOS-00219, SRG-OS-000475-GPOS-00220, SRG-OS-000466-GPOS-00210, SRG-OS-000064-GPOS-00033 | |
|
Rule
Configure auditing of unsuccessful ownership changes (ppc64le)
[ref] | Ensure that unsuccessful attempts to change an ownership of files or directories are audited.
The following rules configure audit as described above:
## Unsuccessful ownership change
-a always,exit -F arch=b64 -S lchown,fchown,chown,fchownat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=unsuccessful-owner-change
-a always,exit -F arch=b64 -S lchown,fchown,chown,fchownat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=unsuccessful-owner-change
Load new Audit rules into kernel by running:
augenrules --load
Note: This rule uses a special set of Audit rules to comply with OSPP 4.2.1. You may reuse this rule in different profiles. If you decide to do so, it is recommended that you inspect contents of the file closely and make sure that they are alligned with your needs. | Rationale: | Unsuccessful attempts to change an ownership of files or directories might be signs of a malicious activity. Having such events audited helps in monitoring and investigation of such activities. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_audit_owner_change_failed_ppc64le | Identifiers and References | Identifiers:
CCE-85988-4 References:
AU-2(a), FAU_GEN.1.1.c, SRG-OS-000462-GPOS-00206, SRG-OS-000463-GPOS-00207, SRG-OS-000465-GPOS-00209, SRG-OS-000474-GPOS-00219, SRG-OS-000475-GPOS-00220, SRG-OS-000466-GPOS-00210, SRG-OS-000064-GPOS-00033 | |
|
Rule
Configure auditing of successful ownership changes
[ref] | Ensure that successful attempts to change an ownership of files or directories are audited.
The following rules configure audit as described above:
## Successful ownership change
-a always,exit -F arch=b32 -S lchown,fchown,chown,fchownat -F success=1 -F auid>=1000 -F auid!=unset -F key=successful-owner-change
-a always,exit -F arch=b64 -S lchown,fchown,chown,fchownat -F success=1 -F auid>=1000 -F auid!=unset -F key=successful-owner-change
Load new Audit rules into kernel by running:
augenrules --load
Note: This rule uses a special set of Audit rules to comply with OSPP 4.2.1. You may reuse this rule in different profiles. If you decide to do so, it is recommended that you inspect contents of the file closely and make sure that they are alligned with your needs. | Rationale: | Auditing of successful ownership changes of files or directories helps in monitoring or investingating of activities performed on the system. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_audit_owner_change_success | Identifiers and References | Identifiers:
CCE-83658-5 References:
AU-2(a), FAU_GEN.1.1.c, SRG-OS-000462-GPOS-00206, SRG-OS-000463-GPOS-00207, SRG-OS-000465-GPOS-00209, SRG-OS-000474-GPOS-00219, SRG-OS-000475-GPOS-00220, SRG-OS-000466-GPOS-00210, SRG-OS-000064-GPOS-00033 | |
|
Rule
Configure auditing of successful ownership changes (AArch64)
[ref] | Ensure that successful attempts to change an ownership of files or directories are audited.
The following rules configure audit as described above:
## Successful ownership change
-a always,exit -F arch=b32 -S lchown,fchown,chown,fchownat -F success=1 -F auid>=1000 -F auid!=unset -F key=successful-owner-change
-a always,exit -F arch=b64 -S fchown,fchownat -F success=1 -F auid>=1000 -F auid!=unset -F key=successful-owner-change
Load new Audit rules into kernel by running:
augenrules --load
Note: This rule uses a special set of Audit rules to comply with OSPP 4.2.1. You may reuse this rule in different profiles. If you decide to do so, it is recommended that you inspect contents of the file closely and make sure that they are alligned with your needs. | Rationale: | Auditing of successful ownership changes of files or directories helps in monitoring or investingating of activities performed on the system. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_audit_owner_change_success_aarch64 | Identifiers and References | Identifiers:
CCE-85948-8 References:
AU-2(a), FAU_GEN.1.1.c, SRG-OS-000462-GPOS-00206, SRG-OS-000463-GPOS-00207, SRG-OS-000465-GPOS-00209, SRG-OS-000474-GPOS-00219, SRG-OS-000475-GPOS-00220, SRG-OS-000466-GPOS-00210, SRG-OS-000064-GPOS-00033 | |
|
Rule
Configure auditing of successful ownership changes (ppc64le)
[ref] | Ensure that successful attempts to change an ownership of files or directories are audited.
The following rules configure audit as described above:
## Successful ownership change
-a always,exit -F arch=b64 -S lchown,fchown,chown,fchownat -F success=1 -F auid>=1000 -F auid!=unset -F key=successful-owner-change
Load new Audit rules into kernel by running:
augenrules --load
Note: This rule uses a special set of Audit rules to comply with OSPP 4.2.1. You may reuse this rule in different profiles. If you decide to do so, it is recommended that you inspect contents of the file closely and make sure that they are alligned with your needs. | Rationale: | Auditing of successful ownership changes of files or directories helps in monitoring or investingating of activities performed on the system. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_audit_owner_change_success_ppc64le | Identifiers and References | Identifiers:
CCE-85998-3 References:
AU-2(a), FAU_GEN.1.1.c, SRG-OS-000462-GPOS-00206, SRG-OS-000463-GPOS-00207, SRG-OS-000465-GPOS-00209, SRG-OS-000474-GPOS-00219, SRG-OS-000475-GPOS-00220, SRG-OS-000466-GPOS-00210, SRG-OS-000064-GPOS-00033 | |
|
Rule
Configure auditing of unsuccessful permission changes
[ref] | Ensure that unsuccessful attempts to change file or directory permissions are audited.
The following rules configure audit as described above:
## Unsuccessful permission change
-a always,exit -F arch=b32 -S chmod,fchmod,fchmodat,setxattr,lsetxattr,fsetxattr,removexattr,lremovexattr,fremovexattr -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=unsuccessful-perm-change
-a always,exit -F arch=b64 -S chmod,fchmod,fchmodat,setxattr,lsetxattr,fsetxattr,removexattr,lremovexattr,fremovexattr -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=unsuccessful-perm-change
-a always,exit -F arch=b32 -S chmod,fchmod,fchmodat,setxattr,lsetxattr,fsetxattr,removexattr,lremovexattr,fremovexattr -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=unsuccessful-perm-change
-a always,exit -F arch=b64 -S chmod,fchmod,fchmodat,setxattr,lsetxattr,fsetxattr,removexattr,lremovexattr,fremovexattr -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=unsuccessful-perm-change
Load new Audit rules into kernel by running:
augenrules --load
Note: This rule uses a special set of Audit rules to comply with OSPP 4.2.1. You may reuse this rule in different profiles. If you decide to do so, it is recommended that you inspect contents of the file closely and make sure that they are alligned with your needs. | Rationale: | Unsuccessful attempts to change permissions of files or directories might be signs of malicious activity. Having such events audited helps in monitoring and investigation of such activities. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_audit_perm_change_failed | Identifiers and References | Identifiers:
CCE-83676-7 References:
AU-2(a), FAU_GEN.1.1.c, SRG-OS-000462-GPOS-00206, SRG-OS-000463-GPOS-00207, SRG-OS-000465-GPOS-00209, SRG-OS-000474-GPOS-00219, SRG-OS-000475-GPOS-00220, SRG-OS-000466-GPOS-00210, SRG-OS-000064-GPOS-00033 | Remediation Ansible snippet ⇲Complexity: | low |
---|
Disruption: | low |
---|
Strategy: | restrict |
---|
- name: Put contents into /etc/audit/rules.d/30-ospp-v42-5-perm-change-failed.rules
according to policy
copy:
dest: /etc/audit/rules.d/30-ospp-v42-5-perm-change-failed.rules
content: |
## Unsuccessful permission change
-a always,exit -F arch=b32 -S chmod,fchmod,fchmodat,setxattr,lsetxattr,fsetxattr,removexattr,lremovexattr,fremovexattr -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=unsuccessful-perm-change
-a always,exit -F arch=b64 -S chmod,fchmod,fchmodat,setxattr,lsetxattr,fsetxattr,removexattr,lremovexattr,fremovexattr -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=unsuccessful-perm-change
-a always,exit -F arch=b32 -S chmod,fchmod,fchmodat,setxattr,lsetxattr,fsetxattr,removexattr,lremovexattr,fremovexattr -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=unsuccessful-perm-change
-a always,exit -F arch=b64 -S chmod,fchmod,fchmodat,setxattr,lsetxattr,fsetxattr,removexattr,lremovexattr,fremovexattr -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=unsuccessful-perm-change
force: true
when:
- ansible_virtualization_type not in ["docker", "lxc", "openvz", "podman", "container"]
- ( not ( ansible_architecture == "aarch64" ) and not ( ansible_architecture ==
"ppc64le" ) )
tags:
- CCE-83676-7
- NIST-800-53-AU-2(a)
- audit_perm_change_failed
- low_complexity
- low_disruption
- medium_severity
- no_reboot_needed
- restrict_strategy
- name: Remove any permissions from other group
file:
path: /etc/audit/rules.d/30-ospp-v42-5-perm-change-failed.rules
mode: o-rwx
when:
- ansible_virtualization_type not in ["docker", "lxc", "openvz", "podman", "container"]
- ( not ( ansible_architecture == "aarch64" ) and not ( ansible_architecture ==
"ppc64le" ) )
tags:
- CCE-83676-7
- NIST-800-53-AU-2(a)
- audit_perm_change_failed
- low_complexity
- low_disruption
- medium_severity
- no_reboot_needed
- restrict_strategy
Remediation Shell script ⇲Complexity: | low |
---|
Disruption: | low |
---|
Strategy: | restrict |
---|
# Remediation is applicable only in certain platforms
if [ ! -f /.dockerenv ] && [ ! -f /run/.containerenv ] && { ( ! ( grep -q aarch64 /proc/sys/kernel/osrelease ) && ! ( grep -q ppc64le /proc/sys/kernel/osrelease ) ); }; then
cat << 'EOF' > /etc/audit/rules.d/30-ospp-v42-5-perm-change-failed.rules
## Unsuccessful permission change
-a always,exit -F arch=b32 -S chmod,fchmod,fchmodat,setxattr,lsetxattr,fsetxattr,removexattr,lremovexattr,fremovexattr -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=unsuccessful-perm-change
-a always,exit -F arch=b64 -S chmod,fchmod,fchmodat,setxattr,lsetxattr,fsetxattr,removexattr,lremovexattr,fremovexattr -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=unsuccessful-perm-change
-a always,exit -F arch=b32 -S chmod,fchmod,fchmodat,setxattr,lsetxattr,fsetxattr,removexattr,lremovexattr,fremovexattr -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=unsuccessful-perm-change
-a always,exit -F arch=b64 -S chmod,fchmod,fchmodat,setxattr,lsetxattr,fsetxattr,removexattr,lremovexattr,fremovexattr -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=unsuccessful-perm-change
EOF
chmod o-rwx /etc/audit/rules.d/30-ospp-v42-5-perm-change-failed.rules
augenrules --load
else
>&2 echo 'Remediation is not applicable, nothing was done'
fi
|
|
Rule
Configure auditing of unsuccessful permission changes (AArch64)
[ref] | Ensure that unsuccessful attempts to change file or directory permissions are audited.
The following rules configure audit as described above:
## Unsuccessful permission change
-a always,exit -F arch=b32 -S chmod,fchmod,fchmodat,setxattr,lsetxattr,fsetxattr,removexattr,lremovexattr,fremovexattr -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=unsuccessful-perm-change
-a always,exit -F arch=b64 -S fchmod,fchmodat,setxattr,lsetxattr,fsetxattr,removexattr,lremovexattr,fremovexattr -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=unsuccessful-perm-change
-a always,exit -F arch=b32 -S chmod,fchmod,fchmodat,setxattr,lsetxattr,fsetxattr,removexattr,lremovexattr,fremovexattr -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=unsuccessful-perm-change
-a always,exit -F arch=b64 -S fchmod,fchmodat,setxattr,lsetxattr,fsetxattr,removexattr,lremovexattr,fremovexattr -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=unsuccessful-perm-change
Load new Audit rules into kernel by running:
augenrules --load
Note: This rule uses a special set of Audit rules to comply with OSPP 4.2.1. You may reuse this rule in different profiles. If you decide to do so, it is recommended that you inspect contents of the file closely and make sure that they are alligned with your needs. | Rationale: | Unsuccessful attempts to change permissions of files or directories might be signs of malicious activity. Having such events audited helps in monitoring and investigation of such activities. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_audit_perm_change_failed_aarch64 | Identifiers and References | Identifiers:
CCE-85950-4 References:
AU-2(a), FAU_GEN.1.1.c, SRG-OS-000462-GPOS-00206, SRG-OS-000463-GPOS-00207, SRG-OS-000465-GPOS-00209, SRG-OS-000474-GPOS-00219, SRG-OS-000475-GPOS-00220, SRG-OS-000466-GPOS-00210, SRG-OS-000064-GPOS-00033 | |
|
Rule
Configure auditing of unsuccessful permission changes (ppc64le)
[ref] | Ensure that unsuccessful attempts to change file or directory permissions are audited.
The following rules configure audit as described above:
## Unsuccessful permission change
-a always,exit -F arch=b64 -S chmod,fchmod,fchmodat,setxattr,lsetxattr,fsetxattr,removexattr,lremovexattr,fremovexattr -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=unsuccessful-perm-change
-a always,exit -F arch=b64 -S chmod,fchmod,fchmodat,setxattr,lsetxattr,fsetxattr,removexattr,lremovexattr,fremovexattr -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=unsuccessful-perm-change
Load new Audit rules into kernel by running:
augenrules --load
Note: This rule uses a special set of Audit rules to comply with OSPP 4.2.1. You may reuse this rule in different profiles. If you decide to do so, it is recommended that you inspect contents of the file closely and make sure that they are alligned with your needs. | Rationale: | Unsuccessful attempts to change permissions of files or directories might be signs of malicious activity. Having such events audited helps in monitoring and investigation of such activities. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_audit_perm_change_failed_ppc64le | Identifiers and References | Identifiers:
CCE-86000-7 References:
AU-2(a), FAU_GEN.1.1.c, SRG-OS-000462-GPOS-00206, SRG-OS-000463-GPOS-00207, SRG-OS-000465-GPOS-00209, SRG-OS-000474-GPOS-00219, SRG-OS-000475-GPOS-00220, SRG-OS-000466-GPOS-00210, SRG-OS-000064-GPOS-00033 | |
|
Rule
Configure auditing of successful permission changes
[ref] | Ensure that successful attempts to modify permissions of files or directories are audited.
The following rules configure audit as described above:
## Successful permission change
-a always,exit -F arch=b32 -S chmod,fchmod,fchmodat,setxattr,lsetxattr,fsetxattr,removexattr,lremovexattr,fremovexattr -F success=1 -F auid>=1000 -F auid!=unset -F key=successful-perm-change
-a always,exit -F arch=b64 -S chmod,fchmod,fchmodat,setxattr,lsetxattr,fsetxattr,removexattr,lremovexattr,fremovexattr -F success=1 -F auid>=1000 -F auid!=unset -F key=successful-perm-change
Load new Audit rules into kernel by running:
augenrules --load
Note: This rule uses a special set of Audit rules to comply with OSPP 4.2.1. You may reuse this rule in different profiles. If you decide to do so, it is recommended that you inspect contents of the file closely and make sure that they are alligned with your needs. | Rationale: | Auditing successful file or directory permission changes helps in monitoring and investigating of activities performed on the system. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_audit_perm_change_success | Identifiers and References | Identifiers:
CCE-83678-3 References:
AU-2(a), FAU_GEN.1.1.c, SRG-OS-000462-GPOS-00206, SRG-OS-000463-GPOS-00207, SRG-OS-000465-GPOS-00209, SRG-OS-000474-GPOS-00219, SRG-OS-000475-GPOS-00220, SRG-OS-000466-GPOS-00210, SRG-OS-000064-GPOS-00033 | |
|
Rule
Configure auditing of successful permission changes (AArch64)
[ref] | Ensure that successful attempts to modify permissions of files or directories are audited.
The following rules configure audit as described above:
## Successful permission change
-a always,exit -F arch=b32 -S chmod,fchmod,fchmodat,setxattr,lsetxattr,fsetxattr,removexattr,lremovexattr,fremovexattr -F success=1 -F auid>=1000 -F auid!=unset -F key=successful-perm-change
-a always,exit -F arch=b64 -S fchmod,fchmodat,setxattr,lsetxattr,fsetxattr,removexattr,lremovexattr,fremovexattr -F success=1 -F auid>=1000 -F auid!=unset -F key=successful-perm-change
Load new Audit rules into kernel by running:
augenrules --load
Note: This rule uses a special set of Audit rules to comply with OSPP 4.2.1. You may reuse this rule in different profiles. If you decide to do so, it is recommended that you inspect contents of the file closely and make sure that they are alligned with your needs. | Rationale: | Auditing successful file or directory permission changes helps in monitoring and investigating of activities performed on the system. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_audit_perm_change_success_aarch64 | Identifiers and References | Identifiers:
CCE-85952-0 References:
AU-2(a), FAU_GEN.1.1.c, SRG-OS-000462-GPOS-00206, SRG-OS-000463-GPOS-00207, SRG-OS-000465-GPOS-00209, SRG-OS-000474-GPOS-00219, SRG-OS-000475-GPOS-00220, SRG-OS-000466-GPOS-00210, SRG-OS-000064-GPOS-00033 | |
|
Rule
Configure auditing of successful permission changes (ppc64le)
[ref] | Ensure that successful attempts to modify permissions of files or directories are audited.
The following rules configure audit as described above:
## Successful permission change
-a always,exit -F arch=b64 -S chmod,fchmod,fchmodat,setxattr,lsetxattr,fsetxattr,removexattr,lremovexattr,fremovexattr -F success=1 -F auid>=1000 -F auid!=unset -F key=successful-perm-change
Load new Audit rules into kernel by running:
augenrules --load
Note: This rule uses a special set of Audit rules to comply with OSPP 4.2.1. You may reuse this rule in different profiles. If you decide to do so, it is recommended that you inspect contents of the file closely and make sure that they are alligned with your needs. | Rationale: | Auditing successful file or directory permission changes helps in monitoring and investigating of activities performed on the system. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_audit_perm_change_success_ppc64le | Identifiers and References | Identifiers:
CCE-86002-3 References:
AU-2(a), FAU_GEN.1.1.c, SRG-OS-000462-GPOS-00206, SRG-OS-000463-GPOS-00207, SRG-OS-000465-GPOS-00209, SRG-OS-000474-GPOS-00219, SRG-OS-000475-GPOS-00220, SRG-OS-000466-GPOS-00210, SRG-OS-000064-GPOS-00033 | |
|
Rule
Ensure the audit Subsystem is Installed
[ref] | The audit package should be installed. | Rationale: | The auditd service is an access monitoring and accounting daemon, watching system calls to audit any access, in comparison with potential local access control policy such as SELinux policy. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_package_audit_installed | Identifiers and References | Identifiers:
CCE-83649-4 References:
BP28(R50), CCI-000130, CCI-000131, CCI-000132, CCI-000133, CCI-000134, CCI-000135, CCI-000154, CCI-000158, CCI-000172, CCI-001464, CCI-001487, CCI-001814, CCI-001875, CCI-001876, CCI-001877, CCI-001878, CCI-001879, CCI-001880, CCI-001881, CCI-001882, CCI-001889, CCI-001914, CCI-002884, CCI-000169, CIP-004-6 R3.3, CIP-007-3 R6.5, AC-7(a), AU-7(1), AU-7(2), AU-14, AU-12(2), AU-2(a), CM-6(a), FAU_GEN.1, Req-10.1, 10.2.1, SRG-OS-000062-GPOS-00031, SRG-OS-000037-GPOS-00015, SRG-OS-000038-GPOS-00016, SRG-OS-000039-GPOS-00017, SRG-OS-000040-GPOS-00018, SRG-OS-000041-GPOS-00019, SRG-OS-000042-GPOS-00021, SRG-OS-000051-GPOS-00024, SRG-OS-000054-GPOS-00025, SRG-OS-000122-GPOS-00063, SRG-OS-000254-GPOS-00095, SRG-OS-000255-GPOS-00096, SRG-OS-000337-GPOS-00129, SRG-OS-000348-GPOS-00136, SRG-OS-000349-GPOS-00137, SRG-OS-000350-GPOS-00138, SRG-OS-000351-GPOS-00139, SRG-OS-000352-GPOS-00140, SRG-OS-000353-GPOS-00141, SRG-OS-000354-GPOS-00142, SRG-OS-000358-GPOS-00145, SRG-OS-000365-GPOS-00152, SRG-OS-000392-GPOS-00172, SRG-OS-000475-GPOS-00220, 4.1.1.1 | |
|
Rule
Enable auditd Service
[ref] | The auditd service is an essential userspace component of
the Linux Auditing System, as it is responsible for writing audit records to
disk.
The auditd service can be enabled with the following command:
$ sudo systemctl enable auditd.service | Rationale: | 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. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_service_auditd_enabled | Identifiers and References | Identifiers:
CCE-90829-3 References:
1, 11, 12, 13, 14, 15, 16, 19, 2, 3, 4, 5, 6, 7, 8, 9, 5.4.1.1, APO10.01, APO10.03, APO10.04, APO10.05, APO11.04, APO12.06, APO13.01, BAI03.05, BAI08.02, DSS01.03, DSS01.04, DSS02.02, DSS02.04, DSS02.07, DSS03.01, DSS03.05, DSS05.02, DSS05.03, DSS05.04, DSS05.05, DSS05.07, MEA01.01, MEA01.02, MEA01.03, MEA01.04, MEA01.05, MEA02.01, 3.3.1, 3.3.2, 3.3.6, CCI-000126, CCI-000130, CCI-000131, CCI-000132, CCI-000133, CCI-000134, CCI-000135, CCI-000154, CCI-000158, CCI-000172, CCI-000366, CCI-001464, CCI-001487, CCI-001814, CCI-001875, CCI-001876, CCI-001877, CCI-002884, CCI-001878, CCI-001879, CCI-001880, CCI-001881, CCI-001882, CCI-001889, CCI-001914, CCI-000169, 164.308(a)(1)(ii)(D), 164.308(a)(5)(ii)(C), 164.310(a)(2)(iv), 164.310(d)(2)(iii), 164.312(b), 4.2.3.10, 4.3.2.6.7, 4.3.3.3.9, 4.3.3.5.8, 4.3.3.6.6, 4.3.4.4.7, 4.3.4.5.6, 4.3.4.5.7, 4.3.4.5.8, 4.4.2.1, 4.4.2.2, 4.4.2.4, SR 1.13, SR 2.10, SR 2.11, SR 2.12, SR 2.6, SR 2.8, SR 2.9, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 6.1, SR 6.2, SR 7.1, SR 7.6, A.11.2.6, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, A.13.1.1, A.13.2.1, A.14.1.3, A.14.2.7, A.15.2.1, A.15.2.2, A.16.1.4, A.16.1.5, A.16.1.7, A.6.2.1, A.6.2.2, CIP-004-6 R3.3, CIP-007-3 R6.5, AC-2(g), AU-3, AU-10, AU-2(d), AU-12(c), AU-14(1), AC-6(9), CM-6(a), SI-4(23), DE.AE-3, DE.AE-5, DE.CM-1, DE.CM-3, DE.CM-7, ID.SC-4, PR.AC-3, PR.PT-1, PR.PT-4, RS.AN-1, RS.AN-4, FAU_GEN.1, Req-10.1, 10.2.1, SRG-OS-000062-GPOS-00031, SRG-OS-000037-GPOS-00015, SRG-OS-000038-GPOS-00016, SRG-OS-000039-GPOS-00017, SRG-OS-000040-GPOS-00018, SRG-OS-000041-GPOS-00019, SRG-OS-000042-GPOS-00021, SRG-OS-000051-GPOS-00024, SRG-OS-000054-GPOS-00025, SRG-OS-000122-GPOS-00063, SRG-OS-000254-GPOS-00095, SRG-OS-000255-GPOS-00096, SRG-OS-000337-GPOS-00129, SRG-OS-000348-GPOS-00136, SRG-OS-000349-GPOS-00137, SRG-OS-000350-GPOS-00138, SRG-OS-000351-GPOS-00139, SRG-OS-000352-GPOS-00140, SRG-OS-000353-GPOS-00141, SRG-OS-000354-GPOS-00142, SRG-OS-000358-GPOS-00145, SRG-OS-000365-GPOS-00152, SRG-OS-000392-GPOS-00172, SRG-OS-000475-GPOS-00220, 4.1.1.4 | |
|
Rule
Enable Auditing for Processes Which Start Prior to the Audit Daemon
[ref] | To ensure all processes can be audited, even those which start
prior to the audit daemon, add the argument audit=1 to the default
GRUB 2 command line for the Linux operating system.
To ensure that audit=1 is added as a kernel command line
argument to newly installed kernels, add audit=1 to the
default Grub2 command line for Linux operating systems. Modify the line within
/etc/default/grub as shown below:
GRUB_CMDLINE_LINUX="... audit=1 ..."
Run the following command to update command line for already installed kernels: # grubby --update-kernel=ALL --args="audit=1" | Rationale: | Each process on the system carries an "auditable" flag which indicates whether
its activities can be audited. Although auditd takes care of enabling
this for all processes which launch after it does, adding the kernel argument
ensures it is set for every process during boot. | Severity: | low | Rule ID: | xccdf_org.ssgproject.content_rule_grub2_audit_argument | Identifiers and References | Identifiers:
CCE-83651-0 References:
1, 11, 12, 13, 14, 15, 16, 19, 3, 4, 5, 6, 7, 8, 5.4.1.1, APO10.01, APO10.03, APO10.04, APO10.05, APO11.04, APO12.06, APO13.01, BAI03.05, BAI08.02, DSS01.04, DSS02.02, DSS02.04, DSS02.07, DSS03.01, DSS05.02, DSS05.03, DSS05.04, DSS05.07, MEA01.01, MEA01.02, MEA01.03, MEA01.04, MEA01.05, MEA02.01, 3.3.1, CCI-001464, CCI-000130, CCI-000135, CCI-000169, CCI-000172, CCI-002884, 164.308(a)(1)(ii)(D), 164.308(a)(5)(ii)(C), 164.310(a)(2)(iv), 164.310(d)(2)(iii), 164.312(b), 4.2.3.10, 4.3.2.6.7, 4.3.3.3.9, 4.3.3.5.8, 4.3.3.6.6, 4.3.4.4.7, 4.3.4.5.6, 4.3.4.5.7, 4.3.4.5.8, 4.4.2.1, 4.4.2.2, 4.4.2.4, SR 1.13, SR 2.10, SR 2.11, SR 2.12, SR 2.6, SR 2.8, SR 2.9, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 6.1, SR 7.1, SR 7.6, A.11.2.6, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, A.13.1.1, A.13.2.1, A.14.1.3, A.15.2.1, A.15.2.2, A.16.1.4, A.16.1.5, A.16.1.7, A.6.2.1, A.6.2.2, AC-17(1), AU-14(1), AU-10, CM-6(a), IR-5(1), DE.AE-3, DE.AE-5, ID.SC-4, PR.AC-3, PR.PT-1, PR.PT-4, RS.AN-1, RS.AN-4, FAU_GEN.1, Req-10.3, 10.7, SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215, SRG-OS-000473-GPOS-00218, SRG-OS-000254-GPOS-00095, 4.1.1.2 | |
|
Rule
Extend Audit Backlog Limit for the Audit Daemon
[ref] | To improve the kernel capacity to queue all log events, even those which occurred
prior to the audit daemon, add the argument audit_backlog_limit=8192 to the default
GRUB 2 command line for the Linux operating system.
To ensure that audit_backlog_limit=8192 is added as a kernel command line
argument to newly installed kernels, add audit_backlog_limit=8192 to the
default Grub2 command line for Linux operating systems. Modify the line within
/etc/default/grub as shown below:
GRUB_CMDLINE_LINUX="... audit_backlog_limit=8192 ..."
Run the following command to update command line for already installed kernels: # grubby --update-kernel=ALL --args="audit_backlog_limit=8192" | Rationale: | audit_backlog_limit sets the queue length for audit events awaiting transfer
to the audit daemon. Until the audit daemon is up and running, all log messages
are stored in this queue. If the queue is overrun during boot process, the action
defined by audit failure flag is taken. | Severity: | low | Rule ID: | xccdf_org.ssgproject.content_rule_grub2_audit_backlog_limit_argument | Identifiers and References | Identifiers:
CCE-83652-8 References:
CCI-000130, CCI-000135, CCI-000169, CCI-000172, CCI-001849, CCI-002884, CM-6(a), FAU_STG.1, FAU_STG.3, SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000254-GPOS-00095, SRG-OS-000341-GPOS-00132, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215, 4.1.1.3 | |
|
Group
GRUB2 bootloader configuration
Group contains 1 group and 6 rules |
[ref]
During the boot process, the boot loader is
responsible for starting the execution of the kernel and passing
options to it. The boot loader allows for the selection of
different kernels - possibly on different partitions or media.
The default Red Hat Enterprise Linux 9 boot loader for x86 systems is called GRUB2.
Options it can pass to the kernel include single-user mode, which
provides root access without any authentication, and the ability to
disable SELinux. To prevent local users from modifying the boot
parameters and endangering security, protect the boot loader configuration
with a password and ensure its configuration file's permissions
are set properly. |
Group
UEFI GRUB2 bootloader configuration
Group contains 1 rule |
[ref]
UEFI GRUB2 bootloader configuration |
Rule
Set the UEFI Boot Loader Password
[ref] | The grub2 boot loader should have a superuser account and password
protection enabled to protect boot-time settings.
Since plaintext passwords are a security risk, generate a hash for the password
by running the following command:
# grub2-setpassword
When prompted, enter the password that was selected.
Warning:
To prevent hard-coded passwords, automatic remediation of this control is not available. Remediation
must be automated as a component of machine provisioning, or followed manually as outlined above.
Also, do NOT manually add the superuser account and password to the
grub.cfg file as the grub2-mkconfig command overwrites this file. | Rationale: | 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. | Severity: | high | Rule ID: | xccdf_org.ssgproject.content_rule_grub2_uefi_password | Identifiers and References | Identifiers:
CCE-88654-9 References:
BP28(R17), 11, 12, 14, 15, 16, 18, 3, 5, DSS05.02, DSS05.04, DSS05.05, DSS05.07, DSS06.03, DSS06.06, 3.4.5, CCI-000213, 164.308(a)(1)(ii)(B), 164.308(a)(7)(i), 164.308(a)(7)(ii)(A), 164.310(a)(1), 164.310(a)(2)(i), 164.310(a)(2)(ii), 164.310(a)(2)(iii), 164.310(b), 164.310(c), 164.310(d)(1), 164.310(d)(2)(iii), 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.3, 4.3.3.5.4, 4.3.3.5.5, 4.3.3.5.6, 4.3.3.5.7, 4.3.3.5.8, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.1, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7, A.6.1.2, A.7.1.1, A.9.1.2, A.9.2.1, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5, CM-6(a), PR.AC-4, PR.AC-6, PR.PT-3, FIA_UAU.1, SRG-OS-000080-GPOS-00048, 1.4.1 | |
|
Rule
Disable Recovery Booting
[ref] | Red Hat Enterprise Linux 9 systems support an "recovery boot" option that can be used
to prevent services from being started. The GRUB_DISABLE_RECOVERY
configuration option in /etc/default/grub should be set to
true to disable the generation of recovery mode menu entries. It is
also required to change the runtime configuration, run:
$ sudo grubby --update-kernel=ALL | Rationale: | Using recovery boot, the console user could disable auditing, firewalls,
or other services, weakening system security. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_grub2_disable_recovery | Identifiers and References | Identifiers:
CCE-85986-8 References:
FIA_UAU.1 | |
|
Rule
Configure kernel to zero out memory before allocation
[ref] | To configure the kernel to zero out memory before allocating it, add the
init_on_alloc=1 argument to the default GRUB 2 command line.
To ensure that init_on_alloc=1 is added as a kernel command line
argument to newly installed kernels, add init_on_alloc=1 to the
default Grub2 command line for Linux operating systems. Modify the line within
/etc/default/grub as shown below:
GRUB_CMDLINE_LINUX="... init_on_alloc=1 ..."
Run the following command to update command line for already installed kernels: # grubby --update-kernel=ALL --args="init_on_alloc=1" | Rationale: | When the kernel configuration option init_on_alloc is enabled,
all page allocator and slab allocator memory will be zeroed when allocated,
eliminating many kinds of "uninitialized heap memory" flaws, effectively
preventing data leaks. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_grub2_init_on_alloc_argument | Identifiers and References | Identifiers:
CCE-85867-0 | |
|
Rule
Enable randomization of the page allocator
[ref] | To enable randomization of the page allocator in the kernel, add the
page_alloc.shuffle=1 argument to the default GRUB 2 command line.
To ensure that page_alloc.shuffle=1 is added as a kernel command line
argument to newly installed kernels, add page_alloc.shuffle=1 to the
default Grub2 command line for Linux operating systems. Modify the line within
/etc/default/grub as shown below:
GRUB_CMDLINE_LINUX="... page_alloc.shuffle=1 ..."
Run the following command to update command line for already installed kernels: # grubby --update-kernel=ALL --args="page_alloc.shuffle=1" | Rationale: | The CONFIG_SHUFFLE_PAGE_ALLOCATOR config option is primarily
focused on improving the average utilization of a direct-mapped
memory-side-cache. Aside of this performance effect, it also reduces
predictability of page allocations in situations when the bad actor can
crash the system and somehow leverage knowledge of (page) allocation order
right after a fresh reboot, or can control the timing between a
hot-pluggable memory node (as in NUMA node) and applications allocating
memory ouf of that node. The page_alloc.shuffle=1 kernel command
line parameter then forces this functionality irrespectively of memory cache
architecture. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_grub2_page_alloc_shuffle_argument | Identifiers and References | Identifiers:
CCE-85879-5 | |
|
Rule
Ensure debug-shell service is not enabled during boot
[ref] | systemd's debug-shell service is intended to
diagnose systemd related boot issues with various systemctl
commands. Once enabled and following a system reboot, the root shell
will be available on tty9 which is access by pressing
CTRL-ALT-F9 . The debug-shell service should only be used
for systemd related issues and should otherwise be disabled.
By default, the debug-shell systemd service is already disabled.
Ensure the debug-shell is not enabled by the systemd.debug-shel=1
boot paramenter option.
Check that the line GRUB_CMDLINE_LINUX="..." within /etc/default/grub
doesn't contain the argument systemd.debug-shell=1 .
Run the following command to update command line for already installed kernels:
# grubby --update-kernel=ALL --remove-args="systemd.debug-shell" | Rationale: | This prevents attackers with physical access from trivially bypassing security
on the machine through valid troubleshooting configurations and gaining root
access when the system is rebooted. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_grub2_systemd_debug-shell_argument_absent | Identifiers and References | Identifiers:
CCE-86292-0 References:
FIA_UAU.1 | |
|
Rule
Disable vsyscalls
[ref] | To disable use of virtual syscalls,
add the argument vsyscall=none to the default
GRUB 2 command line for the Linux operating system.
To ensure that vsyscall=none is added as a kernel command line
argument to newly installed kernels, add vsyscall=none to the
default Grub2 command line for Linux operating systems. Modify the line within
/etc/default/grub as shown below:
GRUB_CMDLINE_LINUX="... vsyscall=none ..."
Run the following command to update command line for already installed kernels: # grubby --update-kernel=ALL --args="vsyscall=none" | Rationale: | Virtual Syscalls provide an opportunity of attack for a user who has control
of the return instruction pointer. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_grub2_vsyscall_argument | Identifiers and References | Identifiers:
CCE-83842-5 References:
CCI-001084, CM-7(a), FPT_ASLR_EXT.1, SRG-OS-000480-GPOS-00227, SRG-OS-000134-GPOS-00068 | |
|
Group
zIPL bootloader configuration
Group contains 7 rules |
[ref]
During the boot process, the bootloader is
responsible for starting the execution of the kernel and passing
options to it.
The default Red Hat Enterprise Linux 9 boot loader for s390x systems is called zIPL. |
Rule
Enable Auditing to Start Prior to the Audit Daemon in zIPL
[ref] | To ensure all processes can be audited, even those which start prior to the audit daemon,
check that all boot entries in /boot/loader/entries/*.conf have audit=1
included in its options.
To ensure that new kernels and boot entries continue to enable audit,
add audit=1 to /etc/kernel/cmdline . | Rationale: | Each process on the system carries an "auditable" flag which indicates whether
its activities can be audited. Although auditd takes care of enabling
this for all processes which launch after it does, adding the kernel argument
ensures it is set for every process during boot. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_zipl_audit_argument | Identifiers and References | Identifiers:
CCE-84096-7 References:
FAU_GEN.1 | |
|
Rule
Extend Audit Backlog Limit for the Audit Daemon in zIPL
[ref] | To improve the kernel capacity to queue all log events, even those which start prior to the audit daemon,
check that all boot entries in /boot/loader/entries/*.conf have audit_backlog_limit=8192
included in its options.
To ensure that new kernels and boot entries continue to extend the audit log events queue,
add audit_backlog_limit=8192 to /etc/kernel/cmdline . | Rationale: | audit_backlog_limit sets the queue length for audit events awaiting transfer
to the audit daemon. Until the audit daemon is up and running, all log messages
are stored in this queue. If the queue is overrun during boot process, the action
defined by audit failure flag is taken. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_zipl_audit_backlog_limit_argument | Identifiers and References | Identifiers:
CCE-84099-1 References:
FAU_STG.1, FAU_STG.3 | |
|
Rule
Ensure all zIPL boot entries are BLS compliant
[ref] | Ensure that zIPL boot entries fully adheres to Boot Loader Specification (BLS)
by checking that /etc/zipl.conf doesn't contain image = . Warning:
To prevent breakage or removal of all boot entries oconfigured in /etc/zipl.conf
automated remediation for this rule is not available. | Rationale: | Red Hat Enterprise Linux 9 adheres to Boot Loader Specification (BLS) and is the prefered method of
configuration. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_zipl_bls_entries_only | Identifiers and References | Identifiers:
CCE-84092-6 | |
|
Rule
Ensure zIPL bootmap is up to date
[ref] | Make sure that /boot/bootmap is up to date.
Every time a boot entry or zIPL configuration is changed /boot/bootmap needs to
be updated to reflect the changes.
Run zipl command to generate an updated /boot/bootmap . | Rationale: | The file /boot/bootmap contains all boot data, keeping it up to date is crucial to
boot correct kernel and options. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_zipl_bootmap_is_up_to_date | Identifiers and References | Identifiers:
CCE-84098-3 | |
|
Rule
Configure kernel to zero out memory before allocation in zIPL
[ref] | To ensure that the kernel is configured to zero out memory before
allocation, check that all boot entries in
/boot/loader/entries/*.conf have init_on_alloc=1
included in its options.
To ensure that new kernels and boot entries continue to zero out memory
before allocation, add init_on_alloc=1 to /etc/kernel/cmdline . | Rationale: | When the kernel configuration option init_on_alloc is enabled,
all page allocator and slab allocator memory will be zeroed when allocated,
eliminating many kinds of "uninitialized heap memory" flaws, effectively
preventing data leaks. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_zipl_init_on_alloc_argument | Identifiers and References | Identifiers:
CCE-85868-8 | |
|
Rule
Enable randomization of the page allocator in zIPL
[ref] | To enable the randomization of the page allocator in the kernel, check that
all boot entries in /boot/loader/entries/*.conf have
page_alloc.shuffle=1 included in its options.
To enable randomization of the page allocator also for newly installed
kernels, add page_alloc.shuffle=1 to /etc/kernel/cmdline . | Rationale: | The CONFIG_SHUFFLE_PAGE_ALLOCATOR config option is primarily
focused on improving the average utilization of a direct-mapped
memory-side-cache. Aside of this performance effect, it also reduces
predictability of page allocations in situations when the bad actor can
crash the system and somehow leverage knowledge of (page) allocation order
right after a fresh reboot, or can control the timing between a
hot-pluggable memory node (as in NUMA node) and applications allocating
memory ouf of that node. The page_alloc.shuffle=1 kernel command
line parameter then forces this functionality irrespectively of memory cache
architecture. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_zipl_page_alloc_shuffle_argument | Identifiers and References | Identifiers:
CCE-85880-3 | |
|
Rule
Ensure debug-shell service is not enabled in zIPL
[ref] | systemd's debug-shell service is intended to
diagnose systemd related boot issues with various systemctl
commands. Once enabled and following a system reboot, the root shell
will be available on tty9 which is access by pressing
CTRL-ALT-F9 . The debug-shell service should only be used
for systemd related issues and should otherwise be disabled.
By default, the debug-shell systemd service is already disabled.
Ensure the debug-shell is not enabled by the systemd.debug-shel=1
boot paramenter option.
Check that not boot entries in /boot/loader/entries/*.conf have
systemd.debug-shell=1 included in its options.
To ensure that new kernels and boot entries don't enable the debug-shell, check
that systemd.debug-shell=1 is not present in /etc/kernel/cmdline . | Rationale: | This prevents attackers with physical access from trivially bypassing security
on the machine through valid troubleshooting configurations and gaining root
access when the system is rebooted. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_zipl_systemd_debug-shell_argument_absent | Identifiers and References | Identifiers:
CCE-86420-7 References:
FIA_UAU.1 | |
|
Group
Network Configuration and Firewalls
Group contains 5 groups and 6 rules |
[ref]
Most systems must be connected to a network of some
sort, and this brings with it the substantial risk of network
attack. This section discusses the security impact of decisions
about networking which must be made when configuring a system.
This section also discusses firewalls, network access
controls, and other network security frameworks, which allow
system-level rules to be written that can limit an attackers' ability
to connect to your system. These rules can specify that network
traffic should be allowed or denied from certain IP addresses,
hosts, and networks. The rules can also specify which of the
system's network services are available to particular hosts or
networks. |
Group
firewalld
Group contains 1 group and 2 rules |
[ref]
The dynamic firewall daemon firewalld provides a
dynamically managed firewall with support for network “zones” to assign
a level of trust to a network and its associated connections and interfaces.
It has support for IPv4 and IPv6 firewall settings. It supports Ethernet
bridges and has a separation of runtime and permanent configuration options.
It also has an interface for services or applications to add firewall rules
directly.
A graphical configuration tool, firewall-config , is used to configure
firewalld , which in turn uses iptables tool to communicate
with Netfilter in the kernel which implements packet filtering.
The firewall service provided by firewalld is dynamic rather than
static because changes to the configuration can be made at anytime and are
immediately implemented. There is no need to save or apply the changes. No
unintended disruption of existing network connections occurs as no part of
the firewall has to be reloaded. |
Group
Inspect and Activate Default firewalld Rules
Group contains 2 rules |
[ref]
Firewalls can be used to separate networks into different zones
based on the level of trust the user has decided to place on the devices and
traffic within that network. NetworkManager informs firewalld to which
zone an interface belongs. An interface's assigned zone can be changed by
NetworkManager or via the firewall-config tool.
The zone settings in /etc/firewalld/ are a range of preset settings
which can be quickly applied to a network interface. These are the zones
provided by firewalld sorted according to the default trust level of the
zones from untrusted to trusted:
drop
Any incoming network packets are dropped, there is no
reply. Only outgoing network connections are possible. block
Any incoming network connections are rejected with an
icmp-host-prohibited message for IPv4 and icmp6-adm-prohibited
for IPv6. Only network connections initiated from within the system are
possible. public
For use in public areas. You do not trust the other
computers on the network to not harm your computer. Only selected incoming
connections are accepted. external
For use on external networks with masquerading enabled
especially for routers. You do not trust the other computers on the network to
not harm your computer. Only selected incoming connections are accepted. dmz
For computers in your demilitarized zone that are
publicly-accessible with limited access to your internal network. Only selected
incoming connections are accepted. work
For use in work areas. You mostly trust the other computers
on networks to not harm your computer. Only selected incoming connections are
accepted. home
For use in home areas. You mostly trust the other computers
on networks to not harm your computer. Only selected incoming connections are
accepted. internal
For use on internal networks. You mostly trust the
other computers on the networks to not harm your computer. Only selected
incoming connections are accepted. trusted
All network connections are accepted.
It is possible to designate one of these zones to be the default zone. When
interface connections are added to NetworkManager , they are assigned
to the default zone. On installation, the default zone in firewalld is set to
be the public zone.
To find out all the settings of a zone, for example the public zone,
enter the following command as root:
# firewall-cmd --zone=public --list-all
Example output of this command might look like the following:
# firewall-cmd --zone=public --list-all
public
interfaces:
services: mdns dhcpv6-client ssh
ports:
forward-ports:
icmp-blocks: source-quench
To view the network zones currently active, enter the following command as root:
# firewall-cmd --get-service
The following listing displays the result of this command
on common Red Hat Enterprise Linux 9 system:
# firewall-cmd --get-service
amanda-client bacula bacula-client dhcp dhcpv6 dhcpv6-client dns ftp
high-availability http https imaps ipp ipp-client ipsec kerberos kpasswd
ldap ldaps libvirt libvirt-tls mdns mountd ms-wbt mysql nfs ntp openvpn
pmcd pmproxy pmwebapi pmwebapis pop3s postgresql proxy-dhcp radius rpc-bind
samba samba-client smtp ssh telnet tftp tftp-client transmission-client
vnc-server wbem-https
Finally to view the network zones that will be active after the next firewalld
service reload, enter the following command as root:
# firewall-cmd --get-service --permanent |
Rule
Install firewalld Package
[ref] | The firewalld package can be installed with the following command:
$ sudo dnf install firewalld | Rationale: | "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.
Red Hat Enterprise Linux 9 functionality (e.g., SSH) must be capable of taking enforcement action if the audit reveals unauthorized activity.
Automated control of remote access sessions allows organizations to ensure ongoing compliance with remote access policies by enforcing connection rules of remote access applications on a variety of information system components (e.g., servers, workstations, notebook computers, smartphones, and tablets)." | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_package_firewalld_installed | Identifiers and References | Identifiers:
CCE-84021-5 References:
CCI-002314, CM-6(a), FMT_SMF_EXT.1, SRG-OS-000096-GPOS-00050, SRG-OS-000297-GPOS-00115, SRG-OS-000298-GPOS-00116, SRG-OS-000480-GPOS-00227, SRG-OS-000480-GPOS-00232 | |
|
Rule
Verify firewalld Enabled
[ref] |
The firewalld service can be enabled with the following command:
$ sudo systemctl enable firewalld.service | Rationale: | Access control methods provide the ability to enhance system security posture
by restricting services and known good IP addresses and address ranges. This
prevents connections from unknown hosts and protocols. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_service_firewalld_enabled | Identifiers and References | Identifiers:
CCE-90833-5 References:
11, 3, 9, BAI10.01, BAI10.02, BAI10.03, BAI10.05, 3.1.3, 3.4.7, CCI-000366, CCI-000382, CCI-002314, 4.3.4.3.2, 4.3.4.3.3, SR 7.6, A.12.1.2, A.12.5.1, A.12.6.2, A.14.2.2, A.14.2.3, A.14.2.4, CIP-003-8 R4, CIP-003-8 R5, CIP-004-6 R3, AC-4, CM-7(b), CA-3(5), SC-7(21), CM-6(a), PR.IP-1, FMT_SMF_EXT.1, SRG-OS-000096-GPOS-00050, SRG-OS-000297-GPOS-00115, SRG-OS-000480-GPOS-00227, SRG-OS-000480-GPOS-00231, SRG-OS-000480-GPOS-00232, 3.4.1.2 | |
|
Group
Uncommon Network Protocols
Group contains 3 rules |
[ref]
The system includes support for several network protocols which are not commonly used.
Although security vulnerabilities in kernel networking code are not frequently discovered,
the consequences can be dramatic. Ensuring uncommon network protocols are disabled
reduces the system's risk to attacks targeted at its implementation of those protocols. Warning:
Although these protocols are not commonly used, avoid disruption
in your network environment by ensuring they are not needed
prior to disabling them. |
Rule
Disable CAN Support
[ref] | The Controller Area Network (CAN) is a serial communications
protocol which was initially developed for automotive and
is now also used in marine, industrial, and medical applications.
To configure the system to prevent the can
kernel module from being loaded, add the following line to the file /etc/modprobe.d/can.conf :
install can /bin/true | Rationale: | Disabling CAN protects the system against exploitation of any
flaws in its implementation. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_kernel_module_can_disabled | Identifiers and References | Identifiers:
CCE-84134-6 References:
CCI-000381, CCI-000366, AC-18, FMT_SMF_EXT.1, SRG-OS-000095-GPOS-00049, SRG-OS-000480-GPOS-00227 | |
|
Rule
Disable SCTP Support
[ref] | The Stream Control Transmission Protocol (SCTP) is a
transport layer protocol, designed to support the idea of
message-oriented communication, with several streams of messages
within one connection.
To configure the system to prevent the sctp
kernel module from being loaded, add the following line to the file /etc/modprobe.d/sctp.conf :
install sctp /bin/true | Rationale: | Disabling SCTP protects
the system against exploitation of any flaws in its implementation. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_kernel_module_sctp_disabled | Identifiers and References | Identifiers:
CCE-84139-5 References:
11, 14, 3, 9, 5.10.1, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS05.02, DSS05.05, DSS06.06, 3.4.6, CCI-000381, CCI-000366, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.3, 4.3.3.5.4, 4.3.3.5.5, 4.3.3.5.6, 4.3.3.5.7, 4.3.3.5.8, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.1, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, 4.3.4.3.2, 4.3.4.3.3, SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7, SR 7.6, A.12.1.2, A.12.5.1, A.12.6.2, A.14.2.2, A.14.2.3, A.14.2.4, A.9.1.2, CM-7(a), CM-7(b), CM-6(a), PR.IP-1, PR.PT-3, Req-1.4.2, 1.4.2, SRG-OS-000095-GPOS-00049, SRG-OS-000480-GPOS-00227 | |
|
Rule
Disable TIPC Support
[ref] | The Transparent Inter-Process Communication (TIPC) protocol
is designed to provide communications between nodes in a
cluster.
To configure the system to prevent the tipc
kernel module from being loaded, add the following line to the file /etc/modprobe.d/tipc.conf :
install tipc /bin/true Warning:
This configuration baseline was created to deploy the base operating system for general purpose
workloads. When the operating system is configured for certain purposes, such as
a node in High Performance Computing cluster, it is expected that
the tipc kernel module will be loaded. | Rationale: | Disabling TIPC protects
the system against exploitation of any flaws in its implementation. | Severity: | low | Rule ID: | xccdf_org.ssgproject.content_rule_kernel_module_tipc_disabled | Identifiers and References | Identifiers:
CCE-84065-2 References:
11, 14, 3, 9, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS05.02, DSS05.05, DSS06.06, CCI-000381, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.3, 4.3.3.5.4, 4.3.3.5.5, 4.3.3.5.6, 4.3.3.5.7, 4.3.3.5.8, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.1, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, 4.3.4.3.2, 4.3.4.3.3, SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7, SR 7.6, A.12.1.2, A.12.5.1, A.12.6.2, A.14.2.2, A.14.2.3, A.14.2.4, A.9.1.2, CM-7(a), CM-7(b), CM-6(a), PR.IP-1, PR.PT-3, FMT_SMF_EXT.1, SRG-OS-000095-GPOS-00049, 3.1.3 | |
|
Group
Wireless Networking
Group contains 1 group and 1 rule |
[ref]
Wireless networking, such as 802.11
(WiFi) and Bluetooth, can present a security risk to sensitive or
classified systems and networks. Wireless networking hardware is
much more likely to be included in laptop or portable systems than
in desktops or servers.
Removal of hardware provides the greatest assurance that the wireless
capability remains disabled. Acquisition policies often include provisions to
prevent the purchase of equipment that will be used in sensitive spaces and
includes wireless capabilities. If it is impractical to remove the wireless
hardware, and policy permits the device to enter sensitive spaces as long
as wireless is disabled, efforts should instead focus on disabling wireless capability
via software. |
Group
Disable Wireless Through Software Configuration
Group contains 1 rule |
[ref]
If it is impossible to remove the wireless hardware
from the device in question, disable as much of it as possible
through software. The following methods can disable software
support for wireless networking, but note that these methods do not
prevent malicious software or careless users from re-activating the
devices. |
Rule
Disable Bluetooth Kernel Module
[ref] | The kernel's module loading system can be configured to prevent
loading of the Bluetooth module. Add the following to
the appropriate /etc/modprobe.d configuration file
to prevent the loading of the Bluetooth module:
install bluetooth /bin/true | Rationale: | If Bluetooth functionality must be disabled, preventing the kernel
from loading the kernel module provides an additional safeguard against its
activation. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_kernel_module_bluetooth_disabled | Identifiers and References | Identifiers:
CCE-84067-8 References:
11, 12, 14, 15, 3, 8, 9, 5.13.1.3, APO13.01, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS01.04, DSS05.02, DSS05.03, DSS05.05, DSS06.06, 3.1.16, CCI-000085, CCI-001443, CCI-001444, CCI-001551, CCI-002418, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.3, 4.3.3.5.4, 4.3.3.5.5, 4.3.3.5.6, 4.3.3.5.7, 4.3.3.5.8, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.1, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, 4.3.4.3.2, 4.3.4.3.3, SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 7.1, SR 7.6, A.11.2.6, A.12.1.2, A.12.5.1, A.12.6.2, A.13.1.1, A.13.2.1, A.14.1.3, A.14.2.2, A.14.2.3, A.14.2.4, A.6.2.1, A.6.2.2, A.9.1.2, AC-18(a), AC-18(3), CM-7(a), CM-7(b), CM-6(a), MP-7, PR.AC-3, PR.IP-1, PR.PT-3, PR.PT-4, SRG-OS-000095-GPOS-00049, SRG-OS-000300-GPOS-00118 | |
|
Group
File Permissions and Masks
Group contains 4 groups and 13 rules |
[ref]
Traditional Unix security relies heavily on file and
directory permissions to prevent unauthorized users from reading or
modifying files to which they should not have access.
Several of the commands in this section search filesystems
for files or directories with certain characteristics, and are
intended to be run on every local partition on a given system.
When the variable PART appears in one of the commands below,
it means that the command is intended to be run repeatedly, with the
name of each local partition substituted for PART in turn.
The following command prints a list of all xfs partitions on the local
system, which is the default filesystem for Red Hat Enterprise Linux 9
installations:
$ mount -t xfs | awk '{print $3}'
For any systems that use a different
local filesystem type, modify this command as appropriate. |
Group
Restrict Partition Mount Options
Group contains 3 rules |
[ref]
System partitions can be mounted with certain options
that limit what files on those partitions can do. These options
are set in the /etc/fstab configuration file, and can be
used to make certain types of malicious behavior more difficult. |
Rule
Add nodev Option to /var/log/audit
[ref] | The nodev mount option can be used to prevent device files from
being created in /var/log/audit .
Legitimate character and block devices should exist only in
the /dev directory on the root partition or within chroot
jails built for system services.
Add the nodev option to the fourth column of
/etc/fstab for the line which controls mounting of
/var/log/audit . | Rationale: | The only legitimate location for device files is the /dev directory
located on the root partition. The only exception to this is chroot jails. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_mount_option_var_log_audit_nodev | Identifiers and References | Identifiers:
CCE-83882-1 References:
CCI-001764, CIP-003-8 R5.1.1, CIP-003-8 R5.3, CIP-004-6 R2.3, CIP-007-3 R2.1, CIP-007-3 R2.2, CIP-007-3 R2.3, CIP-007-3 R5.1, CIP-007-3 R5.1.1, CIP-007-3 R5.1.2, CM-7(a), CM-7(b), CM-6(a), AC-6, AC-6(1), MP-7, PR.IP-1, PR.PT-2, PR.PT-3, SRG-OS-000368-GPOS-00154, 1.1.6.3 | |
|
Rule
Add noexec Option to /var/log/audit
[ref] | The noexec mount option can be used to prevent binaries
from being executed out of /var/log/audit .
Add the noexec option to the fourth column of
/etc/fstab for the line which controls mounting of
/var/log/audit . | Rationale: | Allowing users to execute binaries from directories containing audit log files
such as /var/log/audit should never be necessary in normal operation and
can expose the system to potential compromise. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_mount_option_var_log_audit_noexec | Identifiers and References | Identifiers:
CCE-83878-9 References:
CCI-001764, CIP-003-8 R5.1.1, CIP-003-8 R5.3, CIP-004-6 R2.3, CIP-007-3 R2.1, CIP-007-3 R2.2, CIP-007-3 R2.3, CIP-007-3 R5.1, CIP-007-3 R5.1.1, CIP-007-3 R5.1.2, CM-7(a), CM-7(b), CM-6(a), AC-6, AC-6(1), MP-7, PR.IP-1, PR.PT-2, PR.PT-3, SRG-OS-000368-GPOS-00154, 1.1.6.2 | |
|
Rule
Add nosuid Option to /var/log/audit
[ref] | The nosuid mount option can be used to prevent
execution of setuid programs in /var/log/audit . The SUID and SGID permissions
should not be required in directories containing audit log files.
Add the nosuid option to the fourth column of
/etc/fstab for the line which controls mounting of
/var/log/audit . | Rationale: | The presence of SUID and SGID executables should be tightly controlled. Users
should not be able to execute SUID or SGID binaries from partitions
designated for audit log files. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_mount_option_var_log_audit_nosuid | Identifiers and References | Identifiers:
CCE-83893-8 References:
CCI-001764, CIP-003-8 R5.1.1, CIP-003-8 R5.3, CIP-004-6 R2.3, CIP-007-3 R2.1, CIP-007-3 R2.2, CIP-007-3 R2.3, CIP-007-3 R5.1, CIP-007-3 R5.1.1, CIP-007-3 R5.1.2, CM-7(a), CM-7(b), CM-6(a), AC-6, AC-6(1), MP-7, PR.IP-1, PR.PT-2, PR.PT-3, SRG-OS-000368-GPOS-00154, 1.1.6.4 | |
|
Group
Restrict Programs from Dangerous Execution Patterns
Group contains 2 groups and 10 rules |
[ref]
The recommendations in this section are designed to
ensure that the system's features to protect against potentially
dangerous program execution are activated.
These protections are applied at the system initialization or
kernel level, and defend against certain types of badly-configured
or compromised programs. |
Group
Disable Core Dumps
Group contains 1 rule |
[ref]
A core dump file is the memory image of an executable
program when it was terminated by the operating system due to
errant behavior. In most cases, only software developers
legitimately need to access these files. The core dump files may
also contain sensitive information, or unnecessarily occupy large
amounts of disk space.
Once a hard limit is set in /etc/security/limits.conf , or
to a file within the /etc/security/limits.d/ directory, a
user cannot increase that limit within his or her own session. If access
to core dumps is required, consider restricting them to only
certain users or groups. See the limits.conf man page for more
information.
The core dumps of setuid programs are further protected. The
sysctl variable fs.suid_dumpable controls whether
the kernel allows core dumps from these programs at all. The default
value of 0 is recommended. |
Rule
Disable acquiring, saving, and processing core dumps
[ref] | The systemd-coredump.socket unit is a socket activation of
the systemd-coredump@.service which processes core dumps.
By masking the unit, core dump processing is disabled. | Rationale: | 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. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_service_systemd-coredump_disabled | Identifiers and References | Identifiers:
CCE-83974-6 References:
CCI-000366, SC-7(10), FMT_SMF_EXT.1, SRG-OS-000480-GPOS-00227 | |
|
Group
Enable ExecShield
Group contains 1 rule |
[ref]
ExecShield describes kernel features that provide
protection against exploitation of memory corruption errors such as buffer
overflows. These features include random placement of the stack and other
memory regions, prevention of execution in memory that should only hold data,
and special handling of text buffers. These protections are enabled by default
on 32-bit systems and controlled through sysctl variables
kernel.exec-shield and kernel.randomize_va_space . On the latest
64-bit systems, kernel.exec-shield cannot be enabled or disabled with
sysctl . |
Rule
Restrict Exposed Kernel Pointer Addresses Access
[ref] | To set the runtime status of the kernel.kptr_restrict kernel parameter, run the following command: $ sudo sysctl -w kernel.kptr_restrict=1
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d : kernel.kptr_restrict = 1 | Rationale: | 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. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_sysctl_kernel_kptr_restrict | Identifiers and References | Identifiers:
CCE-83972-0 References:
BP28(R23), CCI-002824, CCI-000366, CIP-002-5 R1.1, CIP-002-5 R1.2, CIP-003-8 R5.1.1, CIP-003-8 R5.3, CIP-004-6 4.1, CIP-004-6 4.2, CIP-004-6 R2.2.3, CIP-004-6 R2.2.4, CIP-004-6 R2.3, CIP-004-6 R4, CIP-005-6 R1, CIP-005-6 R1.1, CIP-005-6 R1.2, CIP-007-3 R3, CIP-007-3 R3.1, CIP-007-3 R5.1, CIP-007-3 R5.1.2, CIP-007-3 R5.1.3, CIP-007-3 R5.2.1, CIP-007-3 R5.2.3, CIP-007-3 R8.4, CIP-009-6 R.1.1, CIP-009-6 R4, SC-30, SC-30(2), SC-30(5), CM-6(a), SRG-OS-000132-GPOS-00067, SRG-OS-000433-GPOS-00192, SRG-OS-000480-GPOS-00227 | |
|
Rule
Disable storing core dumps
[ref] | The kernel.core_pattern option specifies the core dumpfile pattern
name. It can be set to an empty string. In this case, the kernel
behaves differently based on another related option. If
kernel.core_uses_pid is set to 1 , then a file named as
.PID (where PID is process ID of the crashed process) is
created in the working directory. If kernel.core_uses_pid is set to
0 , no coredump is saved.
To set the runtime status of the kernel.core_pattern kernel parameter,
run the following command:
$ sudo sysctl -w kernel.core_pattern=
To make sure that the setting is persistent,
add the following line to a file in the directory /etc/sysctl.d :
kernel.core_pattern = | Rationale: | 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. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_sysctl_kernel_core_pattern_empty_string | Identifiers and References | Identifiers:
CCE-86005-6 References:
FMT_SMF_EXT.1 | |
|
Rule
Configure file name of core dumps
[ref] | To set the runtime status of the kernel.core_uses_pid kernel parameter, run the following command: $ sudo sysctl -w kernel.core_uses_pid=0
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d : kernel.core_uses_pid = 0 | Rationale: | The default coredump filename is core . By setting
core_uses_pid to 1 , the coredump filename becomes
core.PID . If core_pattern does not include
%p (default does not) and core_uses_pid is set, then
.PID will be appended to the filename.
When combined with kernel.core_pattern = "" configuration, it
is ensured that no core dumps are generated and also no confusing error
messages are printed by a shell. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_sysctl_kernel_core_uses_pid | Identifiers and References | Identifiers:
CCE-86003-1 References:
FMT_SMF_EXT.1 | |
|
Rule
Restrict Access to Kernel Message Buffer
[ref] | To set the runtime status of the kernel.dmesg_restrict kernel parameter, run the following command: $ sudo sysctl -w kernel.dmesg_restrict=1
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d : kernel.dmesg_restrict = 1 | Rationale: | Unprivileged access to the kernel syslog can expose sensitive kernel
address information. | Severity: | low | Rule ID: | xccdf_org.ssgproject.content_rule_sysctl_kernel_dmesg_restrict | Identifiers and References | Identifiers:
CCE-83952-2 References:
BP28(R23), 3.1.5, CCI-001090, CCI-001314, 164.308(a)(1)(ii)(D), 164.308(a)(3), 164.308(a)(4), 164.310(b), 164.310(c), 164.312(a), 164.312(e), SI-11(a), SI-11(b), SRG-OS-000132-GPOS-00067, SRG-OS-000138-GPOS-00069 | |
|
Rule
Disable Kernel Image Loading
[ref] | To set the runtime status of the kernel.kexec_load_disabled kernel parameter, run the following command: $ sudo sysctl -w kernel.kexec_load_disabled=1
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d : kernel.kexec_load_disabled = 1 | Rationale: | Disabling kexec_load allows greater control of the kernel memory.
It makes it impossible to load another kernel image after it has been disabled.
| Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_sysctl_kernel_kexec_load_disabled | Identifiers and References | Identifiers:
CCE-83954-8 References:
CCI-001749, CM-6, SRG-OS-000480-GPOS-00227, SRG-OS-000366-GPOS-00153 | |
|
Rule
Disallow kernel profiling by unprivileged users
[ref] | To set the runtime status of the kernel.perf_event_paranoid kernel parameter, run the following command: $ sudo sysctl -w kernel.perf_event_paranoid=2
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d : kernel.perf_event_paranoid = 2 | Rationale: | Kernel profiling can reveal sensitive information about kernel behaviour. | Severity: | low | Rule ID: | xccdf_org.ssgproject.content_rule_sysctl_kernel_perf_event_paranoid | Identifiers and References | Identifiers:
CCE-83959-7 References:
BP28(R23), CCI-001090, AC-6, FMT_SMF_EXT.1, SRG-OS-000132-GPOS-00067, SRG-OS-000138-GPOS-00069 | |
|
Rule
Disable Access to Network bpf() Syscall From Unprivileged Processes
[ref] | To prevent unprivileged processes from using the bpf() syscall
the kernel.unprivileged_bpf_disabled kernel parameter must
be set to 1 or 2 .
Writing 1 to this entry will disable unprivileged calls to bpf() ; once
disabled, calling bpf() without CAP_SYS_ADMIN or CAP_BPF will return -EPERM .
Once set to 1 , this can't be cleared from the running kernel anymore.
To set the runtime status of the kernel.unprivileged_bpf_disabled kernel parameter,
run the following command:
$ sudo sysctl -w kernel.unprivileged_bpf_disabled=1
To make sure that the setting is persistent,
add the following line to a file in the directory /etc/sysctl.d :
kernel.unprivileged_bpf_disabled = 1
Writing 2 to this entry will also disable unprivileged calls to bpf() ,
however, an admin can still change this setting later on, if needed, by
writing 0 or 1 to this entry.
To set the runtime status of the kernel.unprivileged_bpf_disabled kernel parameter,
run the following command:
$ sudo sysctl -w kernel.unprivileged_bpf_disabled=2
To make sure that the setting is persistent,
add the following line to a file in the directory /etc/sysctl.d :
kernel.unprivileged_bpf_disabled = 2 | Rationale: | Loading and accessing the packet filters programs and maps using the bpf()
syscall has the potential of revealing sensitive information about the kernel state. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_sysctl_kernel_unprivileged_bpf_disabled_accept_default | Identifiers and References | Identifiers:
CCE-87712-6 References:
CCI-000366, AC-6, SC-7(10), FMT_SMF_EXT.1, SRG-OS-000132-GPOS-00067, SRG-OS-000480-GPOS-00227 | |
|
Rule
Restrict usage of ptrace to descendant processes
[ref] | To set the runtime status of the kernel.yama.ptrace_scope kernel parameter, run the following command: $ sudo sysctl -w kernel.yama.ptrace_scope=1
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d : kernel.yama.ptrace_scope = 1 | Rationale: | Unrestricted usage of ptrace allows compromised binaries to run ptrace
on another processes of the user. Like this, the attacker can steal
sensitive information from the target processes (e.g. SSH sessions, web browser, ...)
without any additional assistance from the user (i.e. without resorting to phishing).
| Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_sysctl_kernel_yama_ptrace_scope | Identifiers and References | Identifiers:
CCE-83965-4 References:
BP28(R25), CCI-000366, SC-7(10), SRG-OS-000132-GPOS-00067, SRG-OS-000480-GPOS-00227 | |
|
Rule
Disable the use of user namespaces
[ref] | To set the runtime status of the user.max_user_namespaces kernel parameter,
run the following command:
$ sudo sysctl -w user.max_user_namespaces=0
To make sure that the setting is persistent,
add the following line to a file in the directory /etc/sysctl.d :
user.max_user_namespaces = 0
When containers are deployed on the machine, the value should be set
to large non-zero value. Warning:
This configuration baseline was created to deploy the base operating system for general purpose
workloads. When the operating system is configured for certain purposes, such as to host Linux Containers,
it is expected that user.max_user_namespaces will be enabled. | Rationale: | It is detrimental for operating systems to provide, or install by default, functionality exceeding requirements or system objectives.
These unnecessary capabilities or services are often overlooked and therefore may remain unsecured.
They increase the risk to the platform by providing additional attack vectors.
User namespaces are used primarily for Linux containers. The value 0
disallows the use of user namespaces. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_sysctl_user_max_user_namespaces | Identifiers and References | Identifiers:
CCE-83956-3 References:
CCI-000366, SC-39, CM-6(a), FMT_SMF_EXT.1, SRG-OS-000480-GPOS-00227 | |
|
Group
SELinux
Group contains 2 rules |
[ref]
SELinux is a feature of the Linux kernel which can be
used to guard against misconfigured or compromised programs.
SELinux enforces the idea that programs should be limited in what
files they can access and what actions they can take.
The default SELinux policy, as configured on Red Hat Enterprise Linux 9, has been
sufficiently developed and debugged that it should be usable on
almost any system with minimal configuration and a small
amount of system administrator training. This policy prevents
system services - including most of the common network-visible
services such as mail servers, FTP servers, and DNS servers - from
accessing files which those services have no valid reason to
access. This action alone prevents a huge amount of possible damage
from network attacks against services, from trojaned software, and
so forth.
This guide recommends that SELinux be enabled using the
default (targeted) policy on every Red Hat Enterprise Linux 9 system, unless that
system has unusual requirements which make a stronger policy
appropriate. |
Rule
Configure SELinux Policy
[ref] | The SELinux targeted policy is appropriate for
general-purpose desktops and servers, as well as systems in many other roles.
To configure the system to use this policy, add or correct the following line
in /etc/selinux/config :
SELINUXTYPE=targeted
Other policies, such as mls , provide additional security labeling
and greater confinement but are not compatible with many general-purpose
use cases. | Rationale: | Setting the SELinux policy to targeted or a more specialized policy
ensures the system will confine processes that are likely to be
targeted for exploitation, such as network or system services.
Note: During the development or debugging of SELinux modules, it is common to
temporarily place non-production systems in permissive mode. In such
temporary cases, SELinux policies should be developed, and once work
is completed, the system should be reconfigured to
targeted . | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_selinux_policytype | Identifiers and References | Identifiers:
CCE-84074-4 References:
BP28(R66), 1, 11, 12, 13, 14, 15, 16, 18, 3, 4, 5, 6, 8, 9, APO01.06, APO11.04, APO13.01, BAI03.05, DSS01.05, DSS03.01, DSS05.02, DSS05.04, DSS05.05, DSS05.07, DSS06.02, DSS06.03, DSS06.06, MEA02.01, 3.1.2, 3.7.2, CCI-002165, CCI-002696, 164.308(a)(1)(ii)(D), 164.308(a)(3), 164.308(a)(4), 164.310(b), 164.310(c), 164.312(a), 164.312(e), 4.2.3.4, 4.3.3.2.2, 4.3.3.3.9, 4.3.3.4, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.3, 4.3.3.5.4, 4.3.3.5.5, 4.3.3.5.6, 4.3.3.5.7, 4.3.3.5.8, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.1, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, 4.3.4.4.7, 4.4.2.1, 4.4.2.2, 4.4.2.4, 4.4.3.3, SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.10, SR 2.11, SR 2.12, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7, SR 2.8, SR 2.9, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 7.1, SR 7.6, A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.12.1.1, A.12.1.2, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, A.13.1.1, A.13.1.2, A.13.1.3, A.13.2.1, A.13.2.2, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.1, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5, CIP-003-8 R5.1.1, CIP-003-8 R5.2, CIP-003-8 R5.3, CIP-004-6 R2.2.3, CIP-004-6 R2.3, CIP-004-6 R3.3, CIP-007-3 R5.1, CIP-007-3 R5.1.2, CIP-007-3 R5.2, CIP-007-3 R5.3.1, CIP-007-3 R5.3.2, CIP-007-3 R5.3.3, CIP-007-3 R6.5, AC-3, AC-3(3)(a), AU-9, SC-7(21), DE.AE-1, ID.AM-3, PR.AC-4, PR.AC-5, PR.AC-6, PR.DS-5, PR.PT-1, PR.PT-3, PR.PT-4, SRG-OS-000445-GPOS-00199, 1.6.1.3 | |
|
Rule
Ensure SELinux State is Enforcing
[ref] | The SELinux state should be set to enforcing at
system boot time. In the file /etc/selinux/config , add or correct the
following line to configure the system to boot into enforcing mode:
SELINUX=enforcing | Rationale: | Setting the SELinux state to enforcing ensures SELinux is able to confine
potentially compromised processes to the security policy, which is designed to
prevent them from causing damage to the system or further elevating their
privileges. | Severity: | high | Rule ID: | xccdf_org.ssgproject.content_rule_selinux_state | Identifiers and References | Identifiers:
CCE-84079-3 References:
BP28(R4), BP28(R66), 1, 11, 12, 13, 14, 15, 16, 18, 3, 4, 5, 6, 8, 9, APO01.06, APO11.04, APO13.01, BAI03.05, DSS01.05, DSS03.01, DSS05.02, DSS05.04, DSS05.05, DSS05.07, DSS06.02, DSS06.03, DSS06.06, MEA02.01, 3.1.2, 3.7.2, CCI-001084, CCI-002165, CCI-002696, 164.308(a)(1)(ii)(D), 164.308(a)(3), 164.308(a)(4), 164.310(b), 164.310(c), 164.312(a), 164.312(e), 4.2.3.4, 4.3.3.2.2, 4.3.3.3.9, 4.3.3.4, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.3, 4.3.3.5.4, 4.3.3.5.5, 4.3.3.5.6, 4.3.3.5.7, 4.3.3.5.8, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.1, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, 4.3.4.4.7, 4.4.2.1, 4.4.2.2, 4.4.2.4, 4.4.3.3, SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.10, SR 2.11, SR 2.12, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7, SR 2.8, SR 2.9, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 7.1, SR 7.6, A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.12.1.1, A.12.1.2, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, A.13.1.1, A.13.1.2, A.13.1.3, A.13.2.1, A.13.2.2, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.1, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5, CIP-003-8 R5.1.1, CIP-003-8 R5.2, CIP-003-8 R5.3, CIP-004-6 R2.2.3, CIP-004-6 R2.3, CIP-004-6 R3.3, CIP-007-3 R5.1, CIP-007-3 R5.1.2, CIP-007-3 R5.2, CIP-007-3 R5.3.1, CIP-007-3 R5.3.2, CIP-007-3 R5.3.3, CIP-007-3 R6.5, AC-3, AC-3(3)(a), AU-9, SC-7(21), DE.AE-1, ID.AM-3, PR.AC-4, PR.AC-5, PR.AC-6, PR.DS-5, PR.PT-1, PR.PT-3, PR.PT-4, SRG-OS-000445-GPOS-00199, SRG-OS-000134-GPOS-00068, 1.6.1.5 | |
|
Group
Services
Group contains 7 groups and 20 rules |
[ref]
The best protection against vulnerable software is running less software. This section describes how to review
the software which Red Hat Enterprise Linux 9 installs on a system and disable software which is not needed. It
then enumerates the software packages installed on a default Red Hat Enterprise Linux 9 system and provides guidance about which
ones can be safely disabled.
Red Hat Enterprise Linux 9 provides a convenient minimal install option that essentially installs the bare necessities for a functional
system. When building Red Hat Enterprise Linux 9 systems, it is highly recommended to select the minimal packages and then build up
the system from there. |
Group
Base Services
Group contains 1 rule |
[ref]
This section addresses the base services that are installed on a
Red Hat Enterprise Linux 9 default installation which are not covered in other
sections. Some of these services listen on the network and
should be treated with particular discretion. Other services are local
system utilities that may or may not be extraneous. In general, system services
should be disabled if not required. |
Rule
Disable KDump Kernel Crash Analyzer (kdump)
[ref] | The kdump service provides a kernel crash dump analyzer. It uses the kexec
system call to boot a secondary kernel ("capture" kernel) following a system
crash, which can load information from the crashed kernel for analysis.
The kdump service can be disabled with the following command:
$ sudo systemctl mask --now kdump.service | Rationale: | 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. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_service_kdump_disabled | Identifiers and References | Identifiers:
CCE-84232-8 References:
11, 12, 14, 15, 3, 8, 9, APO13.01, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS01.04, DSS05.02, DSS05.03, DSS05.05, DSS06.06, CCI-000366, CCI-001665, 164.308(a)(1)(ii)(D), 164.308(a)(3), 164.308(a)(4), 164.310(b), 164.310(c), 164.312(a), 164.312(e), 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.3, 4.3.3.5.4, 4.3.3.5.5, 4.3.3.5.6, 4.3.3.5.7, 4.3.3.5.8, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.1, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, 4.3.4.3.2, 4.3.4.3.3, SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 7.1, SR 7.6, A.11.2.6, A.12.1.2, A.12.5.1, A.12.6.2, A.13.1.1, A.13.2.1, A.14.1.3, A.14.2.2, A.14.2.3, A.14.2.4, A.6.2.1, A.6.2.2, A.9.1.2, CM-7(a), CM-7(b), CM-6(a), PR.AC-3, PR.IP-1, PR.PT-3, PR.PT-4, FMT_SMF_EXT.1.1, SRG-OS-000269-GPOS-00103, SRG-OS-000480-GPOS-00227 | |
|
Group
Application Whitelisting Daemon
Group contains 2 rules |
[ref]
Fapolicyd (File Access Policy Daemon) implements application whitelisting
to decide file access rights. Applications that are known via a reputation
source are allowed access while unknown applications are not. The daemon
makes use of the kernel's fanotify interface to determine file access rights. |
|
|
Group
Network Time Protocol
Group contains 2 rules |
[ref]
The Network Time Protocol is used to manage the system
clock over a network. Computer clocks are not very accurate, so
time will drift unpredictably on unmanaged systems. Central time
protocols can be used both to ensure that time is consistent among
a network of systems, and that their time is consistent with the
outside world.
If every system on a network reliably reports the same time, then it is much
easier to correlate log messages in case of an attack. In addition, a number of
cryptographic protocols (such as Kerberos) use timestamps to prevent certain
types of attacks. If your network does not have synchronized time, these
protocols may be unreliable or even unusable.
Depending on the specifics of the network, global time accuracy may be just as
important as local synchronization, or not very important at all. If your
network is connected to the Internet, using a public timeserver (or one
provided by your enterprise) provides globally accurate timestamps which may be
essential in investigating or responding to an attack which originated outside
of your network.
A typical network setup involves a small number of internal systems operating
as NTP servers, and the remainder obtaining time information from those
internal servers.
There is a choice between the daemons ntpd and chronyd , which
are available from the repositories in the ntp and chrony
packages respectively.
The default chronyd daemon can work well when external time references
are only intermittently accesible, can perform well even when the network is
congested for longer periods of time, can usually synchronize the clock faster
and with better time accuracy, and quickly adapts to sudden changes in the rate
of the clock, for example, due to changes in the temperature of the crystal
oscillator. Chronyd should be considered for all systems which are
frequently suspended or otherwise intermittently disconnected and reconnected
to a network. Mobile and virtual systems for example.
The ntpd NTP daemon fully supports NTP protocol version 4 (RFC 5905),
including broadcast, multicast, manycast clients and servers, and the orphan
mode. It also supports extra authentication schemes based on public-key
cryptography (RFC 5906). The NTP daemon ( ntpd ) should be considered
for systems which are normally kept permanently on. Systems which are required
to use broadcast or multicast IP, or to perform authentication of packets with
the Autokey protocol, should consider using ntpd .
Refer to
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/configuring_basic_system_settings/using-chrony-to-configure-ntp_configuring-basic-system-settings#doc-wrapper
for more detailed comparison of features of chronyd
and ntpd daemon features respectively, and for further guidance how to
choose between the two NTP daemons.
The upstream manual pages at
http://chrony.tuxfamily.org/manual.html for
chronyd and
http://www.ntp.org for ntpd provide additional
information on the capabilities and configuration of each of the NTP daemons. |
Rule
The Chrony package is installed
[ref] | System time should be synchronized between all systems in an environment. This is
typically done by establishing an authoritative time server or set of servers and having all
systems synchronize their clocks to them.
The chrony package can be installed with the following command:
$ sudo dnf install chrony | Rationale: | Time synchronization is important to support time sensitive security mechanisms like
Kerberos and also ensures log files have consistent time records across the enterprise,
which aids in forensic investigations. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_package_chrony_installed | Identifiers and References | Identifiers:
CCE-84215-3 References:
BP28(R43), 0988, 1405, FMT_SMF_EXT.1, Req-10.4, 10.6.1, SRG-OS-000355-GPOS-00143, 2.1.1 | |
|
Rule
Disable chrony daemon from acting as server
[ref] | The port option in /etc/chrony.conf can be set to
0 to make chrony daemon to never open any listening port
for server operation and to operate strictly in a client-only mode. | Rationale: | In order to prevent unauthorized connection of devices, unauthorized transfer of information, or unauthorized tunneling (i.e., embedding of data types within data types), organizations must disable or restrict unused or unnecessary physical and logical ports/protocols on information systems.
Operating systems are capable of providing a wide variety of functions and services. Some of the functions and services provided by default may not be necessary to support essential organizational operations. Additionally, it is sometimes convenient to provide multiple services from a single component (e.g., VPN and IPS); however, doing so increases risk over limiting the services provided by any one component.
To support the requirements and principles of least functionality, the operating system must support the organizational requirements, providing only essential capabilities and limiting the use of ports, protocols, and/or services to only those required, authorized, and approved to conduct official business or to address authorized quality of life issues. | Severity: | low | Rule ID: | xccdf_org.ssgproject.content_rule_chronyd_client_only | Identifiers and References | Identifiers:
CCE-87543-5 References:
CCI-000381, AU-8(1), AU-12(1), FMT_SMF_EXT.1, SRG-OS-000096-GPOS-00050, SRG-OS-000095-GPOS-00049 | |
|
Group
SSH Server
Group contains 2 groups and 11 rules |
[ref]
The SSH protocol is recommended for remote login and
remote file transfer. SSH provides confidentiality and integrity
for data exchanged between two systems, as well as server
authentication, through the use of public key cryptography. The
implementation included with the system is called OpenSSH, and more
detailed documentation is available from its website,
https://www.openssh.com.
Its server program is called sshd and provided by the RPM package
openssh-server . |
Group
Configure OpenSSH Client if Necessary
Group contains 1 rule |
[ref]
The following configuration changes apply to the SSH client. They can
improve security parameters relwevant to the client user, e.g. increasing
entropy while generating initialization vectors. Note that these changes
influence only the default SSH client configuration. Changes in this group
can be overridden by the client user by modifying files within the
~/.ssh directory or by supplying parameters on the command line. |
Rule
Configure session renegotiation for SSH client
[ref] | The RekeyLimit parameter specifies how often
the session key is renegotiated, both in terms of
amount of data that may be transmitted and the time
elapsed. To decrease the default limits, put line
RekeyLimit 1G 1h to file /etc/ssh/ssh_config.d/02-rekey-limit.conf .
Make sure that there is no other RekeyLimit configuration preceding
the include directive in the main config file
/etc/ssh/ssh_config . Check also other files in
/etc/ssh/ssh_config.d directory. Files are processed according to
lexicographical order of file names. Make sure that there is no file
processed before 02-rekey-limit.conf containing definition of
RekeyLimit . | Rationale: | By decreasing the limit based on the amount of data and enabling
time-based limit, effects of potential attacks against
encryption keys are limited. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_ssh_client_rekey_limit | Identifiers and References | Identifiers:
CCE-87522-9 References:
CCI-000068, FCS_SSH_EXT.1.8, SRG-OS-000423-GPOS-00187, SRG-OS-000033-GPOS-00014, SRG-OS-000424-GPOS-00188 | |
|
Group
Configure OpenSSH Server if Necessary
Group contains 8 rules |
[ref]
If the system needs to act as an SSH server, then
certain changes should be made to the OpenSSH daemon configuration
file /etc/ssh/sshd_config . The following recommendations can be
applied to this file. See the sshd_config(5) man page for more
detailed information. |
Rule
Disable Host-Based Authentication
[ref] | SSH's cryptographic host-based authentication is
more secure than .rhosts authentication. However, it is
not recommended that hosts unilaterally trust one another, even
within an organization.
The default SSH configuration disables host-based authentication. The appropriate
configuration is used if no value is set for HostbasedAuthentication .
To explicitly disable host-based authentication, add or correct the
following line in
/etc/ssh/sshd_config.d/00-complianceascode-hardening.conf :
HostbasedAuthentication no | Rationale: | SSH trust relationships mean a compromise on one host
can allow an attacker to move trivially to other hosts. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_disable_host_auth | Identifiers and References | Identifiers:
CCE-90816-0 References:
11, 12, 14, 15, 16, 18, 3, 5, 9, 5.5.6, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS05.02, DSS05.04, DSS05.05, DSS05.07, DSS06.03, DSS06.06, 3.1.12, CCI-000366, 164.308(a)(4)(i), 164.308(b)(1), 164.308(b)(3), 164.310(b), 164.312(e)(1), 164.312(e)(2)(ii), 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.3, 4.3.3.5.4, 4.3.3.5.5, 4.3.3.5.6, 4.3.3.5.7, 4.3.3.5.8, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.1, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, 4.3.4.3.2, 4.3.4.3.3, SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7, SR 7.6, 0421, 0422, 0431, 0974, 1173, 1401, 1504, 1505, 1546, 1557, 1558, 1559, 1560, 1561, A.12.1.2, A.12.5.1, A.12.6.2, A.14.2.2, A.14.2.3, A.14.2.4, A.6.1.2, A.7.1.1, A.9.1.2, A.9.2.1, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5, CIP-003-8 R5.1.1, CIP-003-8 R5.3, CIP-004-6 R2.2.3, CIP-004-6 R2.3, CIP-007-3 R5.1, CIP-007-3 R5.1.2, CIP-007-3 R5.2, CIP-007-3 R5.3.1, CIP-007-3 R5.3.2, CIP-007-3 R5.3.3, AC-3, AC-17(a), CM-7(a), CM-7(b), CM-6(a), PR.AC-4, PR.AC-6, PR.IP-1, PR.PT-3, FIA_UAU.1, 8.3.1, SRG-OS-000480-GPOS-00229, 5.2.8 | |
|
Rule
Disable SSH Access via Empty Passwords
[ref] | Disallow SSH login with empty passwords.
The default SSH configuration disables logins with empty passwords. The appropriate
configuration is used if no value is set for PermitEmptyPasswords .
To explicitly disallow SSH login from accounts with empty passwords,
add or correct the following line in
/etc/ssh/sshd_config.d/00-complianceascode-hardening.conf :
PermitEmptyPasswords no
Any accounts with empty passwords should be disabled immediately, and PAM configuration
should prevent users from being able to assign themselves empty passwords. | Rationale: | Configuring this setting for the SSH daemon provides additional assurance
that remote login via SSH will require a password, even in the event of
misconfiguration elsewhere. | Severity: | high | Rule ID: | xccdf_org.ssgproject.content_rule_sshd_disable_empty_passwords | Identifiers and References | Identifiers:
CCE-90799-8 References:
NT007(R17), 11, 12, 13, 14, 15, 16, 18, 3, 5, 9, 5.5.6, APO01.06, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS05.02, DSS05.04, DSS05.05, DSS05.07, DSS06.02, DSS06.03, DSS06.06, 3.1.1, 3.1.5, CCI-000366, CCI-000766, 164.308(a)(4)(i), 164.308(b)(1), 164.308(b)(3), 164.310(b), 164.312(e)(1), 164.312(e)(2)(ii), 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.3, 4.3.3.5.4, 4.3.3.5.5, 4.3.3.5.6, 4.3.3.5.7, 4.3.3.5.8, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.1, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, 4.3.4.3.2, 4.3.4.3.3, SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7, SR 5.2, SR 7.6, A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.12.1.2, A.12.5.1, A.12.6.2, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.14.2.2, A.14.2.3, A.14.2.4, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.1, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5, AC-17(a), CM-7(a), CM-7(b), CM-6(a), PR.AC-4, PR.AC-6, PR.DS-5, PR.IP-1, PR.PT-3, FIA_UAU.1, Req-2.2.4, 2.2.6, SRG-OS-000106-GPOS-00053, SRG-OS-000480-GPOS-00229, SRG-OS-000480-GPOS-00227, 5.2.9 | |
|
Rule
Disable GSSAPI Authentication
[ref] | Unless needed, SSH should not permit extraneous or unnecessary
authentication mechanisms like GSSAPI.
The default SSH configuration disallows authentications based on GSSAPI. The appropriate
configuration is used if no value is set for GSSAPIAuthentication .
To explicitly disable GSSAPI authentication, add or correct the following line in
/etc/ssh/sshd_config.d/00-complianceascode-hardening.conf :
GSSAPIAuthentication no | Rationale: | 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. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_sshd_disable_gssapi_auth | Identifiers and References | Identifiers:
CCE-90808-7 References:
11, 3, 9, BAI10.01, BAI10.02, BAI10.03, BAI10.05, 3.1.12, CCI-000318, CCI-000368, CCI-001812, CCI-001813, CCI-001814, CCI-000366, 164.308(a)(4)(i), 164.308(b)(1), 164.308(b)(3), 164.310(b), 164.312(e)(1), 164.312(e)(2)(ii), 4.3.4.3.2, 4.3.4.3.3, SR 7.6, 0418, 1055, 1402, A.12.1.2, A.12.5.1, A.12.6.2, A.14.2.2, A.14.2.3, A.14.2.4, CM-7(a), CM-7(b), CM-6(a), AC-17(a), PR.IP-1, FTP_ITC_EXT.1, FCS_SSH_EXT.1.2, SRG-OS-000364-GPOS-00151, SRG-OS-000480-GPOS-00227 | |
|
Rule
Disable Kerberos Authentication
[ref] | Unless needed, SSH should not permit extraneous or unnecessary
authentication mechanisms like Kerberos.
The default SSH configuration disallows authentication validation through Kerberos.
The appropriate configuration is used if no value is set for KerberosAuthentication .
To explicitly disable Kerberos authentication, add or correct the following line in
/etc/ssh/sshd_config.d/00-complianceascode-hardening.conf :
KerberosAuthentication no | Rationale: | Kerberos authentication for SSH is often implemented using GSSAPI. If Kerberos
is enabled through SSH, the SSH daemon provides a means of access to the
system's Kerberos implementation.
Configuring these settings for the SSH daemon provides additional assurance that remote logon via SSH will not use unused methods of authentication, even in the event of misconfiguration elsewhere. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_sshd_disable_kerb_auth | Identifiers and References | Identifiers:
CCE-90802-0 References:
11, 3, 9, BAI10.01, BAI10.02, BAI10.03, BAI10.05, 3.1.12, CCI-000318, CCI-000368, CCI-001812, CCI-001813, CCI-001814, CCI-000366, 164.308(a)(4)(i), 164.308(b)(1), 164.308(b)(3), 164.310(b), 164.312(e)(1), 164.312(e)(2)(ii), 4.3.4.3.2, 4.3.4.3.3, SR 7.6, 0421, 0422, 0431, 0974, 1173, 1401, 1504, 1505, 1546, 1557, 1558, 1559, 1560, 1561, A.12.1.2, A.12.5.1, A.12.6.2, A.14.2.2, A.14.2.3, A.14.2.4, AC-17(a), CM-7(a), CM-7(b), CM-6(a), PR.IP-1, FTP_ITC_EXT.1, FCS_SSH_EXT.1.2, SRG-OS-000364-GPOS-00151, SRG-OS-000480-GPOS-00227 | |
|
Rule
Disable SSH Root Login
[ref] | The root user should never be allowed to login to a
system directly over a network.
To disable root login via SSH, add or correct the following line in
/etc/ssh/sshd_config.d/00-complianceascode-hardening.conf :
PermitRootLogin no | Rationale: | 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. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_sshd_disable_root_login | Identifiers and References | Identifiers:
CCE-90800-4 References:
BP28(R19), NT007(R21), 1, 11, 12, 13, 14, 15, 16, 18, 3, 5, 5.5.6, APO01.06, DSS05.02, DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.02, DSS06.03, DSS06.06, DSS06.10, 3.1.1, 3.1.5, CCI-000366, CCI-000770, 164.308(a)(4)(i), 164.308(b)(1), 164.308(b)(3), 164.310(b), 164.312(e)(1), 164.312(e)(2)(ii), 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.3, 4.3.3.5.4, 4.3.3.5.5, 4.3.3.5.6, 4.3.3.5.7, 4.3.3.5.8, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.1, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7, SR 5.2, A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.18.1.4, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.1, A.9.4.2, A.9.4.3, A.9.4.4, A.9.4.5, CIP-003-8 R5.1.1, CIP-003-8 R5.3, CIP-004-6 R2.2.3, CIP-004-6 R2.3, CIP-007-3 R2.1, CIP-007-3 R2.2, CIP-007-3 R2.3, CIP-007-3 R5.1, CIP-007-3 R5.1.1, CIP-007-3 R5.1.2, CIP-007-3 R5.2, CIP-007-3 R5.3.1, CIP-007-3 R5.3.2, CIP-007-3 R5.3.3, AC-6(2), AC-17(a), IA-2, IA-2(5), CM-7(a), CM-7(b), CM-6(a), PR.AC-1, PR.AC-4, PR.AC-6, PR.AC-7, PR.DS-5, PR.PT-3, FAU_GEN.1, Req-2.2.4, 2.2.6, SRG-OS-000109-GPOS-00056, SRG-OS-000480-GPOS-00227, 5.2.7 | |
|
Rule
Enable SSH Warning Banner
[ref] | To enable the warning banner and ensure it is consistent
across the system, add or correct the following line in
/etc/ssh/sshd_config.d/00-complianceascode-hardening.conf :
Banner /etc/issue
Another section contains information on how to create an
appropriate system-wide warning banner. | Rationale: | 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. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_sshd_enable_warning_banner | Identifiers and References | Identifiers:
CCE-90807-9 References:
1, 12, 15, 16, 5.5.6, DSS05.04, DSS05.10, DSS06.10, 3.1.9, CCI-000048, CCI-000050, CCI-001384, CCI-001385, CCI-001386, CCI-001387, CCI-001388, 164.308(a)(4)(i), 164.308(b)(1), 164.308(b)(3), 164.310(b), 164.312(e)(1), 164.312(e)(2)(ii), 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, SR 1.1, SR 1.10, SR 1.2, SR 1.5, SR 1.7, SR 1.8, SR 1.9, A.18.1.4, A.9.2.1, A.9.2.4, A.9.3.1, A.9.4.2, A.9.4.3, AC-8(a), AC-8(c), AC-17(a), CM-6(a), PR.AC-7, FTA_TAB.1, Req-2.2.4, 2.2.6, SRG-OS-000023-GPOS-00006, SRG-OS-000228-GPOS-00088 | |
|
Rule
Force frequent session key renegotiation
[ref] | The RekeyLimit parameter specifies how often
the session key of the is renegotiated, both in terms of
amount of data that may be transmitted and the time
elapsed.
To decrease the default limits, add or correct the following line in
/etc/ssh/sshd_config.d/00-complianceascode-hardening.conf :
RekeyLimit 1G 1h | Rationale: | By decreasing the limit based on the amount of data and enabling
time-based limit, effects of potential attacks against
encryption keys are limited. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_sshd_rekey_limit | Identifiers and References | Identifiers:
CCE-90815-2 References:
CCI-000068, FCS_SSH_EXT.1.8, SRG-OS-000480-GPOS-00227, SRG-OS-000033-GPOS-00014 | |
|
Rule
Distribute the SSH Server configuration to multiple files in a config directory.
[ref] | Make sure to have the Include /etc/ssh/sshd_config.d/*.conf line in the /etc/ssh/sshd_config file.
Ideally, don't have any active configuration directives in that file, and distribute the service configuration
to several files in the /etc/ssh/sshd_config.d directory. | Rationale: | This form of distributed configuration is considered as a good practice, and as other sshd rules assume that directives in files in the /etc/ssh/sshd_config.d config directory are effective, there has to be a rule that ensures this.
Aside from that, having multiple configuration files makes the SSH Server configuration changes easier to partition according to the reason that they were introduced, and therefore it should help to perform merges of hardening updates. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_sshd_use_directory_configuration | Identifiers and References | Identifiers:
CCE-87681-3 | |
|
Rule
Install OpenSSH client software
[ref] | The openssh-clients package can be installed with the following command:
$ sudo dnf install openssh-clients | Rationale: | This package includes utilities to make encrypted connections and transfer
files securely to SSH servers. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_package_openssh-clients_installed | Identifiers and References | Identifiers:
CCE-90836-8 References:
FIA_UAU.5, FTP_ITC_EXT.1, FCS_SSH_EXT.1, FCS_SSHC_EXT.1, SRG-OS-000480-GPOS-00227 | |
|
Rule
Install the OpenSSH Server Package
[ref] | The openssh-server package should be installed.
The openssh-server package can be installed with the following command:
$ sudo dnf install openssh-server | Rationale: | Without protection of the transmitted information, confidentiality, and
integrity may be compromised because unprotected communications can be
intercepted and either read or altered. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_package_openssh-server_installed | Identifiers and References | Identifiers:
CCE-90823-6 References:
13, 14, APO01.06, DSS05.02, DSS05.04, DSS05.07, DSS06.02, DSS06.06, CCI-002418, CCI-002420, CCI-002421, CCI-002422, SR 3.1, SR 3.8, SR 4.1, SR 4.2, SR 5.2, A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5, CM-6(a), PR.DS-2, PR.DS-5, FIA_UAU.5, FTP_ITC_EXT.1, FCS_SSH_EXT.1, FCS_SSHS_EXT.1, SRG-OS-000423-GPOS-00187, SRG-OS-000424-GPOS-00188, SRG-OS-000425-GPOS-00189, SRG-OS-000426-GPOS-00190 | |
|
Group
USBGuard daemon
Group contains 4 rules |
[ref]
The USBGuard daemon enforces the USB device authorization policy for all USB devices. |
Rule
Install usbguard Package
[ref] |
The usbguard package can be installed with the following command:
$ sudo dnf install usbguard | Rationale: | usbguard is a software framework that helps to protect
against rogue USB devices by implementing basic whitelisting/blacklisting
capabilities based on USB device attributes.
| Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_package_usbguard_installed | Identifiers and References | Identifiers:
CCE-84203-9 References:
CCI-001958, 1418, CM-8(3), IA-3, SRG-OS-000378-GPOS-00163 | |
|
Rule
Enable the USBGuard Service
[ref] | The USBGuard service should be enabled.
The usbguard service can be enabled with the following command:
$ sudo systemctl enable usbguard.service | Rationale: | The usbguard service must be running in order to
enforce the USB device authorization policy for all USB devices. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_service_usbguard_enabled | Identifiers and References | Identifiers:
CCE-84205-4 References:
CCI-000416, CCI-001958, 1418, CM-8(3)(a), IA-3, FMT_SMF_EXT.1, SRG-OS-000378-GPOS-00163 | |
|
Rule
Log USBGuard daemon audit events using Linux Audit
[ref] | To configure USBGuard daemon to log via Linux Audit
(as opposed directly to a file),
AuditBackend option in /etc/usbguard/usbguard-daemon.conf
needs to be set to LinuxAudit . | Rationale: | Using the Linux Audit logging allows for centralized trace
of events. | Severity: | low | Rule ID: | xccdf_org.ssgproject.content_rule_configure_usbguard_auditbackend | Identifiers and References | Identifiers:
CCE-84206-2 References:
CCI-000169, CCI-000172, AU-2, CM-8(3), IA-3, FMT_SMF_EXT.1, SRG-OS-000062-GPOS-00031, SRG-OS-000471-GPOS-00215 | |
|
Rule
Authorize Human Interface Devices and USB hubs in USBGuard daemon
[ref] | To allow authorization of USB devices combining human interface device and hub capabilities
by USBGuard daemon,
add the line
allow with-interface match-all { 03:*:* 09:00:* }
to /etc/usbguard/rules.conf . Warning:
This rule should be understood primarily as a convenience administration feature. This rule ensures that if the USBGuard default rules.conf file is present, it will alter it so that USB human interface devices and hubs are allowed. However, if the rules.conf file is altered by system administrator, the rule does not check if USB human interface devices and hubs are allowed. This assumes that an administrator modified the file with some purpose in mind. | Rationale: | Without allowing Human Interface Devices, it might not be possible
to interact with the system. Without allowing hubs, it might not be possible to use any
USB devices on the system. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_usbguard_allow_hid_and_hub | Identifiers and References | Identifiers:
CCE-84210-4 References:
CM-8(3), IA-3, FMT_SMF_EXT.1, SRG-OS-000114-GPOS-00059 | |
|