How RHEL 10.2 Quietly Turned Into an Absolute Security Beast

Posted on October 2, 2026

I spent the past week getting my hands dirty with the new Red Hat Enterprise Linux 10.2 build on my test lab, and the engineering crew went all out on security this time. From post-quantum crypto built to stop future supercomputers in their tracks to clever process isolation that plugs kernel lockups, there is heaps going on under the hood. By the end of this read, you will understand every major defense upgrade Red Hat packed into this release and how to wire them into your own servers.

Hai, my name is Luthfi Emka, I’m a linux enthusiast from Indonesia. And here’s my take on RHEL 10.2 security.

Future-proofing SSH and crypto before quantum rigs arrive

If you reckon quantum threats are science fiction for the next generation, security architects disagree. RHEL 10.2 drops significant post-quantum cryptography (PQC) upgrades so an attacker cannot capture your encrypted streams today and decrypt them years later on a quantum box.

The core openssh packages now support post-quantum key exchange using the Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM) paired with NIST-standardized elliptic curves in FIPS mode (Jira:RHEL-70824, Jira:RHEL-125929). Specifically, you get the mlkem768nistp256-sha256 and mlkem1024nistp384-sha384 algorithms. These let you negotiate connections with hybrid protection that pairs classical elliptic curves with lattice cryptography. The system-wide crypto-policies package activates both hybrid methods by default in FIPS mode, meaning two communicating RHEL 10.2 endpoints automatically negotiate quantum resistance if both support it (Jira:RHEL-148560).

The libssh library steps up to upstream version 0.12.0, introducing post-quantum traditional (PQ/T) hybrid key exchanges defined in the IETF draft-ietf-sshm-mlkem-hybrid-kex document (Jira:RHEL-70825, Jira:RHEL-133421). The library adds support for:

  • mlkem768nistp256-sha256
  • mlkem768x25519-sha256
  • mlkem1024nistp384-sha384
  • sntrup761x25519-sha512
  • sntrup761x25519-sha512@openssh.com

Among these, mlkem768x25519-sha256 is enabled across all predefined cryptographic policies and acts as the top-priority default key exchange method (Jira:RHEL-125889, Jira:RHEL-133522). Beyond post-quantum math, the 0.12.0 update to libssh incorporates GSSAPI key exchange per RFC 4462 and RFC 8732, Ed25519 keys via PKCS #11, and OpenSSH-compatible FIDO Universal 2nd Factor (U2F) keys. You also get new configuration options like RequiredRsaSize, client-side AddressFamily, GSSAPIKeyExchange, and GSSAPIKexAlgorithms. The library bumps its minimum RSA key size to 1024 bits, provides APIs to sign arbitrary data with SSH keys, stabilizes the ProxyJump directive, expands OpenSSH-compatible percent expansion characters, adds functions to list configured identities, and introduces a dedicated PKI context structure for cryptographic operations.

Container image integrity catches the quantum wave too. The podman-sequoia library introduces composite post-quantum signatures via ML-DSA-65+Ed25519 and ML-DSA-87+Ed448, satisfying Commercial National Security Algorithm Suite (CNSA) 2.0 standards for software verification (Jira:RHEL-126677[1]). Supplying the plumbing for this is the capnproto package, rebased to version 1.3 and made directly available in the CodeReady Builder (CRB) repository (Jira:RHEL-114452[1], Jira:RHEL-127899). The rust-sequoia-sq and rust-sequoia-podman tools use the zero-copy serialization and RPC mechanics of capnproto to talk to the Sequoia Keystore, running private keys in a detached process to safeguard memory during bulk signing operations.

Finally, p11-kit jumps to upstream 0.26.1 (Jira:RHEL-139074[1]). Its PKCS #11 headers reach version 3.2 to include post-quantum definitions. The update fixes RDNSequence DN lookups per RFC 4514, adds a module setting to define server addresses over RPC, repairs empty array handling in RPC routines, and eliminates its dependency on libsystemd for socket activation. To keep container builds trim, the p11-kit-client.so module has been split from p11-kit-server into its own p11-kit-client subpackage, preventing server bloat on client-only setups (Jira:RHEL-89706).

Locking down daemons and storage with SELinux

SELinux in RHEL 10.2 received a massive rework that changes how critical daemons execute on the host.

OpenSSH moves away from its historic monolithic architecture. The single sshd daemon is split into dedicated binaries: /usr/libexec/openssh/sshd-session handles per-session logic, while /usr/libexec/openssh/sshd-auth isolates the authentication phase (Jira:RHEL-107732). By shifting pre-authentication code into an isolated address space, a vulnerability hit before login cannot compromise the listening daemon. The SELinux policy adds exact security contexts and process transitions for these binaries, enforcing least privilege while keeping PAM authentication and host key protection running smoothly.

Unconfined system background services also get brought to heel:

  • The redfish-finder systemd service drops the unconfined_service_t attribute, locking down the daemon to meet CIS Server Level 2 benchmark requirements (Jira:RHEL-50299[1]).
  • The systemd-oomd out-of-memory daemon is confined away from unconfined_service_t, also ensuring compliance with the CIS Server Level 2 standard (Jira:RHEL-106998[1]).
  • Six domains finished their evaluation period and shifted from permissive to full enforcing mode: anaconda_generator_t, ktlshd_t, switcheroo_control_t, systemd_pcrextend_t, systemd_user_runtimedir_t, and tuned_ppd_t (Jira:RHEL-107038[1]).

Day-to-day administration commands received quality improvements. The restorecon utility features a new -c option that prints out the number of relabeled files and exits with code 0 only when at least one file label was altered (Jira:RHEL-94827). When handling massive storage pools, the setfiles utility adds the -A option (Jira:RHEL-111505). This flag disables conflict tracking between hard-linked index nodes, preventing the utility from chewing up all your memory on constrained systems.

For auditing your access vectors, setools moves up to 4.6.0 (Jira:RHEL-115363). You can view the roles permitted for any type by using seinfo --role_types, confirm that kernel modules remain read-only using a new sechecker module, inspect extended nlmsg socket permissions, and ditch deprecated APIs.

Device nodes and filesystem paths received policy updates as well. Dedicated SELinux labels now attach to /dev/papr-indices, /dev/papr-physical-attestation, and /dev/papr-platform-dump, matching new kernel character interfaces for the Power Architecture Platform Reference (PAPR) ABI (Jira:RHEL-129839). Heads up for image-mode and OSTree deployments: the SELinux policy introduces an equivalency rule that maps /var/opt directly to /opt (Jira:RHEL-116512[1]). Subdirectories like /var/opt/app automatically pick up contexts from /opt/app. This mapping overrides custom rules on upgraded systems, so check your custom policies if you see label issues.

Boot integrity, remote attestation, and disk locks

Securing bare-metal and edge platforms means proving your operating system has not been modified before you release sensitive decryption keys.

A fresh package named clevis-pin-trustee makes its debut in RHEL 10.2 (Jira:RHEL-139808[1]). It automates the encryption and decryption of LUKS-encrypted drives via remote attestation through the Trustee Key Broker Service (KBS). In confidential computing environments like OpenShift confidential clusters or OpenShift Virtualization, the Trustee server functions as an external policy enforcement checkpoint. It withholds drive keys until the machine provides hardware attestation measurements that validate against trusted values.

The trustee pin ties into the standard Clevis toolset through clevis-encrypt-trustee and clevis-decrypt-trustee, and includes a Dracut module named 60clevis-pin-trustee to unlock root volumes early in the boot cycle. You bind storage to your attestation servers using this command:

clevis luks bind -d <device> trustee '<config>'

You can also stack the trustee pin with existing pins like tang and tpm2 to create multi-factor unlock requirements across your fleet.

Hardware attestation via Keylime has been modernized as well. The parent Keylime packages rebase to 7.14.1 (Jira:RHEL-140896). This release fixes a file descriptor leak in keylime-policy when parsing remote RPM repositories, resolves default value handling on the keylime-policy --ima-measurement-list option, adds support for direct TPM ECC keys using NIST curves P-192, P-224, P-256, P-384, and P-521, and introduces an agent-driven push model.

The companion keylime-agent package hits upstream version 0.2.9 with the following enhancements (Jira:RHEL-140897):

  1. The agent-driven push attestation model allows nodes to initiate outbound communication to the verifier, removing the need to punch open inbound ports through firewalls or fight network address translation (NAT).
  2. Hardware cryptography supports TPM-generated ECC keys across NIST curves P-192, P-224, P-256, P-384, and P-521.
  3. RSA operations on the TPM gain flexible key size support for 1024, 2048, 3072, and 4096-bit keys to match organizational policies.
  4. Communications between agents and Keylime verifiers can now use TLS certificates signed with modern ECC keys.

Application allowlisting, OpenSSH controls, and container stripping

The remaining updates fine-tune application control, container image sizes, and system auditing baselines.

The fapolicyd file access monitoring daemon moves to upstream version 1.4.3 (Jira:RHEL-118362). New additions include the --filter flag for fapolicyd-cli --file, the --test-filter command on fapolicy-cli for dry-testing rule sets, the --check-ignore_mounts option (and its accompanying --verbose flag), and a dedicated fapolicyd-filter.conf(5) man page. System overhead drops thanks to larger subject caches, increased database size limits, and support for db_max_size = auto. The fapolicyd-rpm-loader helper has also been relocated to /bin.

Underneath, the companion fapolicyd-selinux package adds a targeted SELinux module (Jira:RHEL-1368). This module blocks users from sending SIGSTOP signals to fapolicyd or tracing the process using ptrace(), stopping malicious signal disruptions that used to freeze the operating system and force hard reboots.

OpenSSH configuration gets tighter control through two directives inside /etc/ssh/sshd_config:

  • You can now explicitly set GSSAPIDelegatedCredentials to no (Jira:RHEL-5281). The default remains yes for legacy setups, but setting it to no stops the server from forwarding Kerberos credentials.
  • The new CanonicalMatchUser directive alters how Match User blocks evaluate accounts (Jira:RHEL-101440[1]). The daemon queries the password database for the authenticating username before evaluating aliases, preventing Active Directory users with capitalized letters in their usernames from slipping out of chroot restrictions and escalating privileges.
  • OpenSSH in FIPS mode relaxes its GSSAPI key exchange rules, permitting the Diffie-Hellman and Elliptic Curve Diffie-Hellman groups gss-group14-sha256, gss-group16-sha512, and gss-nistp256-sha256, while also allowing non-cryptographic usage of MD5 (Jira:RHEL-91181).

Container footprints shrink through the introduction of the libreswan-minimal subpackage (Jira:RHEL-5299). By removing dependencies on systemd and optional external utilities, you can spin up IPsec tunnels inside minimal container images that start faster and draw fewer memory resources.

Finishing off the release, system compliance auditing gets updated with OpenSCAP moving to upstream 1.4.3 (Jira:RHEL-133978) and the SCAP Security Guide rebasing to version 0.1.80 (Jira:RHEL-152059).

Getting across these updates takes a minute, but the extra protection against both current exploits and future quantum threats is well worth the effort. Are you planning to roll out the new post-quantum SSH key exchanges on your servers straight away, or are you holding off for your next hardware cycle? Drop your thoughts in the comments!