11.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)
scp vide les fichiers copiés sur eux-mêmes lorsqu'une syntaxe spécifique est utilisée
L'utilitaire scp est passé du protocole de copie sécurisée (SCP) au protocole de transfert de fichiers SSH (SFTP), plus sûr. Par conséquent, la copie d'un fichier d'un emplacement vers le même emplacement efface le contenu du fichier. Le problème concerne la syntaxe suivante :
scp localhost:/myfile localhost:/myfile
Pour contourner ce problème, ne copiez pas de fichiers vers une destination identique à l'emplacement source en utilisant cette syntaxe.
Le problème a été corrigé pour les syntaxes suivantes :
-
scp /myfile localhost:/myfile -
scp localhost:~/myfile ~/myfile
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.
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.
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.
La remédiation des règles d'audit SCAP échoue de manière incorrecte
La remédiation Bash de certaines règles SCAP liées à la configuration de l'Audit n'ajoute pas la clé Audit lors de la remédiation. Ceci s'applique aux règles suivantes :
-
audit_rules_login_events -
audit_rules_login_events_faillock -
audit_rules_login_events_lastlog -
audit_rules_login_events_tallylog -
audit_rules_usergroup_modification -
audit_rules_usergroup_modification_group -
audit_rules_usergroup_modification_gshadow -
audit_rules_usergroup_modification_opasswd -
audit_rules_usergroup_modification_passwd -
audit_rules_usergroup_modification_shadow -
audit_rules_time_watch_localtime -
audit_rules_mac_modification -
audit_rules_networkconfig_modification -
audit_rules_sysadmin_actions -
audit_rules_session_events -
audit_rules_sudoers -
audit_rules_sudoers_d
Par conséquent, si la règle d'audit concernée existe déjà mais n'est pas entièrement conforme à la vérification OVAL, la remédiation corrige la partie fonctionnelle de la règle d'audit, c'est-à-dire les bits de chemin et d'accès, mais n'ajoute pas la clé d'audit. Par conséquent, la règle d'audit résultante fonctionne correctement, mais la règle SCAP signale incorrectement FAIL. Pour contourner ce problème, ajoutez manuellement les clés correctes aux règles d'audit.
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.
Keylime pourrait échouer dans l'attestation des systèmes qui accèdent à plusieurs fichiers mesurés par l'IMA
Si un système qui exécute l'agent Keylime accède à plusieurs fichiers mesurés par l'architecture de mesure de l'intégrité (IMA) en succession rapide, le vérificateur Keylime peut traiter incorrectement les ajouts au journal de l'IMA. En conséquence, le hachage en cours d'exécution ne correspond pas à l'état correct du registre de configuration de la plate-forme (PCR), et le système échoue à l'attestation. Il n'existe actuellement aucune solution de contournement.
Le script de génération de la politique de démarrage mesurée par Keylime peut provoquer une erreur de segmentation et un vidage du noyau
Le script create_mb_refstate, qui génère des politiques pour l'attestation de démarrage sur mesure dans Keylime, peut calculer incorrectement la longueur des données dans le champ DevicePath au lieu d'utiliser la valeur du champ LengthOfDevicePath lors du traitement de la sortie de l'outil tpm2_eventlog en fonction de l'entrée fournie. En conséquence, le script tente d'accéder à une mémoire invalide en utilisant la longueur incorrectement calculée, ce qui entraîne une erreur de segmentation et un vidage du noyau. La fonctionnalité principale de Keylime n'est pas affectée par ce problème, mais il se peut que vous ne puissiez pas générer une politique de démarrage mesurée.
Pour contourner ce problème, n'utilisez pas de politique de démarrage mesurée ou écrivez le fichier de politique manuellement à partir des données obtenues à l'aide de l'outil tpm2_eventlog du paquetage tpm2-tools.
Certains certificats TPM provoquent le plantage du registraire Keylime
L'option de configuration require_ek_cert dans tenant.conf, qui devrait être activée dans les déploiements de production, détermine si le locataire Keylime nécessite un certificat de clé d'endossement (EK) du Trusted Platform Module (TPM). Lors de la cotation initiale de l'identité avec require_ek_cert activé, Kelime tente de vérifier si le dispositif TPM sur l'agent est authentique en comparant le certificat EK avec les certificats de confiance présents dans le magasin de certificats Keylime TPM. Cependant, certains certificats du magasin sont des certificats x509 malformés et provoquent le plantage du registre Keylime. Il n'existe actuellement aucune solution simple à ce problème, si ce n'est de configurer require_ek_cert en false et de définir un script personnalisé dans l'option ek_check_script qui effectuera la validation EK.
