11.5. Sécurité
tangd-keygen ne gère pas correctement les umask qui ne sont pas par défaut
Le script tangd-keygen ne modifie pas les autorisations de fichiers pour les fichiers de clés générés. Par conséquent, sur les systèmes dotés d'un masque de mode de création de fichiers utilisateur par défaut (umask) qui empêche la lecture des clés par d'autres utilisateurs, la commande tang-show-keys renvoie le message d'erreur Internal Error 500 au lieu d'afficher les clés.
Pour contourner le problème, utilisez la commande chmod o r *.jwk pour modifier les permissions sur les fichiers du répertoire /var/db/tang.
OpenSSL ne détecte pas si un jeton PKCS #11 supporte 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.
Bugzilla: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.
Bugzilla: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
Le module complémentaire OSCAP Anaconda ne récupère pas les profils personnalisés dans l'installation graphique
Le module complémentaire OSCAP Anaconda ne fournit pas d'option pour sélectionner ou désélectionner l'adaptation des profils de sécurité dans l'installation graphique RHEL. À partir de RHEL 8.8, le module complémentaire ne prend pas en compte l'adaptation par défaut lors de l'installation à partir d'archives ou de paquets RPM. Par conséquent, l'installation affiche le message d'erreur suivant au lieu de récupérer un profil OSCAP adapté :
There was an unexpected problem with the supplied content.
Pour contourner ce problème, vous devez spécifier des chemins dans la section don org_fedora_oscap de votre fichier Kickstart, par exemple :
xccdf-path = /usr/share/xml/scap/sc_tailoring/ds-combined.xml tailoring-path = /usr/share/xml/scap/sc_tailoring/tailoring-xccdf.xml
Par conséquent, vous ne pouvez utiliser l'installation graphique pour les profils personnalisés OSCAP qu'avec les spécifications Kickstart correspondantes.
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.
oscap-anaconda-addon ne permet pas au CIS de durcir les systèmes avec le groupe de paquets Network Servers
Lors de l'installation de RHEL Network Servers avec un profil de sécurité CIS (cis, cis_server_l1, cis_workstation_l1, ou cis_workstation_l2) sur des systèmes où le groupe de paquets Network Servers est sélectionné, oscap-anaconda-addon envoie le message d'erreur package tftp has been added to the list of excluded packages, but it can’t be removed from the current software selection without breaking the install. Pour poursuivre l'installation, revenez à la sélection des logiciels et décochez la case Network Servers additional software pour permettre à l'installation et au durcissement de se terminer. Installez ensuite les paquets requis.
Keylime n'accepte pas les certificats PEM concaténés
Lorsque Keylime reçoit une chaîne de certificats sous la forme de plusieurs certificats au format PEM concaténés dans un seul fichier, le composant Keylime keylime-agent-rust n'utilise pas correctement tous les certificats fournis lors de la vérification de la signature, ce qui entraîne un échec de la poignée de main TLS. En conséquence, les composants clients (keylime_verifier et keylime_tenant) ne peuvent pas se connecter à l'agent Keylime. Pour contourner ce problème, utilisez un seul certificat au lieu de plusieurs.
Jira:RHELPLAN-157225
Keylime nécessite un fichier spécifique pour tls_dir = default
Lorsque la variable tls_dir est définie sur default dans la configuration du vérificateur ou du registraire Keylime, Keylime vérifie la présence du fichier cacert.crt dans le répertoire /var/lib/keylime/cv_ca. Si le fichier n'est pas présent, le service keylime_verifier ou keylime_registrar ne démarre pas et enregistre le message suivant dans un journal : Exception: It appears that the verifier has not yet created a CA and certificates, please run the verifier first. En conséquence, Keylime rejette les certificats d'autorité de certification (CA) personnalisés qui ont un nom de fichier différent même s'ils sont placés dans le répertoire /var/lib/keylime/ca_cv.
Pour contourner ce problème et utiliser des certificats d'autorité de certification personnalisés, spécifiez manuellement tls_dir =/var/lib/keylime/ca_cv au lieu d'utiliser tls_dir = default.
Jira:RHELPLAN-157337
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.
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.
Problèmes de consommation de mémoire d'OpenSCAP
Sur les systèmes disposant d'une mémoire limitée, l'analyseur OpenSCAP peut se terminer prématurément ou ne pas générer les fichiers de résultats. Pour contourner ce problème, vous pouvez personnaliser le profil d'analyse afin de désélectionner les règles qui impliquent une récursivité sur l'ensemble du système de fichiers /:
-
rpm_verify_hashes -
rpm_verify_permissions -
rpm_verify_ownership -
file_permissions_unauthorized_world_writable -
no_files_unowned_by_user -
dir_perms_world_writable_system_owned -
file_permissions_unauthorized_suid -
file_permissions_unauthorized_sgid -
file_permissions_ungroupowned -
dir_perms_world_writable_sticky_bits
Pour plus de détails et de solutions de contournement, voir l'article de la base de connaissances correspondant.
