Menu Close

Chapter 10. Security

This chapter lists 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.

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 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)

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.

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.

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

Additionally, 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.

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.

10.3. SELinux

Support for disabling SELinux through /etc/selinux/config has been removed

With this 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.

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.