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 filehash_test as notchecked. In addition, OpenSCAP returns notchecked also when evaluating OVAL filehash58_test with the hash_type element within filehash58_object set to SHA-1 or MD5.

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-224, SHA-256, SHA-384, SHA-512 in the hash_type element within filehash58_object.

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 LEGACY, DEFAULT and 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)
  • ARIA
  • SEED
  • IDEA
  • Integrity-only cipher suites
  • TLS CBC mode cipher suites using SHA-384 HMAC
  • AES-CCM8
  • 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. DEFAULT, FUTURE and 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.

The 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 sshd startup 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-sha2 combinations 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, sshd uses 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

The 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 FIPS.

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.

NSS pk12util no longer uses DES-3 and SHA-1 by default

The 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-pkcs11 and 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.cnf file.

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 no to 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 esn= to no and the replay_window= option to a value of 32 or lower. For example:


The replay_window= option is necessary because a different mechanism uses ESN for anti-replay protection with window sizes larger than 32.

10.3. SELinux

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 systemd services:

  • qat
  • systemd-pstore
  • boothd
  • fdo-manufacturing-server
  • fdo-rendezvous-server
  • fdo-client-linuxapp
  • fdo-owner-onboarding-server

As a result, these services do not run with the unconfined_service_t SELinux label anymore, and run successfully in SELinux enforcing mode.