4.7. Sécurité
Le système crypto-policies est désormais plus sûr
Avec cette mise à jour, les politiques cryptographiques du système ont été ajustées pour fournir des valeurs par défaut sécurisées et actualisées :
- Désactivation de TLS 1.0, TLS 1.1, DTLS 1.0, RC4, Camellia, DSA, 3DES et FFDHE-1024 dans toutes les politiques.
- Augmentation de la taille minimale des clés RSA et de la taille minimale des paramètres Diffie-Hellman dans LEGACY.
- Désactivation des algorithmes TLS et SSH utilisant SHA-1, à l'exception de l'utilisation de SHA-1 dans les codes d'authentification des messages basés sur le hachage (HMAC).
Si votre scénario nécessite l'activation de certains algorithmes et chiffrements désactivés, utilisez des stratégies ou sous-politiques personnalisées.
(BZ#1937651)
RHEL 9 fournit OpenSSL 3.0.1
RHEL 9 fournit les paquets openssl dans la version amont 3.0.1, qui comprend de nombreuses améliorations et corrections de bogues par rapport à la version précédente. Les changements les plus notables sont les suivants :
- Ajout du nouveau concept de fournisseur. Les fournisseurs sont des collections d'algorithmes, et vous pouvez choisir différents fournisseurs pour différentes applications.
- Introduction du nouveau schéma de version dans le format suivant : <major>.<minor>.<patch>.
- Ajout de la prise en charge du protocole de gestion des certificats (CMP, RFC 4210), du format de message de demande de certificat (CRMF) et du transfert HTTP (RFC 6712).
- Introduction d'un client HTTP(S) qui prend en charge GET et POST, la redirection, les contenus en clair et codés ASN.1-, les proxies et les délais d'attente.
- Ajout d'une nouvelle API de fonction de dérivation de clé (EVP_KDF) et d'une API de code d'authentification de message (EVP_MAC).
-
Ajout de la prise en charge de Linux Kernel TLS (KTLS) en compilant avec l'option de configuration
enable-ktls. - Ajout de la prise en charge de la vérification de la signature CAdES-BES.
- Ajout de la prise en charge du schéma de signature CAdES-BES et de ses attributs (RFC 5126) à l'API de la CMS.
Prise en charge de nouveaux algorithmes, par exemple :
- Algorithmes KDF "SINGLE STEP" et "SSH".
- Algorithmes MAC "GMAC" et "KMAC".
- Algorithme KEM "RSASVE".
- Algorithme de chiffrement "AES-SIV"
- Ajout de la structure du type de contenu AuthEnvelopedData (RFC 5083) utilisant AES_GCM.
-
Les algorithmes par défaut pour la création de PKCS #12 avec la fonction
PKCS12_create()ont été remplacés par des algorithmes plus modernes basés sur PBKDF2 et AES. - Ajout d'une nouvelle API générique de traçage.
OpenSSL inclut désormais les fournisseurs
La boîte à outils OpenSSL dans sa version 3.0.1, qui est incluse dans RHEL 9, a ajouté le concept de fournisseurs. Les fournisseurs sont des collections d'algorithmes, et vous pouvez choisir différents fournisseurs pour différentes applications. OpenSSL inclut actuellement les fournisseurs suivants : base, default, fips, legacy, et null.
Par défaut, OpenSSL charge et active le fournisseur default, qui comprend des algorithmes couramment utilisés tels que RSA, DSA, DH, CAMELLIA, SHA-1 et SHA-2.
Lorsque le drapeau FIPS est activé dans le noyau, OpenSSL charge automatiquement le fournisseur FIPS et n'utilise que des algorithmes approuvés par le FIPS. Par conséquent, il n'est pas nécessaire de basculer manuellement OpenSSL en mode FIPS.
Pour changer de fournisseur au niveau du système, modifiez le fichier de configuration openssl.cnf. Par exemple, si votre scénario nécessite l'utilisation du fournisseur legacy, décommentez la section correspondante.
L'activation explicite d'un fournisseur annule l'activation implicite du fournisseur par défaut et peut rendre le système inaccessible à distance, par exemple par la suite OpenSSH.
Pour plus d'informations sur les algorithmes inclus dans chaque fournisseur, consultez les pages de manuel correspondantes. Par exemple, la page de manuel OSSL_PROVIDER-legacy(7) pour le fournisseur legacy.
Le générateur de bits aléatoires OpenSSL prend désormais en charge CPACF
Cette version des paquets openssl introduit la prise en charge du CP Assist for Cryptographic Functions (CPACF) dans le générateur de bits aléatoires déterministes (DRBG) OpenSSL conforme à la norme NIST SP800-90A.
(BZ#1871147)
openssl-spkac peut désormais créer des fichiers SPKAC signés avec SHA-1 et SHA-256
L'utilitaire openssl-spkac peut désormais créer des fichiers de clés publiques et de défis signés Netscape (SPKAC) signés avec des hachages différents de MD5. Vous pouvez également créer et vérifier des fichiers SPKAC signés avec des hachages SHA-1 et SHA-256.
RHEL 9 fournit openCryptoki 3.17.0
RHEL 9 est distribué avec openCryptoki version 3.17.0. Les corrections de bogues et améliorations notables par rapport à la version 3.16.0 sont les suivantes :
-
L'utilitaire
p11sakajoute une nouvelle fonction pour lister les touches. openCryptokiprend désormais en charge :- OpenSSL 3.0.
- Notifications d'événements.
- Les solutions de repli logiciel dans les jetons ICA.
- Le démarrage de WebSphere Application Server n'échoue plus lorsque l'adaptateur cryptographique matériel est activé.
RHEL 9 inclut OpenSSL avec des correctifs supplémentaires, qui sont spécifiques à RHEL. Si le système est en mode FIPS (Federal Information Processing Standards), OpenSSL charge automatiquement le fournisseur FIPS et le fournisseur de base et force les applications à utiliser le fournisseur FIPS. Par conséquent, le comportement de openCryptoki sur RHEL 9 diffère de celui en amont :
- Les jetons qui s'appuient sur l'implémentation par OpenSSL des opérations cryptographiques (soft tokens et fallbacks logiciels des jetons ICA) ne prennent désormais en charge que les mécanismes approuvés par le FIPS, même si les mécanismes non approuvés sont toujours répertoriés comme étant disponibles.
openCryptokiprend en charge deux formats de données différents pour les jetons : l'ancien format de données, qui utilise des algorithmes non approuvés par la FIPS (tels que DES et SHA1), et le nouveau format de données, qui utilise uniquement des algorithmes approuvés par la FIPS.L'ancien format de données ne fonctionne plus car le fournisseur FIPS n'autorise l'utilisation que d'algorithmes approuvés par le FIPS.
ImportantPour que
openCryptokifonctionne sur RHEL 9, migrez les jetons pour utiliser le nouveau format de données avant d'activer le mode FIPS sur le système. Cette opération est nécessaire car l'ancien format de données est toujours utilisé par défaut dansopenCryptoki 3.17. Les installationsopenCryptokiexistantes qui utilisent l'ancien format de données des jetons ne fonctionneront plus lorsque le système passera en mode FIPS.Vous pouvez migrer les jetons vers le nouveau format de données en utilisant l'utilitaire
pkcstok_migrate, fourni avecopenCryptoki. Notez quepkcstok_migrateutilise des algorithmes non approuvés par le FIPS pendant la migration. Par conséquent, il convient d'utiliser cet outil avant d'activer le mode FIPS sur le système. Pour plus d'informations, voir Migration vers la conformité FIPS - utilitaire pkcstok_migrate.
(BZ#1869533)
GnuTLS fourni dans la version 3.7.3
Dans RHEL 9, les paquets gnutls sont fournis dans la version amont 3.7.3. Cette version apporte de nombreuses améliorations et corrections de bogues par rapport aux versions précédentes, notamment :
- Introduction d'une API pour les indicateurs explicites de la norme FIPS 140-3.
- Défauts renforcés pour l'exportation de fichiers PKCS#12.
- Fixation du moment de l'échange des données anticipées (données zéro round trip, 0-RTT).
-
L'outil
certutiln'hérite plus du point de distribution de la liste de révocation des certificats (CRL) de l'autorité de certification (CA) lors de la signature d'une demande de signature de certificat (CSR).
(BZ#2033220)
RHEL 9 fournit NSS 3.71
RHEL 9 est distribué avec la version 3.71 des bibliothèques NSS (Network Security Services). Les changements notables sont les suivants :
- La prise en charge de l'ancien format de base de données DBM a été complètement supprimée. NSS ne prend en charge que le format de base de données SQLite dans RHEL 9.
- Les algorithmes de chiffrement PKCS #12 utilisent désormais les algorithmes AES-128-CBC avec PBKDF2 et SHA-256 au lieu de PBE-SHA1-RC2-40 et PBE-SHA1-2DES.
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.
Option de longueur minimale des bits de la clé RSA dans OpenSSH
L'utilisation accidentelle de clés RSA courtes peut rendre le système plus vulnérable aux attaques. Avec cette mise à jour, vous pouvez définir la longueur minimale des bits de la clé RSA pour les serveurs et les clients OpenSSH. Pour définir la longueur minimale de la clé RSA, utilisez la nouvelle option RSAMinSize dans le fichier /etc/ssh/sshd_config pour les serveurs OpenSSH et dans le fichier /etc/ssh/ssh_config pour les clients OpenSSH.
OpenSSH distribué dans la version 8.7p1
RHEL 9 inclut OpenSSH dans la version 8.7p1. Cette version apporte de nombreuses améliorations et corrections de bogues par rapport à la version 8.0p1 de OpenSSH, qui est distribuée dans RHEL 8.5, notamment :
New Features
Prise en charge des transferts utilisant le protocole SFTP en remplacement du protocole SCP/RCP précédemment utilisé. SFTP offre une gestion plus prévisible des noms de fichiers et ne nécessite pas l'expansion des motifs glob(3) par l'interpréteur de commandes du côté distant.
Le support SFTP est activé par défaut. Si SFTP n'est pas disponible ou incompatible dans votre scénario, vous pouvez utiliser le drapeau
-Opour forcer l'utilisation du protocole SCP/RCP d'origine.-
La directive de configuration
LogVerbosequi permet de forcer la journalisation maximale du débogage par des listes de motifs de fichiers/fonctions/lignes. -
Limitation du débit en fonction de l'adresse du client avec les nouvelles directives
sshd_configPerSourceMaxStartupsetPerSourceNetBlockSize. Cela permet un contrôle plus fin que la limite globale deMaxStartups. -
Le mot-clé
HostbasedAcceptedAlgorithmsfiltre désormais sur la base de l'algorithme de signature au lieu de filtrer par type de clé. -
Le mot-clé
Includesshd_configdu démonsshdqui permet d'inclure des fichiers de configuration supplémentaires en utilisant des motifsglob. -
Prise en charge des authentificateurs matériels U2F (Universal 2nd Factor) spécifiés par l'alliance FIDO. U2F/FIDO sont des normes ouvertes pour le matériel d'authentification à deux facteurs peu coûteux qui sont largement utilisées pour l'authentification des sites web. Dans OpenSSH, les dispositifs FIDO sont pris en charge par les nouveaux types de clés publiques
ecdsa-sketed25519-sket par les types de certificats correspondants. -
Prise en charge des clés FIDO qui nécessitent un code PIN pour chaque utilisation. Vous pouvez générer ces clés en utilisant
ssh-keygenavec la nouvelle optionverify-required. Lorsqu'une clé nécessitant un code PIN est utilisée, l'utilisateur est invité à saisir son code PIN pour terminer l'opération de signature. -
Le fichier
authorized_keysprend désormais en charge une nouvelle optionverify-required. Cette option exige que les signatures FIDO fassent appel à une vérification par jeton de la présence de l'utilisateur avant de procéder à la signature. Le protocole FIDO prend en charge plusieurs méthodes de vérification de l'utilisateur. OpenSSH ne prend actuellement en charge que la vérification du code PIN. -
Ajout de la prise en charge de la vérification des signatures FIDO
webauthn.webauthnest une norme permettant d'utiliser les clés FIDO dans les navigateurs web. Ces signatures ont un format légèrement différent des signatures FIDO ordinaires et nécessitent donc une prise en charge explicite.
Bug fixes
-
Clarification de la sémantique du mot-clé
ClientAliveCountMax=0. Désormais, il désactive entièrement l'arrêt de la connexion au lieu du comportement précédent qui consistait à arrêter instantanément la connexion après le premier test de vivacité, quel que soit son succès.
Security
- Correction d'un débordement d'entier exploitable dans le code d'analyse de la clé privée pour le type de clé XMSS. Ce type de clé est encore expérimental et son support n'est pas compilé par défaut. Aucune option autoconf orientée utilisateur n'existe dans OpenSSH portable pour l'activer.
- Ajout d'une protection pour les clés privées au repos dans la RAM contre la spéculation et les attaques par canal latéral de la mémoire comme Spectre, Meltdown et Rambleed. Cette version chiffre les clés privées lorsqu'elles ne sont pas utilisées avec une clé symétrique dérivée d'une "préclé" relativement importante composée de données aléatoires (actuellement 16 Ko).
La redirection des langues est désactivée par défaut dans OpenSSH
L'utilisation des paramètres régionaux C.UTF-8 dans les petites images, telles que les conteneurs et les machines virtuelles, réduit la taille et améliore les performances par rapport à l'utilisation des paramètres régionaux traditionnels en_US.UTF-8.
La plupart des distributions envoient des variables d'environnement locales par défaut et les acceptent côté serveur. Cependant, cela signifie que la connexion via SSH de clients utilisant des locales autres que C ou C.UTF-8 à des serveurs sur lesquels les paquets glibc-langpack-en ou glibc-all-langpacks n'étaient pas installés entraînait une dégradation de l'expérience de l'utilisateur. En particulier, la sortie au format UTF-8 était défectueuse et certains outils ne fonctionnaient pas ou envoyaient des messages d'avertissement fréquents.
Avec cette mise à jour, la redirection des paramètres linguistiques est désactivée par défaut dans OpenSSH. La locale reste ainsi viable même si les clients se connectent à des serveurs dotés d'installations minimales qui ne prennent en charge qu'un petit nombre de locales.
OpenSSH prend en charge les clés de sécurité U2F/FIDO
Auparavant, les clés OpenSSH stockées dans le matériel n'étaient prises en charge que par la norme PKCS #11, ce qui limitait l'utilisation d'autres clés de sécurité dans SSH. La prise en charge des clés de sécurité U2F/FIDO a été développée en amont et est désormais implémentée dans RHEL 9, ce qui améliore l'utilisation des clés de sécurité dans SSH indépendamment de l'interface PKCS #11.
Libreswan fourni dans la version 4.6
Dans RHEL 9, Libreswan est fourni dans la version amont 4.6. Cette version apporte de nombreuses corrections de bogues et améliorations, notamment sur l'IPsec labellisé utilisé avec l'Internet Key Exchange version 2 (IKEv2).
(BZ#2017355)
Libreswan n'accepte pas les paquets IKEv1 par défaut
Le protocole IKEv2 (Internet Key Exchange v2) étant désormais largement déployé, Libreswan ne prend plus en charge les paquets IKEv1 par défaut. IKEv2 offre un environnement plus sûr et une meilleure résistance aux attaques. Si votre scénario nécessite l'utilisation d'IKEv1, vous pouvez l'activer en ajoutant l'option ikev1-policy=accept au fichier de configuration /etc/ipsec.conf.
RHEL 9 fournit stunnel 5.62
RHEL 9 est distribué avec le paquet stunnel version 5.62. Les corrections de bogues et améliorations notables sont les suivantes :
-
Sur les systèmes en mode FIPS,
stunnelutilise désormais toujours le mode FIPS. -
Les options
NO_TLSv1.1,NO_TLSv1.2, etNO_TLSv1.3ont été renommées respectivementNO_TLSv1_1,NO_TLSv1_2, etNO_TLSv1_3. -
La nouvelle option de niveau de service
sessionResumepermet d'activer et de désactiver la reprise de session. -
LDAP est désormais pris en charge par les clients
stunnelà l'aide de l'optionprotocol. - Un script de complétion Bash est désormais disponible.
RHEL 9 fournit nettle 3.7.3
RHEL 9 fournit la version 3.7.3 du paquet nettle avec de nombreuses corrections de bogues et améliorations. Les changements notables sont les suivants :
-
Prise en charge de nouveaux algorithmes et modes, par exemple
Ed448,SHAKE256,AES-XTS,SIV-CMAC. - Ajoute des optimisations spécifiques à l'architecture pour les algorithmes existants.
(BZ#1986712)
RHEL 9 fournit p11-kit 0.24
RHEL 9 fournit le paquet p11-kit avec la version 0.24. Cette version apporte de nombreuses corrections de bogues et améliorations. Notamment, le sous-répertoire de stockage des autorités de certification de confiance a été renommé blocklist.
(BZ#1966680)
cyrus-sasl utilise désormais GDBM au lieu de Berkeley DB
Le paquetage cyrus-sasl est maintenant construit sans la dépendance libdb, et le plugin sasldb utilise le format de base de données GDBM au lieu de Berkeley DB. Pour migrer vos bases de données SASL (Simple Authentication and Security Layer) existantes stockées dans l'ancien format Berkeley DB, utilisez l'outil cyrusbdb2current avec la syntaxe suivante :
cyrusbdb2current <sasldb_path> <new_path>
La politique SELinux de RHEL 9 est à jour avec le noyau actuel
La politique SELinux inclut de nouvelles permissions, classes et capacités qui font également partie du noyau. Par conséquent, SELinux peut utiliser tout le potentiel fourni par le noyau. En particulier, SELinux dispose d'une meilleure granularité pour l'octroi des permissions, ce qui présente des avantages ultérieurs en termes de sécurité. Cela permet également de faire fonctionner les systèmes avec la politique SELinux MLS, car la politique MLS empêcherait certains systèmes de démarrer s'ils contenaient des permissions inconnues de la politique.
(BZ#1941810, BZ#1954145)
La politique SELinux par défaut interdit les commandes contenant des bibliothèques de relocalisation de texte
Le booléen selinuxuser_execmod est désormais désactivé par défaut afin d'améliorer l'empreinte de sécurité des systèmes installés. En conséquence, les utilisateurs de SELinux ne peuvent pas entrer de commandes utilisant des bibliothèques qui nécessitent une relocalisation de texte, à moins que les fichiers de la bibliothèque ne portent l'étiquette textrel_shlib_t.
OpenSCAP est fourni dans la version 1.3.6
RHEL 9 inclut OpenSCAP dans la version 1.3.6, qui apporte des corrections de bogues et des améliorations, notamment :
-
Vous pouvez fournir des copies locales des composants du flux de données de la source SCAP distante au lieu de les télécharger pendant l'analyse en utilisant l'option
--local-files -
OpenSCAP accepte plusieurs arguments
--rulepour sélectionner plusieurs règles sur la ligne de commande. -
Vous pouvez ignorer l'évaluation de certaines règles en utilisant l'option
--skip-rule. -
Vous pouvez limiter la mémoire consommée par les sondes OpenSCAP en utilisant la variable d'environnement
OSCAP_PROBE_MEMORY_USAGE_RATIO. - OpenSCAP supporte désormais le Blueprint OSBuild comme type de remédiation.
OSCAP Anaconda Add-on supporte désormais un nouveau nom d'add-on
Grâce à cette amélioration, vous pouvez utiliser le nouveau nom du module com_redhat_oscap plutôt que l'ancien nom du module org_fedora_oscap dans le fichier Kickstart du module OSCAP Anaconda Add-on. Par exemple, la section Kickstart peut être structurée comme suit :
%addon com_redhat_oscap content-type = scap-security-guide %end
OSCAP Anaconda Add-on est actuellement compatible avec l'ancien nom de l'add-on, mais la prise en charge de l'ancien nom de l'add-on sera supprimée dans une prochaine version majeure de RHEL.
(BZ#1893753)
Les flux CVE OVAL sont désormais compressés
Avec cette mise à jour, Red Hat fournit les flux CVE OVAL sous une forme compressée. Ils ne sont plus disponibles sous forme de fichiers XML, mais au format bzip2. L'emplacement des flux pour RHEL9 a également été mis à jour pour refléter ce changement. Notez que les scanners SCAP tiers peuvent avoir des problèmes avec les règles d'analyse qui utilisent un flux compressé parce que le référencement du contenu compressé n'est pas standardisé.
Guide de sécurité SCAP fourni dans la version 0.1.60
RHEL 9 inclut les paquets scap-security-guide dans la version 0.1.60. Cette version apporte des corrections de bogues et des améliorations, notamment :
-
Les règles de renforcement de la pile PAM utilisent désormais
authselectcomme outil de configuration. - Le SCAP Security Guide fournit désormais un fichier d'adaptation delta pour le profil STIG. Ce fichier d'adaptation définit un profil qui représente les différences entre le contenu automatisé STIG et SSG de la DISA.
Profils du guide de sécurité SCAP pris en charge dans RHEL 9.0
Grâce aux profils de conformité du guide de sécurité SCAP inclus dans RHEL 9.0, vous pouvez renforcer le système conformément aux recommandations des organisations émettrices. Par conséquent, vous pouvez configurer et automatiser la conformité de vos systèmes RHEL 9 selon le niveau de renforcement requis en utilisant les remédiations et les profils SCAP associés.
| Nom du profil | ID du profil | Version de la politique |
|---|---|---|
| Agence nationale de la sécurité des systèmes d'information (ANSSI) BP-028 niveau renforcé |
| 1.2 |
| Agence nationale de la sécurité des systèmes d'information (ANSSI) BP-028 Haut niveau |
| 1.2 |
| Agence nationale de la sécurité des systèmes d'information (ANSSI) BP-028 Niveau intermédiaire |
| 1.2 |
| Agence nationale de la sécurité des systèmes d'information (ANSSI) BP-028 Niveau minimal |
| 1.2 |
| [PROJET] CIS Red Hat Enterprise Linux 9 Benchmark pour le niveau 2 - Serveur |
| PROJET[a] |
| [PROJET] CIS Red Hat Enterprise Linux 9 Benchmark pour le niveau 1 - Serveur |
| PROJET[a] |
| [PROJET] CIS Red Hat Enterprise Linux 9 Benchmark pour le niveau 1 - Station de travail |
| PROJET[a] |
| [PROJET] CIS Red Hat Enterprise Linux 9 Benchmark pour le niveau 2 - Station de travail |
| PROJET[a] |
| [Informations non classifiées dans les systèmes d'information et les organisations non fédérales (NIST 800-171) |
| r2 |
| Centre australien de cybersécurité (ACSC) Huit éléments essentiels |
| non versionné |
| Loi sur la portabilité et la responsabilité en matière d'assurance maladie (HIPAA) |
| non versionné |
| Centre australien de cybersécurité (ACSC) ISM Official |
| non versionné |
| [Profil de protection pour les systèmes d'exploitation généraux |
| 4.2.1 |
| Base de contrôle PCI-DSS v3.2.1 pour Red Hat Enterprise Linux 9 |
| 3.2.1 |
| [PROJET] STIG DISA pour Red Hat Enterprise Linux 9 |
| PROJET[b] |
| [DRAFT] DISA STIG avec GUI pour Red Hat Enterprise Linux 9 |
| PROJET[b] |
[a]
Le CIS n'a pas encore publié de benchmark officiel pour RHEL 9
[b]
La DISA n'a pas encore publié de référence officielle pour RHEL 9
| ||
La remédiation automatique peut rendre le système non fonctionnel. Exécutez d'abord la remédiation dans un environnement de test.
(BZ#2045341, BZ#2045349, BZ#2045361, BZ#2045368, BZ#2045374, BZ#2045381, BZ#2045386, BZ#2045393, BZ#2045403)
RHEL 9 fournit fapolicyd 1.1
RHEL 9 est distribué avec le paquet fapolicyd version 1.1. Les améliorations les plus notables sont les suivantes :
-
Le répertoire
/etc/fapolicyd/rules.d/, qui contient les fichiers contenant les règles d'exécution d'autorisation et de refus, remplace le fichier/etc/fapolicyd/fapolicyd.rules. Le scriptfagenrulesfusionne désormais tous les fichiers de règles de ce répertoire dans le fichier/etc/fapolicyd/compiled.rules. Voir la nouvelle page de manuelfagenrules(8)pour plus de détails. -
En plus du fichier
/etc/fapolicyd/fapolicyd.trustqui permet de marquer comme fiables les fichiers ne faisant pas partie de la base de données RPM, vous pouvez désormais utiliser le nouveau répertoire/etc/fapolicyd/trust.d, qui permet de séparer une liste de fichiers fiables en plusieurs fichiers. Vous pouvez également ajouter une entrée pour un fichier en utilisant la sous-commandefapolicyd-cli -favec la directive--trust-filedans ces fichiers. Consultez les pages de manuelfapolicyd-cli(1)etfapolicyd.trust(13)pour plus d'informations. -
La base de données de confiance
fapolicydprend désormais en charge les espaces blancs dans les noms de fichiers. -
fapolicydenregistre désormais le chemin d'accès correct à un fichier exécutable lorsqu'il ajoute le fichier à la base de données de confiance.
Rsyslog inclut le module mmfields pour des opérations plus performantes et CEF
Rsyslog comprend désormais le sous-paquetage rsyslog-mmfields qui fournit le module mmfields. Il s'agit d'une alternative à l'utilisation de l'extraction de champs du substitut de propriété, mais contrairement à ce dernier, tous les champs sont extraits en une seule fois et stockés dans la partie des données structurées. Par conséquent, vous pouvez utiliser mmfields en particulier pour traiter des formats d'enregistrement basés sur des champs, par exemple Common Event Format (CEF), et si vous avez besoin d'un grand nombre de champs ou si vous réutilisez des champs spécifiques. Dans ces cas, mmfields est plus performant que les fonctions Rsyslog existantes.
logrotate inclus dans un paquet séparé rsyslog-logrotate
La configuration logrotate a été séparée du paquet principal rsyslog dans le nouveau paquet rsyslog-logrotate. Ceci est utile dans certains environnements minimaux, par exemple lorsque la rotation des journaux n'est pas nécessaire, pour éviter d'installer des dépendances inutiles.
sudo supporte les plugins Python
Avec le programme sudo version 1.9, qui est inclus dans RHEL 9, vous pouvez écrire des plugins sudo en Python. Il est ainsi plus facile d'améliorer sudo pour l'adapter plus précisément à des scénarios spécifiques.
Pour plus d'informations, voir la page de manuel sudo_plugin_python(8).
libseccomp fourni dans la version 2.5.2
RHEL 9.0 fournit les paquets libseccomp dans la version amont 2.5.2. Cette version apporte de nombreuses corrections de bogues et améliorations par rapport aux versions précédentes, notamment :
-
Mise à jour de la table syscall pour Linux vers la version
v5.14-rc7. -
Ajout de la fonction
get_notify_fd()aux liaisons Python pour obtenir le descripteur de fichier de notification. - Consolidation en un seul endroit de la gestion des appels de service multiplexés pour toutes les architectures.
- Ajout de la prise en charge du syscall multiplexé pour les architectures PowerPC (PPC) et MIPS.
-
Modification de la signification de l'opération
SECCOMP_IOCTL_NOTIF_ID_VALIDdans le noyau. -
Modification de la logique de notification du descripteur de fichier
libseccomppour prendre en charge l'ancienne et la nouvelle utilisation deSECCOMP_IOCTL_NOTIF_ID_VALIDpar le noyau. -
Correction d'un bug où
seccomp_load()ne pouvait être appelé qu'une seule fois. -
Modification de la gestion des notifications
fdpour ne demander une notificationfdque si le filtre a une action_NOTIFY. -
Ajout de la documentation sur
SCMP_ACT_NOTIFYà la page de manuelseccomp_add_rule(3). - Clarification des clés GPG des mainteneurs.
Clevis prend désormais en charge SHA-256
Grâce à cette amélioration, le cadre Clevis prend en charge l'algorithme SHA-256 en tant que hachage par défaut pour les empreintes de clés Web JSON (JWK), conformément aux recommandations de RFC 7638. Comme les anciennes empreintes (SHA-1) sont toujours prises en charge, vous pouvez toujours décrypter les données précédemment cryptées.
(BZ#1956760)
