Este conteúdo não está disponível no idioma selecionado.
Chapter 8. Applying security policies
During the in-place upgrade process, the SELinux policy must be switched to permissive mode. Furthermore, security profiles might contain changes between major releases. To restore system security, switch SELinux to enforcing mode again and verify the system-wide cryptographic policy. You may also want to remediate the system to be compliant with a specific security profile. Also, some security-related components require pre-update steps for a correct upgrade.
8.1. Changing SELinux mode to enforcing
During the in-place upgrade process, the Leapp
utility sets SELinux mode to permissive. When the system is successfully upgraded, you have to manually change SELinux mode to enforcing.
Prerequisites
- The system has been upgraded and you have performed the Verification described in Verifying the post-upgrade state.
Procedure
Ensure that there are no SELinux denials, for example, by using the
ausearch
utility:# ausearch -m AVC,USER_AVC -ts boot
Note that the previous step covers only the most common scenario. To check for all possible SELinux denials, see the Identifying SELinux denials section in the Using SELinux title, which provides a complete procedure.
Open the
/etc/selinux/config
file in a text editor of your choice, for example:# vi /etc/selinux/config
Configure the
SELINUX=enforcing
option:# This file controls the state of SELinux on the system. # SELINUX= can take one of these three values: # enforcing - SELinux security policy is enforced. # permissive - SELinux prints warnings instead of enforcing. # disabled - No SELinux policy is loaded. SELINUX=enforcing # SELINUXTYPE= can take one of these two values: # targeted - Targeted processes are protected, # mls - Multi Level Security protection. SELINUXTYPE=targeted
Save the change, and restart the system:
# reboot
Verification
After the system restarts, confirm that the
getenforce
command returnsEnforcing
:$ getenforce Enforcing
Additional resources
8.2. System-wide cryptographic policies
The system-wide cryptographic policies is a system component that configures the core cryptographic subsystems, covering the TLS, IPSec, SSH, DNSSec, and Kerberos protocols.
The in-place upgrade process preserves the cryptographic policy you used in RHEL 8. For example, if you used the DEFAULT
cryptographic policy in RHEL 8, your system upgraded to RHEL 9 also uses DEFAULT
. Note that specific settings in predefined policies differ, and RHEL 9 cryptographic policies contain more strict and more secure default values. For example, the RHEL 9 DEFAULT
cryptographic policy restricts SHA-1 usage for signatures and the LEGACY
policy no longer allows DH and RSA ciphers with less than 2048 bits. See the Using system-wide cryptographic policies section in the Security hardening document for more information. Custom cryptographic policies are preserved across the in-place upgrade.
To view or change the current system-wide cryptographic policy, use the update-crypto-policies tool:
$ update-crypto-policies --show
DEFAULT
For example, the following command switches the system-wide crypto policy level to FUTURE
, which should withstand any near-term future attacks:
# update-crypto-policies --set FUTURE
Setting system policy to FUTURE
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. However, LEGACY
also enables many other algorithms that are not secure.
Enabling the SHA
subpolicy makes your system more vulnerable than the default RHEL 9 settings. Switching to the LEGACY
policy is even less secure, and you should use it with caution.
You can also customize system-wide cryptographic policies. For details, see the Customizing system-wide cryptographic policies with subpolicies and Creating and setting a custom system-wide cryptographic policy sections. If you use a custom cryptographic policy, consider reviewing and updating the policy to mitigate threats brought by advances in cryptography and computer hardware.
Additional resources
- Using system-wide cryptographic policies
-
update-crypto-policies(8)
man page
8.3. Upgrading a system hardened to a security baseline
To get a fully hardened system after a successful upgrade to RHEL 9, you can use automated remediation provided by the OpenSCAP suite. OpenSCAP remediations align your system with security baselines, such as PCI-DSS, OSPP, or ACSC Essential Eight. The configuration compliance recommendations differ among major versions of RHEL due to the evolution of the security offering.
When upgrading a hardened RHEL 8 system, the Leapp tool does not provide direct means to retain the full hardening. Depending on the changes in the component configuration, the system might diverge from the recommendations for the RHEL 9 during the upgrade.
You cannot use the same SCAP content for scanning RHEL 8 and RHEL 9. Update the management platforms if the compliance of the system is managed by tools such as Red Hat Satellite or Red Hat Insights.
As an alternative to automated remediations, you can make the changes manually by following an OpenSCAP-generated report. For information about generating a compliance report, see Scanning the system for security compliance and vulnerabilities.
Automated remediations support RHEL systems in the default configuration. Because the system configuration has been altered after the upgrade, running automated remediations might not make the system fully compliant with the required security profile. You might need to fix some requirements manually.
The following example procedure hardens your system settings according to the PCI-DSS profile.
Prerequisites
-
The
scap-security-guide
package is installed on your RHEL 9 system.
Procedure
Find the appropriate security compliance data stream
.xml
file:$ ls /usr/share/xml/scap/ssg/content/ ... ssg-rhel9-ds.xml ...
See the Viewing compliance profiles section for more information.
Remediate the system according to the selected profile from the appropriate data stream:
# oscap xccdf eval --profile pci-dss --remediate /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml
You can replace the
pci-dss
value in the--profile
argument with the ID of the profile according to which you want to harden your system. For a full list of profiles supported in RHEL 9, see SCAP security profiles supported in RHEL.WarningIf not used carefully, running the system evaluation with the
--remediate
option enabled might render the system non-functional. Red Hat does not provide any automated method to revert changes made by security-hardening remediations. Remediations are supported on RHEL systems in the default configuration. If your system has been altered after the installation, running remediation might not make it compliant with the required security profile.Restart your system:
# reboot
Verification
Verify that the system is compliant with the profile, and save the results in an HTML file:
$ oscap xccdf eval --report pcidss_report.html --profile pci-dss /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml
Additional resources
-
scap-security-guide(8)
andoscap(8)
man pages - Scanning the system for security compliance and vulnerabilities
- Red Hat Insights Security Policy
- Red Hat Satellite Security Policy
8.4. Verifying USBGuard policies
With the USBGuard software framework, you can protect your systems against intrusive USB devices by using lists of permitted and forbidden devices based on the USB device authorization feature in the kernel.
Prerequisites
- You have created a rule set for USB devices that reflected the requirements of your scenario before the upgrade.
-
The
usbguard
service is installed and running on your RHEL 9 system.
Procedure
-
Back up your *.conf files stored in the
/etc/usbguard/
directory. -
Use the
usbguard generate-policy
to generate a new policy file. Note that the command generates rules for the currently present USB devices only. Compare the newly generated rules against the rules in the previous policy:
- If you identify differences in the rules for the devices that were present when you generated the new policy and the pre-upgrade rules for the same devices, modify the original rules correspondingly also for devices that might be inserted later.
- If there are no differences between the newly generated and the pre-upgrade rules, you can use the policy files created in RHEL 8 without any modification.
Additional resources
8.5. Updating fapolicyd databases
The fapolicyd
software framework controls the execution of applications based on a user-defined policy.
In rare cases, a problem with the fapolicyd
trust database format can occur. To rebuild the database:
Stop the service:
# systemctl stop fapolicyd
Delete the database:
# fapolicyd-cli --delete-db
Start the service:
# systemctl start fapolicyd
If you added custom trust files to the trust database, update them either individually by using the fapolicyd-cli -f update <FILE>
command or altogether by using fapolicyd-cli -f update
. To apply the changes, use either the fapolicyd-cli --update
command or restart the fapolicyd
service.
Additionally, custom binaries might require a rebuild for the new RHEL version. Perform any such updates before you update the fapolicyd database.
Additional resources
8.6. Updating NSS databases from DBM to SQLite
Many applications automatically convert the NSS database format from DBM to SQLite after you set the NSS_DEFAULT_DB_TYPE
environment variable to the sql
value on the system. You can ensure that all databases are converted by using the certutil
tool.
Convert your NSS databases stored in the DBM format before you upgrade to RHEL 9. In other words, perform the following steps on RHEL systems (6, 7, and 8) from which you want to upgrade to RHEL 9.
Prerequisites
-
The
nss-tools
package is installed on your system.
Procedure
Set
NSS_DEFAULT_DB_TYPE
tosql
on the system:# export NSS_DEFAULT_DB_TYPE=sql
Use the conversion command in every directory[1] that contains NSS database files in the DBM format, for example:
# certutil -K -X -d /etc/ipsec.d/
Note that you have to provide a password or a path to a password file as a value of the
-f
option if your database file is password-protected, for example:# certutil -K -X -f /etc/ipsec.d/nsspassword -d /etc/ipsec.d/
Additional resources
-
certutil(1)
man page.
8.7. Migrating Cyrus SASL databases from the Berkeley DB format to GDBM
The RHEL 9 cyrus-sasl
package is built without the libdb
dependency, and the sasldb
plugin uses the GDBM database format instead of Berkeley DB.
Prerequisites
-
The
cyrus-sasl-lib
package is installed on your system.
Procedure
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>
Additional resources
-
cyrusbdb2current(1)
man page
/etc/pki/nssdb
directory. Other locations depend on applications you use. For example, Libreswan stores its database in the /etc/ipsec.d/
directory and Firefox uses the /home/<username>/.mozilla/firefox/
directory.