Red Hat Summit Red Hat SummitSupportConsoleDevelopersStart a trialContact

Chapter 20. Security

The following chapters contain the most notable changes to security between RHEL 9 and RHEL 10.

20.1. Security compliance changes
Copy link

Installation hardening with OSCAP Anaconda Addon removed
The oscap-anaconda-addon package has been removed. As a consequence, the RHEL 10 installer no longer provides the Security Policy spoke and installation hardening. RHEL 10 introduces a more flexible and customizable approach to hardening systems by using Anaconda and Kickstart in addition to the already existing Image Builder option. For more information, see Creating pre-hardened images with RHEL image builder OpenSCAP integration.
OpenSCAP

The new version 1.4.x of the OpenSCAP scanner is provided in RHEL 10. The most important changes are the following:

  • The openscap package no longer provides the openscap-devel subpackage for the libopenscap library, which is now an internal library without public API and any guarantee for backward compatibility. The openscap package is provided with no guarantee of ABI and API compatibility.

  • The following ds submodules that provide data stream composing functions have been removed from the oscap tool:

    • sds-compose
    • sds-add
    • sds-split
    • rds-create
    • rds-split

  • The following incomplete modules have been removed:

    • cve
    • cvss
    • cvrf

  • The following deprecated command-line options have been removed:

    • --template
    • --oval-template
    • --sce-template
    • --skip-valid is removed and is replaced by --skip-validation
  • New Kickstart remediation type was added.
  • The autotailor tool now can produce XCCDF tailoring files based on JSON Tailoring.
SCAP Workbench
The scap-workbench package with the SCAP Workbench GUI utility has been removed. As alternatives, you can use the oscap and autotailor command-line tools or Red Hat Lightspeed for both tailoring and scanning. For more information, see Managing SCAP security policies in the Red Hat Lightspeed compliance service.
SCAP Security Guide

The scap-security-guide package does not contain the following profiles:

  • Protection Profile for General Purpose Operating Systems (OSPP)
  • Centro Criptológico Nacional (CCN) - Basic
  • Centro Criptológico Nacional (CCN) - Intermediate

For the complete list of profiles supported in RHEL 10, see SCAP security profiles supported in RHEL 10.

20.2. Changes to cryptographic components
Copy link

ca-certificates truststore moved
The /etc/pki/tls/certs truststore is converted to a different format better optimized for OpenSSL. As a consequence, if you use the files in /etc/pki/tls/certs directly, switch to the /etc/pki/ca-trust/extracted directory, where the same data is stored. For example, software that accesses the trust bundle at /etc/pki/tls/certs/ca-bundle.crt should switch to using /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem instead.
fips-mode-setup is removed
The fips-mode-setup command is removed from RHEL. To enable the cryptographic module self-checks mandated by the Federal Information Processing Standard (FIPS) 140, enable FIPS mode during the system installation. See the Switching RHEL to FIPS mode chapter in the Security hardening document for more information.
/etc/system-fips removed
Support for indicating FIPS mode through the /etc/system-fips file has been removed from RHEL. To install RHEL in FIPS mode, add the fips=1 parameter to the kernel command line during the system installation. You can check whether RHEL operates in FIPS mode by displaying the /proc/sys/crypto/fips_enabled file.
compat-openssl11 is removed
The compatibility library for OpenSSL 1.1, compat-openssl11, has been removed from RHEL 10. OpenSSL 1.1 is no longer maintained upstream and applications that use the OpenSSL TLS toolkit should be migrated to version 3.x.
pkcs11-provider replaces openssl-pkcs11
As a part of the migration from OpenSSL engines to the Providers API, the pkcs11-provider package replaces the openssl-pkcs11 package (engine_pkcs11). The openssl-pkcs11 package is removed from RHEL 10.
DEFAULT cryptographic policy rejects TLS ciphers with RSA key exchange

TLS ciphers that use the RSA key exchange are no longer accepted in the DEFAULT system-wide cryptographic policy in RHEL 10. These ciphers do not provide perfect forward secrecy and are not considered as secure as ciphers that use other key exchanges, for example, the Elliptic-curve Diffie-Hellman (ECDH) key exchange.

This change also reduces the exposure to side-channel attacks because the RSA key exchange uses PKCS #1 v1.5 encryption padding, which can cause vulnerability to timing side-channel attacks.

If you need the RSA key exchange for interoperability with legacy systems, you can re-enable it by using the LEGACY system-wide cryptographic policy or by applying a custom subpolicy.

The LEGACY cryptographic policy disallows SHA-1 signatures in TLS
The LEGACY system-wide cryptographic policy in RHEL 10 no longer allows creating or verifying signatures that use SHA-1 in TLS contexts. Therefore, libraries other than OpenSSL might no longer accept or create any signatures that use SHA-1 regardless of use case. OpenSSL continues to accept signatures that use SHA-1 when not used for TLS if the system is in LEGACY or this functionality is re-enabled with a custom subpolicy.
SHA1 subpolicy removed
The SHA1 subpolicy that allowed to use the SHA-1 algorithm for creating and verifying signatures in the DEFAULT system-wide cryptographic policy after entering the update-crypto-policies --set DEFAULT:SHA1 command is no longer available in RHEL 10.
OpenSSL no longer permits SHA-1 at SECLEVEL=2 in TLS
OpenSSL does not accept the SHA-1 algorithm at SECLEVEL=2 in TLS in RHEL 10. If your scenario requires using TLS 1.0 or 1.1, you must explicitly set SECLEVEL=0 and switch to the LEGACY system-wide cryptographic policy. In the LEGACY policy, applications that use SHA-1 in signatures outside of TLS will continue to work.
OpenSSL cipher suites no longer enable cipher suites with disabled hashes or MACs
Previously, applying custom cryptographic policies could leave certain TLS 1.3 cipher suites enabled even if their hashes or MACs were disabled, because the OpenSSL TLS 1.3-specific Ciphersuites option values were controlled only by the ciphers option of the cryptographic policy. With this update, crypto-policies takes more algorithms into account when deciding whether to enable a cipher suite. As a result, OpenSSL on systems with custom cryptographic policies might refuse to negotiate some of the previously enabled TLS 1.3 cipher suites in better accordance with the system configuration.
OpenSSL FIPS indicators are subject to change during the RHEL 10 lifetime
Because RHEL introduced OpenSSL FIPS indicators before the OpenSSL upstream did, and both designs differ, the indicators may change in a future minor version of RHEL 10. After the potential adoption of the upstream API, the RHEL 10.0 indicators might return an error message "unsupported" instead of a result. See the OpenSSL FIPS Indicators GitHub document for details.
OpenSSL 3.5 uses standard format for ML-KEM and ML-DSA

In RHEL 10.0, the oqsprovider library used a pre-standard format for the Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM) and the Module-Lattice-Based Digital Signature Algorithm (ML-DSA) private keys. With the rebase to OpenSSL 3.5, you must convert the ML-KEM and ML-DSA keys to the standard format by using the following command: 

# openssl pkcs8 -in <old_private_key> -nocrypt -topk8 -out <standard_private_key>
Copy to Clipboard Toggle word wrap

Replace <old_private_key> with the path to the non-standard private key, and <standard_private_key> with the path where the standard key will be saved.

Switching to LEGACY policy does not enable support for SHA-1 in TLS connections

You can control support for SHA-1 signatures either by the @SECLEVEL setting specified in the default cipher string or the rh-allow-sha1-signatures property. Support for SHA-1 in the TLS context is enabled by setting @SECLEVEL=0. However, this setting also allows other insecure algorithms.

You can override the SECLEVEL setting by specifying the rh-allow-sha1-signatures property in the evp_properties section. By default and when unspecified in the configuration file, evp_properties is set to no. The system-wide cryptographic policies set the property to yes after you switch to the LEGACY policy.

Therefore, to enable support for SHA-1 in contexts outside TLS, you can switch the system to the LEGACY cryptographic policy. To enable SHA-1 in TLS, you must switch the system to LEGACY and use a cipher string that sets @SECLEVEL=0 either by defining a custom cryptographic policy or setting this for your application in OpenSSL.

Stricter SSH host key permissions have been restored
The necessary host key permissions have been changed from the previous less strict value of 0640 to 0600, which is also the value used upstream. The ssh_keys group, which previously owned all SSH keys, has also been removed. Therefore, the ssh-keysign utility uses the SUID bit instead of the SGID bit.
crypto-policies now set allow-rsa-pkcs1-encrypt = false for GnuTLS
In RHEL 10, the GnuTLS library blocks encryption and decryption with the RSA PKCS #1 v1.5 padding by default. Except for the LEGACY policy, the allow-rsa-pkcs1-encrypt = false option is specified in all system-wide cryptographic policies (DEFAULT, FUTURE, and FIPS).

20.3. Changes to SELinux
Copy link

SELinux policy modules related to EPEL packages moved to -extra subpackages in the CRB repository

In RHEL 10.0, the SELinux policy modules related only to packages contained in the Extra Packages for Enterprise Linux (EPEL) repository and not to any RHEL package were moved from the selinux-policy package to the selinux-policy-epel package. This reduced the size of selinux-policy, allowing the system to perform operations such as rebuilding and loading the SELinux policy faster.

In RHEL 10.1, the modules from selinux-policy-epel are moved to the following -extra subpackages in the RHEL CodeReady Linux Builder (CRB) repository:

  • selinux-policy-targeted-extra
  • selinux-policy-mls-extra

This change enables the automatic installation of -extra SELinux policy modules when users enable the EPEL repository.

rpm -ql returns incorrect location of the selinux-policy packages on RHEL in image mode
The rpm -ql command lists non-existent locations of the selinux-policy and selinux-policy-targeted when used on RHEL in image mode. The policy modules are installed in the /etc/selinux/targeted instead of /var/lib/selinux/targeted directory, as misleadingly reported by rpm. This discrepancy is expected because most file systems in image mode are read-only, and the RPM tool doesn’t have the actual location of installed packages.
Back to top
Red Hat logoGithubredditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust. Explore our recent updates.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

Theme

© 2026 Red Hat