Chapter 10. Security
The following chapters contain the most notable changes to security between RHEL 8 and RHEL 9.
10.1. Security compliance
CIS and DISA STIG profiles provided as DRAFT
The profiles based on benchmarks from the Center for Internet Security (CIS) and Defence Industry Security Association Security Technical Implementation Guides (DISA STIG) are provided as DRAFT because the issuing authorities have not yet published an official benchmark for RHEL 9. In addition, the OSSP profile is in DRAFT because it is being implemented.
For a complete list of profiles available in RHEL 9, see SCAP Security Guide profiles supported in RHEL 9.
OpenSCAP no longer supports SHA-1 and MD5
Due to removal of SHA-1 and MD5 hash functions in Red Hat Enterprise Linux 9, support for OVAL
filehash_test has been removed from OpenSCAP. Also, support for SHA-1 and MD5 hash functions has been removed from OVAL
filehash58_test implementation in OpenSCAP. As a result, OpenSCAP evaluates rules in SCAP content that use the OVAL
notchecked. In addition, OpenSCAP returns
notchecked also when evaluating OVAL
filehash58_test with the
hash_type element within
filehash58_object set to
To update your OVAL content, rewrite the affected SCAP content so that it uses
filehash58_test instead of
filehash_test and use one of
SHA-512 in the
hash_type element within
OpenSCAP uses the data stream file instead of the XCCDF file
The SCAP source data stream file (
ssg-rhel9-ds.xml) contains all the data that in previous versions of RHEL were contained in the XCCDF file (
ssg-rhel9-xccdf.xml). The SCAP source data stream is a container file that includes all the components (XCCDF, OVAL, CPE) needed to perform a compliance scan. Using the SCAP source data stream instead of XCCDF has been recommended since RHEL 7. In previous versions of RHEL, the data in the XCCDF file and SCAP source data stream was duplicated. In RHEL 9, this duplication is removed to reduce the RPM package size. If your scenario requires using separate files instead of the data stream, you can split the data stream file by using this command:
# oscap ds sds-split /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml output_directory.
10.2. Crypto-policies, RHEL core cryptographic components, and protocols
Continuing SHA-1 deprecation
In RHEL 9, SHA-1 usage for signatures is restricted in the DEFAULT system-wide cryptographic policy. Except for HMAC, SHA-1 is no longer allowed in TLS, DTLS, SSH, IKEv2, DNSSEC, and Kerberos protocols. Individual applications not controlled by the RHEL system-wide crypto policies are also moving away from using SHA-1 hashes in RHEL 9.
If your scenario requires the use of SHA-1 for verifying existing or third-party cryptographic signatures, you can enable it by entering the following command:
# update-crypto-policies --set DEFAULT:SHA1
Alternatively, you can switch the system-wide crypto policies to the
LEGACY policy. Note that
LEGACY also enables many other algorithms that are not secure. See the Re-enabling SHA-1 section in the RHEL 9 Security hardening document for more information.
For solutions of compatibility problems with systems that still require SHA-1, see the following KCS articles:
Algorithms disabled in all policy levels
The following algorithms are disabled in the
FUTURE crypto policies provided with RHEL 9:
- TLS older than version 1.2 (since RHEL 9, was < 1.0 in RHEL 8)
- DTLS older than version 1.2 (since RHEL 9, was < 1.0 in RHEL 8)
- DH with parameters < 2048 bits (since RHEL 9, was < 1024 bits in RHEL 8)
- RSA with key size < 2048 bits (since RHEL 9, was < 1024 bits in RHEL 8)
- DSA (since RHEL 9, was < 1024 bits in RHEL 8)
- 3DES (since RHEL 9)
- RC4 (since RHEL 9)
- FFDHE-1024 (since RHEL 9)
- DHE-DSS (since RHEL 9)
- Camellia (since RHEL 9)
- Integrity-only cipher suites
- TLS CBC mode cipher suites using SHA-384 HMAC
- All ECC curves incompatible with TLS 1.3, including secp256k1
- IKEv1 (since RHEL 8)
- NSEC3DSA in the BIND configuration (since RHEL 9.2)
If your scenario requires a policy that has been disabled, you can enable it by applying a custom cryptographic policy or by an explicit configuration of individual applications, but the resulting configuration will not be supported.
Changes to TLS
In RHEL 9, TLS configuration is performed using the system-wide cryptographic policies mechanism. TLS versions below 1.2 are not supported anymore.
LEGACY cryptographic policies allow only TLS 1.2 and 1.3. See Using system-wide cryptographic policies for more information.
The default settings provided by libraries included in RHEL 9 are secure enough for most deployments. The TLS implementations use secure algorithms where possible while not preventing connections from or to legacy clients or servers. Apply hardened settings in environments with strict security requirements where legacy clients or servers that do not support secure algorithms or protocols are not expected or allowed to connect.
Extended Master Secret TLS Extension is now enforced on FIPS-enabled systems
With the release of the RHSA-2023:3722 advisory, the TLS
Extended Master Secret (EMS) extension (RFC 7627) is mandatory for TLS 1.2 connections on FIPS-enabled RHEL 9 systems. This is in accordance with FIPS-140-3 requirements. TLS 1.3 is not affected.
Legacy clients that do not support EMS or TLS 1.3 now cannot connect to FIPS servers running on RHEL 9. Similarly, RHEL 9 clients in FIPS mode cannot connect to servers that only support TLS 1.2 without EMS. This in practice means that these clients cannot connect to servers on RHEL 6, RHEL 7 and non-RHEL legacy operating systems. This is because the legacy 1.0.x versions of OpenSSL do not support EMS or TLS 1.3.
SCP not supported in RHEL 9
The secure copy protocol (SCP) protocol is no longer supported because it is difficult to secure. It has already caused security issues, for example CVE-2020-15778. In RHEL 9, SCP is replaced by the SSH File Transfer Protocol (SFTP) by default.
By default, SSH cannot connect from RHEL 9 systems to older systems (for example, RHEL 6) or from older systems to RHEL 9. This is because the cryptographic algorithms used in older versions are now considered insecure. If your scenario requires connecting with older systems, you can either use the ECDSA and ECDH algorithms as keys on the legacy system or use the legacy cryptographic policy on the RHEL 9 system. For additional details, see the solutions SSH from RHEL 9 to RHEL 6 systems does not work and Failed connection with SSH servers and clients that do not support the server-sig-algs extension.
OpenSSH root password login disabled by default
The default configuration of OpenSSH in RHEL 9 disallows users to log in as
root with a password to prevent attackers from gaining access through brute-force attacks on passwords.
OpenSSH further enforces SHA-2
As part of the effort to migrate further from the less secure SHA-1 message digest for cryptographic purposes, the following changes were made in OpenSSH:
Added a check on
sshdstartup whether using SHA-1 is configured on the system. If it is not available, OpenSSH does not try to use SHA-1 for operations. This eliminates loading DSS keys when they are present and also enforces advertising
rsa-sha2combinations when they are available.
- On SSH private key conversion, OpenSSH explicitly uses SHA-2 for testing RSA keys.
When SHA-1 signatures are unavailable on the server side,
sshduses SHA-2 to confirm host key proof. This might be incompatible with clients on RHEL 8 and earlier versions.
- When the SHA-1 algorithm is unavailable on the client side, OpenSSH uses SHA-2.
- On the client side, OpenSSH permits SHA-2-based key proofs from the server when SHA-1 was used in key proof request or when the hash algorithm is not specified (assuming default). This is aligned with the already present exception for RSA certificates, and allows connecting by using modern algorithms when supported.
GnuTLS requires EMS with TLS 1.2 in FIPS mode
To comply with the FIPS-140-3 standard, GnuTLS servers and clients require the Extended Master Secret (EMS) extension (RFC 7627) for all TLS 1.2 connections negotiated in FIPS mode. If your scenario requires preserving compatibility with older servers and clients that do not support EMS and you cannot use TLS 1.3, you can apply the
NO-ENFORCE-EMS system-wide cryptographic subpolicy:
# update-crypto-policies --set FIPS:NO-ENFORCE-EMS
If you allow TLS 1.2 connections without EMS, your system no longer meets the FIPS-140-3 requirements.
GnuTLS no longer supports TPM 1.2
The GnuTLS library no longer supports the Trusted Platform Module (TPM) 1.2 technology. Your applications using TPM through the GnuTLS API must support TPM 2.0.
GnuTLS support for GOST has been removed
In RHEL 8, the GOST ciphers have been disabled through the system-wide cryptographic policies. In RHEL 9, support for these ciphers has been removed from the GnuTLS library.
cyrus-sasl now uses GDBM instead of Berkeley DB
cyrus-sasl package is now built without the
libdb dependency, and the
sasldb plugin uses the GDBM database format instead of Berkeley DB. To migrate your existing Simple Authentication and Security Layer (SASL) databases stored in the old Berkeley DB format, use the
cyrusbdb2current tool with the following syntax:
$ cyrusbdb2current <sasldb_path> <new_path>
NSS now enforce EMS in FIPS mode
The Network Security Services (NSS) libraries now contain the
TLS-REQUIRE-EMS policy to require the Extended Master Secret (EMS) extension (RFC 7627) for all TLS 1.2 connections as mandated by the FIPS 140-3 standard. NSS use the new policy when the system-wide cryptographic policies are set to
If your scenario requires interoperating with legacy systems without support for EMS or TLS 1.3, you can apply the
NO-ENFORCE-EMS system-wide cryptographic subpolicy. Such a change violates the FIPS-140-3 requirements.
NSS no longer support DBM and
pk12util defaults changed
The Network Security Services (NSS) libraries no longer support the DBM file format for the trust database. In RHEL 8, the SQLite file format became the default format, and the existing DBM databases were opened on read-only mode and automatically converted to SQLite. Before you upgrade to RHEL 9, update all trust databases from DBM to SQLite.
See the Updating NSS databases from DBM to SQLite procedure for detailed instructions.
pk12util no longer uses DES-3 and SHA-1 by default
pk12util tool now uses the AES and SHA-256 algorithms instead of DES-3 and SHA-1 by default when exporting private keys.
Note that SHA-1 is disabled by the default system-wide cryptographic policy for all signatures in RHEL 9.
NSS no longer support RSA keys shorter than 1023 bits
The update of the Network Security Services (NSS) libraries changes the minimum key size for all RSA operations from 128 to 1023 bits. This means that NSS no longer perform the following functions:
- Generate RSA keys shorter than 1023 bits.
- Sign or verify RSA signatures with RSA keys shorter than 1023 bits.
- Encrypt or decrypt values with RSA key shorter than 1023 bits.
OpenSSL ENGINE extension API is not supported in FIPS mode
The legacy extension system to OpenSSL, the ENGINE API, is not compatible with the new provider API. Therefore, applications that depend on functionality provided by OpenSSL engines, such as the
openssl-ibmca modules, cannot be used in FIPS mode.
FIPS mode in OpenSSL must be enabled to work correctly
If you are using non-default values in the
openssl.cnf configuration file with FIPS mode enabled, and especially when using a third-party FIPS provider, add
fips=yes to the
OpenSSL does not accept explicit curve parameters in FIPS mode
Elliptic curve cryptography parameters, private keys, public keys, and certificates that specified explicit curve parameters no longer work in FIPS mode. Specifying the curve parameters using ASN.1 object identifiers, which use one of the FIPS-approved curves, still works in FIPS mode.
Libreswan now requests ESN by default
In Libreswan, the default value for the configuration option
esn= has changed from
either. This means that when initiating connections, Libreswan requests the use of Extended Serial Number (ESN) by default. In particular, when hardware offload is used, this new behavior prevents certain network interface cards (NIC) from establishing IPsec connection if they do not support ESN. To disable ESN, set
no and the
replay_window= option to a value of 32 or lower. For example:
replay_window= option is necessary because a different mechanism uses ESN for anti-replay protection with window sizes larger than 32.
Support for disabling SELinux through
/etc/selinux/config has been removed
With the RHEL 9.0 release, support for disabling SELinux through the
SELINUX=disabled option in the
/etc/selinux/config file has been removed from the kernel. When you disable SELinux only through
/etc/selinux/config, the system starts with SELinux enabled but with no policy loaded, and SELinux security hooks remain registered in the kernel. This means that SELinux disabled by using
/etc/selinux/config still requires some system resources, and you should instead disable SELinux by using the kernel command line in all performance-sensitive scenarios.
Furthermore, the Anaconda installation program and the corresponding man pages have been updated to reflect this change. This change also enables read-only-after-initialization protection for the Linux Security Module (LSM) hooks.
If your scenario requires disabling SELinux, add the
selinux=0 parameter to your kernel command line.
See the Remove support for SELinux run-time disable Fedora wiki page for more information.
Additional services confined in the SELinux policy
The RHEL 9.3 release added additional rules to the SELinux policy that confine the following
As a result, these services do not run with the
unconfined_service_t SELinux label anymore, and run successfully in SELinux enforcing mode.