Vidages mémoire (core dumps) désactivés (limits hard core 0)
Impose une limite stricte (hard) de 0 sur la taille des fichiers de vidage mémoire pour tous les utilisateurs via * hard core 0 dans les limites PAM, empêchant les processus d'écrire des dumps mémoire sur disque.
Vérifié sur le contenu d’un fichier de configuration persistant, la source de vérité qui survit aux redémarrages.
Pourquoi cette règle
Un vidage mémoire (core dump) est une copie de la mémoire d'un processus écrite sur disque lorsqu'il plante. Cette mémoire peut contenir des mots de passe, clés privées, jetons de session et autres secrets détenus en clair par l'application. Si les core dumps sont illimités, tout plantage (ou un attaquant qui fait délibérément planter un service) peut fuiter ces secrets dans un fichier lisible ensuite, et des dumps volumineux peuvent saturer le système de fichiers (déni de service). Une limite stricte à 0 supprime cette exposition.
Ce que vérifie Pavois
Pavois recherche dans la configuration PAM effective, /etc/security/limits.conf et chaque drop-in sous /etc/security/limits.d/, la directive * hard core 0. Inspecter le répertoire (et pas seulement le fichier principal) permet de détecter la règle lorsqu'elle est livrée sous forme de drop-in, ce qu'un contrôle limité à limits.conf raterait.
describe command('grep -rqE \'^\\*[[:space:]]+hard[[:space:]]+core[[:space:]]+0\' /etc/security/limits.conf /etc/security/limits.d/ 2>/dev/null && echo ok || echo ko') do
its('stdout.strip') { should eq 'ok' }
endComment vérifier qu’elle est appliquée
Lancez grep -rE '^\*[[:space:]]+hard[[:space:]]+core[[:space:]]+0' /etc/security/limits.conf /etc/security/limits.d/. Une ligne correspondante doit s'afficher. Vous pouvez aussi confirmer la valeur effective avec ulimit -Hc dans un shell de connexion neuf, qui doit renvoyer 0.
Inspecter et investiguer
Il n'existe pas de journal dédié. Vérifiez la limite active avec ulimit -Hc (par shell) et le motif de core du noyau avec sysctl kernel.core_pattern. Les plantages gérés par systemd apparaissent via coredumpctl list (qui ne doit plus rien afficher de nouveau une fois les dumps désactivés).
Remédiation
Aucune remédiation automatisée n'est encore fournie pour cette règle, elle doit donc être appliquée manuellement : ajoutez la ligne * hard core 0 dans un fichier sous /etc/security/limits.d/ (par ex. 99-Pavois.conf). Pour une couverture complète, définissez aussi kernel.core_pattern via sysctl et désactivez systemd-coredump.
Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :
| content | * hard core 0 |
|---|---|
| group | root |
| mode | 0644 |
| owner | root |
| path | /etc/security/limits.d/99-pavois-core.conf |
| resource | file |
pavois harden plan localoù la cible est local, un alias SSH user@hôte, ou un conteneur , Docs
Impact & précautions
Désactiver les core dumps présente un risque opérationnel très faible. La principale conséquence est que les développeurs et équipes support perdent les dumps de plantage post-mortem utilisés pour déboguer les applications natives. Avant d'appliquer sur un système où vous diagnostiquez activement des plantages, assurez-vous d'avoir une alternative (reproduire en laboratoire contrôlé, ou autoriser temporairement les dumps pour un service précis). Pour des serveurs de production, c'est sûr et recommandé.