Activer la prise en charge de BUG()
Garantit que le noyau en cours d'exécution est compilé avec CONFIG_BUG=y, afin que les assertions BUG()/BUG_ON() se déclenchent et signalent les erreurs internes critiques au lieu d'être ignorées silencieusement.
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
CONFIG_BUG=y fait réellement déclencher les macros BUG() et BUG_ON() du noyau, affichant une trace et tuant le contexte fautif (oops/panic), lorsqu'un invariant interne est violé. Désactivée, ces vérifications sont retirées à la compilation et le noyau continue silencieusement dans un état corrompu, ce qui peut masquer une exploitation, transformer des fautes détectables en corruption mémoire furtive, et rendre un bug de sécurité imprévisible au lieu d'échouer proprement. L'activer garantit que le noyau échoue bruyamment plutôt que de continuer compromis.
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_BUG=y. S'indexer sur uname -r reflète l'image exacte démarrée par GRUB, plus fiable que lire un fichier /boot/config-* arbitraire lorsque plusieurs noyaux sont installés.
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_BUG=|PAVOIS_NO_KERNEL_CONFIG)'") do
its('stdout') { should_not match(/PAVOIS_NO_KERNEL_CONFIG/) }
its('stdout') { should match(/^CONFIG_BUG=y$/) }
endComment vérifier qu’elle est appliquée
Exécutez grep -h '^CONFIG_BUG=' /boot/config-$(uname -r) (ou zcat /proc/config.gz | grep '^CONFIG_BUG='). Attendu : CONFIG_BUG=y.
Inspecter et investiguer
Option de compilation statique du noyau, sans journal dédié. Inspectez avec zcat /proc/config.gz | grep '^CONFIG_BUG=' ou grep '^CONFIG_BUG=' /boot/config-$(uname -r). Lorsqu'un BUG() se déclenche réellement à l'exécution, l'oops/la trace 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_BUG=y, tous les noyaux de distribution courants l'activent par défaut ; sinon recompilez le noyau. pavois harden apply ne peut pas la modifier.
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
Risque si désactivé : les auto-vérifications du noyau sont retirées à la compilation, donc corruptions et violations d'invariants passent inaperçues et le noyau peut continuer dans un état non sûr, masquant des exploits.
Précautions avant de modifier : c'est activé par défaut partout, donc un échec est rare et signale généralement un noyau personnalisé. Remplacer le noyau nécessite un redémarrage, conservez le noyau précédent dans GRUB en repli et validez le démarrage sur une console. Activer CONFIG_BUG n'a aucun inconvénient en production hormis une augmentation négligeable de la taille du code.
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.