Restreindre l'accès au tampon des messages du noyau
Définit kernel.dmesg_restrict=1 pour que seuls les utilisateurs privilégiés (CAP_SYSLOG) puissent lire le tampon circulaire du noyau, masquant les adresses qui faciliteraient un exploit noyau.
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
Le tampon circulaire du noyau (dmesg) contient souvent des pointeurs noyau, des adresses mémoire, des détails de chargement de modules et des informations matérielles. Un utilisateur non privilégié qui peut le lire peut contourner KASLR et recueillir des renseignements facilitant la conception d'un exploit noyau. Définir kernel.dmesg_restrict=1 exige la capacité CAP_SYSLOG pour lire le tampon, limitant l'accès à root et réduisant les informations disponibles pour un attaquant local.
Ce que vérifie Pavois
Pavois lit la valeur effective du noyau via la ressource kernel_parameter (équivalent à sysctl kernel.dmesg_restrict), et non /etc/sysctl.conf ou un drop-in *.conf. Une valeur écrite dans un fichier peut n'avoir jamais été chargée (faute de frappe, ordre, drop-in qui l'écrase) ; lire le noyau en cours d'exécution reflète si l'accès dmesg non privilégié est réellement bloqué à l'instant.
describe kernel_parameter('kernel.dmesg_restrict') do
its('value') { should cmp 1 }
end
describe command("grep -hsE '^[[:space:]]*kernel.dmesg_restrict[[: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.dmesg_restrict, sortie attendue kernel.dmesg_restrict = 1. En tant qu'utilisateur non root, dmesg devrait alors échouer avec Operation not permitted.
Inspecter et investiguer
Lisez la valeur courante avec sysctl kernel.dmesg_restrict ou cat /proc/sys/kernel/dmesg_restrict. Le journal du noyau reste accessible à root via dmesg ou journalctl -k ; les lectures non root sont simplement refusées avec EPERM.
Remédiation
Le plan de durcissement de Pavois définit la clé sysctl kernel.dmesg_restrict à 1, la persiste dans un drop-in géré et l'applique à chaud, de sorte que le noyau en cours d'exécution comme les démarrages futurs l'utilisent. Appliqué avec pavois harden apply.
Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :
| key | kernel.dmesg_restrict |
|---|---|
| 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 opérationnel faible. Le seul changement est que les utilisateurs non root ne peuvent plus exécuter dmesg ; les administrateurs et la supervision lancée par root ne sont pas affectés. Certains scripts de diagnostic ou de détection matérielle non privilégiés qui analysent dmesg devront s'exécuter avec des privilèges élevés ou lire journalctl -k en tant que root. Réversible en remettant la clé à 0.
Mapping des normes
| Norme | Référence | Type | Version | Confiance |
|---|---|---|---|---|
| ANSSI BP-028 | R9 | direct | 2.0 | haute |
| NIST | 3.1.5, SI-11(a), SI-11(b) | support | 800-53 Rev 5 · 800-171 Rev 2 (pinned) | moyenne |
| CIS | 1.5.5 | direct | per OS, see the benchmark table | haute |
| DISA STIG | UBTU-22-213010, UBTU-24-600140 | direct | per OS STIG release | 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.