Panique du noyau en cas d'oops
Fixe kernel.panic_on_oops = 1 afin que le noyau s'arrête (panique) immédiatement lors d'un oops 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, potentiellement corrompu. Par défaut, le noyau journalise l'oops et tente de continuer, laissant le système dans un état indéfini qu'un attaquant peut provoquer délibérément puis exploiter. Fixer kernel.panic_on_oops = 1 force le noyau à paniquer (s'arrêter) immédiatement à chaque oops, privant l'attaquant d'une fenêtre pour exploiter l'état corrompu et transformant une corruption silencieuse en arrêt franc.
Ce que vérifie Pavois
Pavois lit la valeur noyau en vigueur via kernel_parameter('kernel.panic_on_oops') (équivalent à sysctl kernel.panic_on_oops), et non une ligne de /etc/sysctl.d/*.conf. Un fichier de configuration peut déclarer 1 alors que le noyau en cours est encore à 0, parce que le fichier n'a jamais été appliqué, qu'un paramètre de démarrage l'a écrasé, ou qu'un drop-in ultérieur a prévalu. Seul le paramètre effectif prouve le comportement actuel du noyau.
describe kernel_parameter('kernel.panic_on_oops') do
its('value') { should cmp 1 }
end
describe command("grep -hsE '^[[:space:]]*kernel.panic_on_oops[[:space:]]*=[[:space:]]*1([[:space:]]|$)' /etc/sysctl.conf /etc/sysctl.d/*.conf /run/sysctl.d/*.conf /usr/lib/sysctl.d/*.conf /lib/sysctl.d/*.conf 2>/dev/null") do
its('stdout') { should match(/\S/) }
endComment vérifier qu’elle est appliquée
Exécutez sysctl kernel.panic_on_oops. Sortie attendue :
kernel.panic_on_oops = 1
Inspecter et investiguer
Vérifiez l'état en cours via sysctl kernel.panic_on_oops. Lorsqu'un oops déclenche réellement une panique, la trace de pile est inscrite dans le tampon noyau, visible via dmesg ou journalctl -k avant l'arrêt, et capturée par kdump s'il est configuré.
Remédiation
Le plan de durcissement de Pavois utilise la ressource sysctl pour fixer kernel.panic_on_oops = 1, le persiste dans un drop-in géré par Pavois sous /etc/sysctl.d/, et l'applique à chaud (sans redémarrage). Appliquez-le avec pavois harden apply.
Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :
| key | kernel.panic_on_oops |
|---|---|
| resource | sysctl |
| value | 1 |
pavois harden plan localoù la cible est local, un alias SSH user@hôte, ou un conteneur , Docs
Impact & précautions
Risque si non appliqué : le noyau continue après un oops dans un état indéfini, potentiellement corrompu, qu'un attaquant peut exploiter et qui peut aussi causer une corruption silencieuse de données.
Précautions avant application :
- C'est un arbitrage disponibilité contre intégrité : un simple oops qui auparavant laissait la machine fonctionner tant bien que mal va désormais arrêter la machine. Sur des systèmes sujets à des oops occasionnels de pilotes, un arrêt/redémarrage inattendu peut entraîner une indisponibilité.
- Associez ce réglage à
kdump/redémarrage automatique (délaikernel.panic) pour qu'un hôte en panique capture un dump et redémarre, plutôt que de rester hors service. Validez d'abord sur un hôte non critique.
Mapping des normes
| Norme | Référence | Type | Version | Confiance |
|---|---|---|---|---|
| ANSSI BP-028 | R9 | 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.