Chapter 8. Security

This chapter lists the most notable changes to security between RHEL 8 and RHEL 9.

8.1. Security compliance

scap-security-guide does not provide RHEL 9 STIG and CIS profiles

In RHEL 9.0 Beta, the scap-security-guide packages do not contain RHEL 9 versions of the following security profiles:

  • STIG
  • CIS

8.2. Crypto-policies, RHEL core cryptographic components, and protocols

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 SHA-1

In RHEL 9, SHA-1 usage is restricted in the DEFAULT system-wide cryptographic policy. With the exception of HMAC and DNSSec usage, SHA-1 is no longer allowed in TLS, DTLS, SSH, IKEv2 and Kerberos protocols. Individual applications not controlled by crypto policies are also moving away from using SHA-1 hashes in RHEL 9.

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.

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.

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