Enhance security with system-wide crypto policies in RHEL 9

Whether working on open source or closed-source projects, software development teams frequently split into groups that oversee various components. For instance, the group working on database applications can be distinct from the group managing SSH or HTTP services. Usually, each organization chooses its own cryptography suppliers, libraries, languages, and tools. Although this specialization might improve the product's overall quality, it also makes it more difficult to establish a uniform cryptographic policy throughout the system.

This is why it's critical to build up a system with globally applicable cryptographic parameters that have been carefully tested. To guarantee that new components are installed appropriately, setting up a system of this kind in a heterogeneous environment is difficult and requires a thorough grasp of cryptography. Also, the best practices for cryptography change over time, so settings that seem safe now might not be so secure later on. Because of this, IT teams are always under pressure to make sure that all services adhere to industry standards like Payment Card Industry Data Security Standard (PCI-DSS), Defense Information Systems Agency Security Technical Implementation Guide (DISA STIG), or National Institute of Standards and Technology (NIST) recommendations.

Therefore, keeping consistent cryptographic setups is a big task that cannot be delegated to IT departments or end users alone. Before talking about possible fixes, it's critical to understand the dangers posed by incorrect settings or misconfigurations.

Legacy functionalities are frequently kept active as software develops, expanding the attack surface. The fundamental cause of this is the requirement for backward compatibility, which makes configuration settings the primary instrument for vulnerability mitigation. System administrators or end users are usually in charge of these settings. Nevertheless, it is not feasible nor efficient to rely on them to maintain settings updated with the newest cryptographic developments. Updating each application's setup by hand is a difficult and frequently overlooked operation, even in situations when the required knowledge is present.

Why Red Hat Enterprise Linux 9?

Red Hat Enterprise Linux (RHEL) 9 offers a stronger defense against these vulnerabilities because of its system-wide encryption policy, which is excellent news. This policy is enforced uniformly to all services that are currently in operation and is automatically updated with software updates to keep pace with the most recent developments in cryptography.

The strategy is conservative by default, banning antiquated communication methods such as TLS 1.1 and previous versions, thereby reducing a wide range of threats. This guarantees that RHEL-powered systems can adhere to strict guidelines, such as the Payment Card Industry Data Security Standard (PCI-DSS). The policy is also adjustable, so you can customize the parameters to meet your unique requirements. You may tighten the settings for a stricter security posture or loosen them to keep compatibility with legacy systems.

Which policies are supplied with RHEL 9 systems?

The cryptographic policies that are offered are called LEGACY, DEFAULT, FUTURE, and FIPS. Here is a quick summary of each:

• DEFAULT: Providing security settings compliant with modern standards, this policy is advised for the majority of use scenarios. It is compatible with SSH2, IKEv2, and TLS 1.2 and 1.3 protocols. If the Diffie-Hellman and RSA parameters are more than 2048 bits, they are allowed.

• LEGACY: This less secure policy was created to work with older systems. It permits SHA-1 to be used with SSH for CBC-mode ciphers and TLS hashes, signatures, and algorithms. With RSA keys and Diffie-Hellman parameters that are accepted at a minimum length of 2048 bits, it supports TLS 1.2 and 1.3, IKEv2, and SSH2. Certificates signed using SHA-1 can also be accepted by applications that use GnuTLS.

• FUTURE: This policy is more conservative and aims to protect against potential near-term threats. It disallows SHA-1 in DNSSec and HMAC, rejects SHA2-224 and SHA3-224 hashes, and disables 128-bit ciphers. CBC-mode ciphers are also disabled, except in Kerberos. It supports TLS 1.2 and 1.3, IKEv2, and SSH2, but requires RSA keys and Diffie-Hellman parameters to be at least 3072 bits. Note that using this policy may cause interoperability issues on the public internet.

• FIPS: This policy aligns with the FIPS 140 requirements and is managed by the fips-mode-setup tool, which switches the RHEL system into FIPS 140 compliance mode. However, simply switching to this policy does not guarantee FIPS 140 compliance. Additionally, all cryptographic keys must be regenerated after enabling FIPS mode, which may not be feasible in some scenarios.

How to use crypto policies

Crypto policies are centrally managed on the system and can be easily viewed or updated using simple commands. To change the system-wide cryptographic policy, you'll use the update-crypto-policies tool, which requires root privileges.

To display the currently active system-wide crypto policy:

$ update-crypto-policies --show
DEFAULT

To set a new cryptographic policy:

# update-crypto-policies --set <POLICY>
<POLICY>

For example, to set the policy to FUTURE:

$ update-crypto-policies --set FUTURE
Setting system policy to FUTURE

After setting the new policy, restart the system using the reboot command. Once the system reboots, verify the policy change with the --show option as shown earlier. 

It's important to note that predefined policy levels are designed to be general purpose, which means they may not meet specific security requirements. This is where custom crypto policies come into play. Users can add or remove algorithms or protocols from existing policy levels in RHEL 9 custom crypto policies, or they can design whole new crypto policies that are customized to meet their own requirements.

Modifying an existing crypto policy

To modify existing crypto policies, you can use policy modifier modules. These are text files that contain specific instructions for the update-crypto-policies tool. The naming convention for these files is <MODULE>.pmod, where <MODULE> is the name of the modifier in uppercase without spaces, and .pmod is the file extension in lowercase.

These files should be placed in the /etc/crypto-policies/policies/modules directory, or in /usr/share/crypto-policies/policies/modules if they are part of installed packages.

For example, if you want to remove support for CHACHA20-POLY1305 to mitigate CVE-2023-48795 on RHEL-9 systems, you would create a policy modifier module named CVE-2023-48795.pmod with the following lines:

cipher@SSH = -CHACHA20-POLY1305
ssh_etm = 0

Before applying the modifier, you can check the current crypto policy with:

$ update-crypto-policies --show

Output: 

DEFAULT

You can then apply the policy modifier to the existing crypto policy using the following command:

# update-crypto-policies --set DEFAULT:CVE-2023-48795

Output:

Setting system policy to DEFAULT:CVE-2023-48795

To confirm the policy modifier has been applied correctly, check the set crypto policy again using:

$ update-crypto-policies --show

Output:

DEFAULT:CVE-2023-48795

Creating a new policy from scratch

If you have specific requirements, you can create a new crypto policy from scratch. To do this, start by copying an existing policy file, such as the DEFAULT.pol file. You can then edit and rename it to create your new policy.

Ensure that the system-wide crypto policy definition files are owned by the root user and are not writable by non-privileged users, similar to other system-wide configuration files.

Follow the steps below to create and apply your new policy.

1. Copy one of the predefined policy files:

   # cp  /usr/share/crypto-policies/policies/DEFAULT.pol /etc/crypto-policies/policies/MYPOLICY.pol

2. Edit the copied policy file to meet your specific needs:

   # vi  /etc/crypto-policies/policies/MYPOLICY.pol

3. After making the necessary changes, set the new crypto policy:

   # update-crypto-policies --set MYPOLICY

4. Reboot the system to ensure the new crypto policy settings are applied to all running services and applications:

   # reboot

5. After the reboot, confirm that the new crypto policy is active by checking the current policy:

   # update-crypto-policies --show

   Output: 

   MYPOLICY

Conclusion

The scenarios we've covered highlight how RHEL effectively enforces system-wide crypto policies across applications. RHEL 9’s system-wide crypto policies offer exceptional flexibility. Whether you need to build a new policy from the ground up or customize an existing one, these tools allow administrators to fine-tune security settings to match their unique requirements. This adaptability is vital in keeping pace with the constantly changing security landscape. For administrators managing system interoperability, maintaining compatibility with older devices, or upholding compliance standards, RHEL 9’s customizable crypto policies are a powerful solution. They enable you to enforce precise security measures, verifying that only authorized cryptographic algorithms and protocols are in use.

To begin, explore the crypto_policies and security hardening manual page and the RHEL 9 documentation. Feel free to experiment with different configurations, secure in the knowledge that the default system profiles will remain available for easy rollback if needed.