4.7. Sécurité
Nouveaux paquets : keylime
RHEL 9.1 introduit Keylime, un outil d'attestation des systèmes distants, qui utilise la technologie TPM (trusted platform module). Avec Keylime, vous pouvez vérifier et surveiller en permanence l'intégrité des systèmes distants. Vous pouvez également spécifier des charges utiles cryptées que Keylime délivre aux machines surveillées, et définir des actions automatisées qui se déclenchent chaque fois qu'un système échoue au test d'intégrité.
Pour plus d'informations, voir Ensuring system integrity with Keylime dans le document Security hardening de RHEL 9.
(JIRA:RHELPLAN-92522)
Une nouvelle option dans OpenSSH permet de définir la longueur minimale de la clé RSA
L'utilisation accidentelle de clés RSA courtes rend le système plus vulnérable aux attaques. Avec cette mise à jour, vous pouvez définir la longueur minimale des clés RSA pour les serveurs et les clients OpenSSH. Pour définir la longueur minimale des clés RSA, utilisez la nouvelle option RequiredRSASize
dans le fichier /etc/ssh/sshd_config
pour les serveurs OpenSSH et dans le fichier /etc/ssh/ssh_config
pour les clients OpenSSH.
crypto-policies
imposer une longueur minimale de clé RSA de 2048 bits pour OpenSSH par défaut
L'utilisation de clés RSA courtes rend le système plus vulnérable aux attaques. OpenSSH prenant désormais en charge la limitation de la longueur minimale des clés RSA, les règles cryptographiques applicables à l'ensemble du système imposent par défaut la longueur minimale de 2048 bits pour les clés RSA.
Si OpenSSH échoue les connexions avec un message d'erreur Invalid key length
, commencez à utiliser des clés RSA plus longues.
Vous pouvez également assouplir cette restriction en utilisant une sous-politique personnalisée, au détriment de la sécurité. Par exemple, si la commande update-crypto-policies --show
indique que la politique actuelle est DEFAULT
:
-
Définissez une sous-politique personnalisée en insérant le paramètre
min_rsa_size@openssh = 1024
dans le fichier/etc/crypto-policies/policies/modules/RSA-OPENSSH-1024.pmod
. -
Appliquez la sous-politique personnalisée à l'aide de la commande
update-crypto-policies --set DEFAULT:RSA-OPENSSH-1024
.
Une nouvelle option d'OpenSSL prend en charge SHA-1 pour les signatures
OpenSSL 3.0.0 dans RHEL 9 ne prend pas en charge SHA-1 pour la création et la vérification des signatures par défaut (les fonctions de dérivation de clé SHA-1 (KDF) et les codes d'authentification de message basés sur le hachage (HMAC) sont toujours pris en charge). Toutefois, pour assurer la rétrocompatibilité avec les systèmes RHEL 8 qui utilisent encore SHA-1 pour les signatures, une nouvelle option de configuration rh-allow-sha1-signatures
est introduite dans RHEL 9. Cette option, si elle est activée dans alg_section
de openssl.cnf
, permet la création et la vérification de signatures SHA-1.
Cette option est automatiquement activée si la politique cryptographique du système LEGACY (pas le fournisseur LEGACY) est définie.
Notez que cela affecte également l'installation de paquets RPM avec des signatures SHA-1, ce qui peut nécessiter le passage à la politique cryptographique du système LEGACY.
(BZ#2060510, BZ#2055796)
crypto-policies
soutient désormais sntrup761x25519-sha512@openssh.com
Cette mise à jour des politiques cryptographiques du système ajoute la prise en charge de la méthode d'échange de clés (KEX) sntrup761x25519-sha512@openssh.com
. L'algorithme post-quantique sntrup761
est déjà disponible dans la suite OpenSSH, et cette méthode offre une meilleure sécurité contre les attaques des ordinateurs quantiques. Pour activer sntrup761x25519-sha512@openssh.com
, créez et appliquez une sous-politique, par exemple :
# echo 'key_exchange = +SNTRUP' > /etc/crypto-policies/policies/modules/SNTRUP.pmod # update-crypto-policies --set DEFAULT:SNTRUP
Pour plus d'informations, voir la section Personnaliser les stratégies cryptographiques à l'échelle du système avec des sous-politiques dans le document de renforcement de la sécurité de RHEL 9.
Les NSS ne prennent plus en charge les clés RSA de moins de 1023 bits
La mise à jour des bibliothèques Network Security Services (NSS) modifie la taille minimale des clés pour toutes les opérations RSA de 128 à 1023 bits. Cela signifie que les NSS n'exécutent plus les fonctions suivantes :
- Générer des clés RSA plus courtes que 1023 bits.
- Signer ou vérifier des signatures RSA avec des clés RSA de moins de 1023 bits.
- Chiffrer ou déchiffrer des valeurs avec une clé RSA inférieure à 1023 bits.
La politique SELinux limite les services supplémentaires
Les paquets selinux-policy
ont été mis à jour, et par conséquent les services suivants sont maintenant confinés par SELinux :
-
ksm
-
nm-priv-helper
-
rhcd
-
stalld
-
systemd-network-generator
-
targetclid
-
wg-quick
(BZ#1965013, BZ#1964862, BZ#2020169, BZ#2021131, BZ#2042614, BZ#2053639, BZ#2111069)
SELinux prend en charge le mot-clé self
dans les transitions de type
L'outil SELinux prend désormais en charge les règles de transition de type avec le mot-clé self
dans les sources de politique. La prise en charge des transitions de type avec le mot-clé self
prépare la politique SELinux à l'étiquetage des inodes anonymes.
Mise à jour des paquets SELinux pour l'espace utilisateur
Les paquets SELinux pour l'espace utilisateur libsepol
, libselinux
, libsemanage
, policycoreutils
, checkpolicy
, et mcstrans
ont été mis à jour vers la dernière version amont 3.4. Les changements les plus notables sont les suivants :
Ajout de la prise en charge du réétiquetage parallèle grâce à l'option
-T
dans les outilssetfiles
,restorecon
etfixfiles
.-
Vous pouvez soit spécifier le nombre de threads de processus dans cette option, soit utiliser
-T 0
pour utiliser le maximum de cœurs de processeurs disponibles. Cela permet de réduire considérablement le temps nécessaire au réétiquetage.
-
Vous pouvez soit spécifier le nombre de threads de processus dans cette option, soit utiliser
-
Ajout de la nouvelle option
--checksum
, qui imprime les hashs SHA-256 des modules. -
Ajout de nouveaux utilitaires de politique dans le paquet
libsepol-utils
.
Le réétiquetage automatique SELinux est désormais parallèle par défaut
Étant donné que l'option de réétiquetage parallèle récemment introduite réduit considérablement le temps nécessaire au processus de réétiquetage SELinux sur les systèmes multicœurs, le script de réétiquetage automatique contient désormais l'option -T 0
dans la ligne de commande fixfiles
. L'option -T 0
garantit que le programme setfiles
utilise par défaut le maximum de cœurs de processeur disponibles pour le ré-étiquetage.
Pour n'utiliser qu'un seul thread de processus pour le réétiquetage, comme dans la version précédente de RHEL, remplacez ce paramètre en entrant la commande fixfiles -T 1 onboot
au lieu de fixfiles onboot
ou la commande echo "-T 1" > /.autorelabel
au lieu de touch /.autorelabel
.
Guide de sécurité SCAP repassé à la version 0.1.63
Les paquets du guide de sécurité SCAP (SSG) ont été rebasés vers la version amont 0.1.63. Cette version apporte diverses améliorations et corrections de bogues, notamment :
-
De nouvelles règles de conformité pour
sysctl
,grub2
,pam_pwquality
, et la configuration du noyau au moment de la construction ont été ajoutées. -
Les règles de renforcement de la pile PAM utilisent désormais
authselect
comme outil de configuration. Note : Avec ce changement, les règles de renforcement de la pile PAM ne sont pas appliquées si la pile PAM a été modifiée par d'autres moyens.
Ajout d'une option de taille maximale pour les fichiers d'erreur Rsyslog
La nouvelle option action.errorfile.maxsize
permet de spécifier le nombre maximal d'octets du fichier d'erreurs pour le système de traitement des journaux Rsyslog. Lorsque le fichier d'erreurs atteint la taille spécifiée, Rsyslog ne peut plus y écrire d'erreurs supplémentaires ou d'autres données. Cela permet d'éviter que le fichier d'erreurs ne remplisse le système de fichiers et ne rende l'hôte inutilisable.
clevis-luks-askpass
est désormais activé par défaut
Le fichier /lib/systemd/system-preset/90-default.preset
contient désormais l'option de configuration enable clevis-luks-askpass.path
et l'installation du sous-paquet clevis-systemd
garantit que le fichier d'unité clevis-luks-askpass.path
est activé. Cela permet au client de chiffrement Clevis de déverrouiller également les volumes chiffrés LUKS qui se montent tardivement dans le processus de démarrage. Avant cette mise à jour, l'administrateur devait utiliser la commande systemctl enable clevis-luks-askpass.path
pour permettre à Clevis de déverrouiller ces volumes.
fapolicyd
repassé à la version 1.1.3
Les paquets fapolicyd
ont été mis à jour vers la version 1.1.3. Les améliorations notables et les corrections de bogues incluent :
- Les règles peuvent désormais contenir le nouvel attribut PPID du sujet, qui correspond au PID parent (ID du processus) d'un sujet.
- La bibliothèque OpenSSL a remplacé la bibliothèque Libgcrypt en tant que moteur cryptographique pour les calculs de hachage.
-
La commande
fagenrules --load
fonctionne désormais correctement.