8.6. Sécurité
OpenSSL ne détecte pas si un jeton PKCS #11 prend en charge la création de signatures RSA ou RSA-PSS brutes
Le protocole TLS 1.3 nécessite la prise en charge des signatures RSA-PSS. Si un jeton PKCS #11 ne prend pas en charge les signatures RSA ou RSA-PSS brutes, les applications serveur qui utilisent la bibliothèque OpenSSL ne fonctionnent pas avec une clé RSA si la clé est détenue par le jeton PKCS #11. Par conséquent, la communication TLS échoue dans le scénario décrit.
Pour contourner ce problème, configurez les serveurs et les clients de manière à ce qu'ils utilisent la version 1.2 du protocole TLS, qui est la version la plus élevée disponible.
(BZ#1681178)
OpenSSL traite incorrectement les jetons PKCS #11 qui ne prennent pas en charge les signatures RSA ou RSA-PSS brutes
La bibliothèque OpenSSL ne détecte pas les capacités liées aux clés des jetons PKCS #11. Par conséquent, l'établissement d'une connexion TLS échoue lorsqu'une signature est créée avec un jeton qui ne prend pas en charge les signatures RSA ou RSA-PSS brutes.
Pour contourner le problème, ajoutez les lignes suivantes après la ligne .include à la fin de la section crypto_policy dans le fichier /etc/pki/tls/openssl.cnf:
SignatureAlgorithms = RSA+SHA256:RSA+SHA512:RSA+SHA384:ECDSA+SHA256:ECDSA+SHA512:ECDSA+SHA384 MaxProtocol = TLSv1.2
Par conséquent, une connexion TLS peut être établie dans le scénario décrit.
(BZ#1685470)
La cryptographie non approuvée par la FIPS fonctionne dans OpenSSL en mode FIPS
La cryptographie qui n'est pas approuvée par le FIPS fonctionne dans la boîte à outils OpenSSL, quels que soient les paramètres du système. Par conséquent, vous pouvez utiliser des algorithmes cryptographiques qui devraient être désactivés lorsque le système fonctionne en mode FIPS, par exemple :
- Les suites de chiffrement TLS utilisant l'échange de clés RSA fonctionnent.
- Les algorithmes de cryptage et de décryptage à clé publique basés sur la technologie RSA fonctionnent malgré l'utilisation des blocs PKCS #1 et SSLv23 ou l'utilisation de clés de moins de 2048 bits.
OpenSSL ne peut pas utiliser de moteurs en mode FIPS
L'API Engine est obsolète dans OpenSSL 3.0 et est incompatible avec l'implémentation FIPS (Federal Information Processing Standards) d'OpenSSL et d'autres implémentations compatibles FIPS. Par conséquent, OpenSSL ne peut pas exécuter les moteurs en mode FIPS. Il n'existe pas de solution à ce problème.
Les suites de chiffrement PSK ne fonctionnent pas avec la politique cryptographique FUTURE
Les suites de chiffrement à clé pré-partagée (PSK) ne sont pas reconnues comme des méthodes d'échange de clés à secret parfait (PFS). Par conséquent, les ciphersuites ECDHE-PSK et DHE-PSK ne fonctionnent pas avec OpenSSL configuré à SECLEVEL=3, par exemple avec la politique cryptographique FUTURE. Comme solution de contournement, vous pouvez définir une politique cryptographique moins restrictive ou un niveau de sécurité inférieur (SECLEVEL) pour les applications qui utilisent des suites de chiffrement PSK.
GnuPG permet incorrectement d'utiliser des signatures SHA-1 même si cela est interdit par la norme crypto-policies
Le logiciel cryptographique GNU Privacy Guard (GnuPG) peut créer et vérifier des signatures qui utilisent l'algorithme SHA-1 indépendamment des paramètres définis par les politiques cryptographiques du système. Par conséquent, vous pouvez utiliser SHA-1 à des fins cryptographiques dans la politique cryptographique DEFAULT, ce qui n'est pas cohérent avec la dépréciation de cet algorithme peu sûr pour les signatures à l'échelle du système.
Pour contourner ce problème, n'utilisez pas les options de GnuPG qui impliquent SHA-1. Vous empêcherez ainsi GnuPG d'abaisser la sécurité du système par défaut en utilisant les signatures SHA-1 non sécurisées.
Certaines opérations d'OpenSSH n'utilisent pas les interfaces approuvées par le FIPS
La bibliothèque cryptographique OpenSSL, utilisée par OpenSSH, fournit deux interfaces : l'ancienne et la nouvelle. En raison des modifications apportées aux composants internes d'OpenSSL, seules les interfaces modernes utilisent des implémentations d'algorithmes cryptographiques certifiées FIPS. Comme OpenSSH utilise des interfaces anciennes pour certaines opérations, il n'est pas conforme aux exigences de la FIPS.
gpg-agent ne fonctionne pas comme agent SSH en mode FIPS
L'outil gpg-agent crée des empreintes MD5 lors de l'ajout de clés au programme ssh-agent, même si le mode FIPS désactive le condensé MD5. Par conséquent, l'utilitaire ssh-add ne parvient pas à ajouter les clés à l'agent d'authentification.
Pour contourner le problème, créez le fichier ~/.gnupg/sshcontrol sans utiliser la commande gpg-agent --daemon --enable-ssh-support. Par exemple, vous pouvez coller la sortie de la commande gpg --list-keys au format <FINGERPRINT> 0 dans ~/.gnupg/sshcontrol. Ainsi, gpg-agent fonctionne comme agent d'authentification SSH.
SELinux staff_u Les utilisateurs peuvent passer à tort à l'option unconfined_r
Lorsque le booléen secure_mode est activé, les utilisateurs de staff_u peuvent passer par erreur au rôle unconfined_r. En conséquence, les utilisateurs de staff_u peuvent effectuer des opérations privilégiées affectant la sécurité du système.
La politique SELinux par défaut autorise les exécutables non confinés à rendre leur pile exécutable
L'état par défaut du booléen selinuxuser_execstack dans la politique SELinux est activé, ce qui signifie que les exécutables non confinés peuvent rendre leur pile exécutable. Les exécutables ne devraient pas utiliser cette option, qui pourrait indiquer des exécutables mal codés ou une attaque possible. Cependant, en raison de la compatibilité avec d'autres outils, paquetages et produits tiers, Red Hat ne peut pas modifier la valeur du booléen dans la stratégie par défaut. Si votre scénario ne dépend pas de ces aspects de compatibilité, vous pouvez désactiver l'option booléenne dans votre politique locale en entrant la commande setsebool -P selinuxuser_execstack off.
Les règles de délai SSH dans les profils STIG configurent des options incorrectes
Une mise à jour d'OpenSSH a affecté les règles des profils suivants du Guide de mise en œuvre technique de la sécurité de l'Agence des systèmes d'information de la défense (DISA STIG) :
-
DISA STIG pour RHEL 9 (
xccdf_org.ssgproject.content_profile_stig) -
DISA STIG avec GUI pour RHEL 9 (
xccdf_org.ssgproject.content_profile_stig_gui)
Dans chacun de ces profils, les deux règles suivantes sont affectées :
Title: Set SSH Client Alive Count Max to zero CCE Identifier: CCE-90271-8 Rule ID: xccdf_org.ssgproject.content_rule_sshd_set_keepalive_0 Title: Set SSH Idle Timeout Interval CCE Identifier: CCE-90811-1 Rule ID: xccdf_org.ssgproject.content_rule_sshd_set_idle_timeout
Lorsqu'elles sont appliquées aux serveurs SSH, chacune de ces règles configure une option (ClientAliveCountMax et ClientAliveInterval) qui ne se comporte plus comme auparavant. En conséquence, OpenSSH ne déconnecte plus les utilisateurs SSH inactifs lorsqu'il atteint le délai configuré par ces règles. Comme solution de contournement, ces règles ont été temporairement supprimées des profils DISA STIG pour RHEL 9 et DISA STIG avec GUI pour RHEL 9 jusqu'à ce qu'une solution soit développée.
fagenrules --load ne fonctionne pas correctement
Le service fapolicyd ne gère pas correctement le signal de raccrochage (SIGHUP). Par conséquent, fapolicyd se termine après avoir reçu le signal SIGHUP. Par conséquent, la commande fagenrules --load ne fonctionne pas correctement et les mises à jour des règles nécessitent un redémarrage manuel de fapolicyd. Pour contourner ce problème, redémarrez le service fapolicyd après toute modification des règles, ce qui permettra à fagenrules --load de fonctionner correctement.
Les remédiations Ansible nécessitent des collectes supplémentaires
Avec le remplacement d'Ansible Engine par le paquetage ansible-core, la liste des modules Ansible fournis avec l'abonnement RHEL est réduite. Par conséquent, l'exécution de remédiations qui utilisent le contenu Ansible inclus dans le paquetage scap-security-guide nécessite des collections du paquetage rhc-worker-playbook.
Pour une remédiation Ansible, effectuez les étapes suivantes :
Installez les paquets nécessaires :
# dnf install -y ansible-core scap-security-guide rhc-worker-playbook
-
Naviguez jusqu'au répertoire
/usr/share/scap-security-guide/ansible: # cd /usr/share/scap-security-guide/ansible Exécutez le playbook Ansible approprié en utilisant les variables d'environnement qui définissent le chemin d'accès aux collections Ansible supplémentaires :
# ANSIBLE_COLLECTIONS_PATH=/usr/share/rhc-worker-playbook/ansible/collections/ansible_collections/ ansible-playbook -c local -i localhost, rhel9-playbook-cis_server_l1.ymlRemplacer
cis_server_l1par l'ID du profil par rapport auquel vous souhaitez remédier au système.
Par conséquent, le contenu Ansible est traité correctement.
La prise en charge des collections fournies dans rhc-worker-playbook est limitée à l'activation du contenu Ansible fourni dans scap-security-guide.
