Panique du noyau sur oops
Exige que le noyau en cours d'exécution soit compilé avec CONFIG_PANIC_ON_OOPS=y afin qu'un oops du noyau déclenche une panique immédiate au lieu de continuer dans un état corrompu.
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.
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
Un oops du noyau signale que celui-ci a atteint un état incohérent ou corrompu. Par défaut, le noyau journalise l'oops et tente de continuer, laissant le système fonctionner dans un état partiellement corrompu, ce qu'un attaquant exploitant un bug de corruption mémoire peut mettre à profit, et qui peut corrompre silencieusement des données. CONFIG_PANIC_ON_OOPS=y transforme un oops en panique immédiate (arrêt/redémarrage), privant l'attaquant d'une seconde tentative et empêchant le système de fonctionner sur un état corrompu.
Ce que vérifie Pavois
Pavois lit la configuration de compilation du noyau en cours d'exécution via /boot/config-$(uname -r), avec repli sur /proc/config.gz, de sorte que le résultat reflète le noyau démarré. Pavois attend CONFIG_PANIC_ON_OOPS=y. Le comportement peut aussi être ajusté à l'exécution via le sysctl kernel.panic_on_oops.
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_PANIC_ON_OOPS=|PAVOIS_NO_KERNEL_CONFIG)'") do
its('stdout') { should_not match(/PAVOIS_NO_KERNEL_CONFIG/) }
its('stdout') { should match(/^CONFIG_PANIC_ON_OOPS=y$/) }
endComment vérifier qu’elle est appliquée
À la compilation : grep '^CONFIG_PANIC_ON_OOPS=' /boot/config-$(uname -r) → CONFIG_PANIC_ON_OOPS=y. À l'exécution : sysctl kernel.panic_on_oops doit renvoyer kernel.panic_on_oops = 1.
Inspecter et investiguer
Un oops/panique est enregistré par le noyau : consultez dmesg, journalctl -k, et les vidages de plantage capturés par kdump/kexec (par ex. sous /var/crash). Le réglage actuel à l'exécution est donné par sysctl kernel.panic_on_oops.
Remédiation
Aucune remédiation automatique pour le drapeau de compilation : CONFIG_PANIC_ON_OOPS est une option de compilation du noyau. Toutefois, le comportement équivalent à l'exécution peut être défini avec le sysctl kernel.panic_on_oops=1 (une règle distincte du domaine sysctl), que la plupart des noyaux de distribution respectent. Appliquez l'option du noyau manuellement (utilisez un noyau compilé avec) ; pavois harden apply ne peut pas modifier un paramètre compilé en dur.
Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :
| resource | kernel_build |
|---|
pavois harden plan localoù la cible est local, un alias SSH user@hôte, ou un conteneur , Docs
Impact & précautions
Sans panique sur oops, le système continue de fonctionner après une faute noyau, risquant une corruption de données et laissant aux exploits l'occasion de réessayer. Le compromis est la disponibilité : une fois activé, un oops non malveillant (par ex. un pilote bogué) redémarrera la machine au lieu de journaliser et continuer. Précaution : sur les systèmes où la disponibilité est critique, associez ceci à kdump pour capturer un vidage de plantage à des fins de diagnostic, assurez-vous que les services redémarrent proprement, et évitez-le sur les hôtes où un oops de pilote transitoire serait plus nuisible que le redémarrage. Aucun risque de blocage d'accès.
Mapping des normes
| Norme | Référence | Type | Version | Confiance |
|---|---|---|---|---|
| ANSSI BP-028 | R19 | direct | 2.0 | haute |
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.