← Toutes les règles
SOCLE-CLD-KRN-026// Kernel buildfaibleruntime effectif

Activer les vérifications de la gestion des identifiants (credentials)

Garantit que le noyau en cours d'exécution est compilé avec CONFIG_DEBUG_CREDENTIALS=y (là où le symbole existe), ajoutant des vérifications qui détectent toute falsification des structures d'identifiants (struct cred).

Vérifié sur l’état résolu en cours d’exécution (ex. sshd -T, sysctl, systemctl show), attrape les drop-ins et Include qu’une lecture de fichier raterait. Réserve : runtime ≠ persistance ; une valeur correcte maintenant peut ne pas survivre à un redémarrage.

Un PASS prouve✓ actif maintenant✓ sur disque✓ survit au rebootle verdict qualifié →
Debian 12CIS 1.1.0RHEL 8 / Rocky 8 / AlmaLinux 8CIS 4.0.0RHEL 9 / Rocky 9 / AlmaLinux 9CIS 2.0.0Ubuntu 22.04CIS 3.0.0
Un seul check, mappé sur 1 norme

Pavois vérifie la configuration effective, l’état résolu et réellement appliqué, pas un fichier. Les scanners basés fichier (OVAL/SCAP, Lynis) ratent les Include, drop-ins et défauts runtime ; ce check voit ce qui est réellement en vigueur.

Un mapping est une référence croisée vers l’endroit où chaque norme situe cette exigence, ancrée et recoupée, pas une affirmation d’équivalence. Un check réussi est une preuve vers ces références, comment le lire.

Pourquoi cette règle

CONFIG_DEBUG_CREDENTIALS=y ajoute des vérifications de cohérence et de validation à l'exécution sur les objets struct cred du noyau, qui portent l'UID/GID et les capacités d'une tâche. Beaucoup d'exploits d'élévation de privilèges fonctionnent en corrompant ou en écrasant ces structures d'identifiants pour s'octroyer root. La validation supplémentaire détecte ce type de falsification (valeurs magiques incohérentes, compteurs de références erronés) et déclenche un BUG(), transformant un écrasement silencieux d'identifiants en un échec immédiat et visible plutôt qu'en une élévation réussie. Note : cette option a été retirée du noyau mainline vers la v6.3 car les vérifications sont devenues permanentes ; sur ces noyaux le symbole est simplement absent.

Ce que vérifie Pavois

Pavois lit la config de compilation du noyau en cours d'exécution via /boot/config-$(uname -r) (repli /proc/config.gz) et vérifie CONFIG_DEBUG_CREDENTIALS=y. S'indexer sur uname -r correspond à l'image exacte démarrée, plus fiable que lire un /boot/config-* quelconque. Sur les noyaux ≥ 6.3 le symbole n'existe plus (vérifications inconditionnelles), donc une ligne absente peut être attendue plutôt qu'un véritable manque.

describe command("C=/boot/config-$(uname -r); if [ -r \"$C\" ]; then cat \"$C\"; elif zcat /proc/config.gz 2>/dev/null | head -1 | grep -q .; then zcat /proc/config.gz; else echo PAVOIS_NO_KERNEL_CONFIG; fi | grep -E '^(CONFIG_DEBUG_CREDENTIALS=|PAVOIS_NO_KERNEL_CONFIG)'") do
  its('stdout') { should_not match(/PAVOIS_NO_KERNEL_CONFIG/) }
  its('stdout') { should match(/^CONFIG_DEBUG_CREDENTIALS=y$/) }
end

Comment vérifier qu’elle est appliquée

Exécutez grep -h '^CONFIG_DEBUG_CREDENTIALS=' /boot/config-$(uname -r) (ou zcat /proc/config.gz | grep DEBUG_CREDENTIALS). Attendu : CONFIG_DEBUG_CREDENTIALS=y, ou aucun symbole sur les noyaux ≥ 6.3 (uname -r).

Inspecter et investiguer

Option de compilation statique du noyau, sans journal dédié. Inspectez avec zcat /proc/config.gz | grep DEBUG_CREDENTIALS ou grep DEBUG_CREDENTIALS /boot/config-$(uname -r). Si une vérification d'identifiants échoue à l'exécution, le BUG()/oops résultant apparaît dans dmesg et journalctl -k.

Remédiation

Aucune remédiation automatisée n'est fournie : c'est une option de compilation du noyau. Appliquez-la en démarrant un noyau compilé avec CONFIG_DEBUG_CREDENTIALS=y (un noyau durci), ou recompilez le noyau. Sur les noyaux ≥ 6.3 aucune action n'est requise, les vérifications sont toujours intégrées. pavois harden apply ne peut pas la modifier.

Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :

resourcekernel_build
pavois harden plan local

où la cible est local, un alias SSH user@hôte, ou un conteneur , Docs

Impact & précautions

Risque si désactivé (sur les noyaux ayant encore le symbole) : la corruption ou l'écrasement des structures d'identifiants, primitive courante d'élévation de privilèges, passe inaperçu et peut réussir silencieusement.

Précautions avant de modifier : les vérifications ajoutent un léger surcoût à l'exécution mais aucun risque fonctionnel. Changer de noyau nécessite un redémarrage ; conservez le noyau précédent dans GRUB en repli et validez le démarrage sur une console. Ne considérez pas un symbole absent sur les noyaux récents (≥ 6.3) comme une régression.

Mapping des normes

NormeRéférenceTypeVersionConfiance
ANSSI BP-028R16direct2.0haute

Chaque référence est une référence croisée ancrée dans le benchmark amont et recoupée avec le SCAP Security Guide et ansible-lockdown, pas une affirmation d’équivalence. Direct = une exigence prescriptive au niveau de la ligne ; support = une famille de contrôle abstraite (NIST) vers laquelle le check apporte une preuve. Comment lire un mapping.

Sources & références

Normes officielles

ANSSI-BP-028 (2.0) ↗