Désactiver l'acquisition, l'enregistrement et le traitement des vidages mémoire (core dumps)
Garantit que systemd-coredump.service est désactivé et arrêté afin que les vidages mémoire des applications ne soient ni acquis, ni enregistrés, ni traités.
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.
Pourquoi cette règle
Un vidage mémoire (core dump) est une image de la mémoire capturée lorsque le système termine une application en cours de plantage. Cette image peut contenir des données très sensibles, mots de passe, clés de chiffrement, jetons, données personnelles, et n'est généralement utile qu'aux développeurs déboguant le programme. Laisser systemd-coredump actif signifie que ces instantanés mémoire sont écrits sur disque où ils peuvent être lus par un attaquant ou divulguer des secrets. Désactiver la collecte des core dumps réduit l'exposition des secrets en mémoire et supprime un vecteur de divulgation d'informations.
Ce que vérifie Pavois
Pavois lit l'état effectif de l'unité via service('systemd-coredump.service') (systemctl is-enabled / is-active). Sur la plupart des systèmes, ce service est activé par socket (systemd-coredump.socket), donc le contrôle confirme qu'il ne sera pas déclenché. C'est plus fiable que de chercher kernel.core_pattern dans /etc/sysctl.d/, car l'état effectif tient compte du masquage et des surcharges drop-in sous /etc/systemd/system/.
describe command('systemd-analyze cat-config systemd/coredump.conf 2>/dev/null | grep -iE "^[[:space:]]*Storage[[:space:]]*=" | tail -1') do
its('stdout') { should match(/=\s*none/i) }
endComment vérifier qu’elle est appliquée
Exécutez systemctl is-enabled systemd-coredump.service (attendu disabled, masked ou static) et systemctl is-active systemd-coredump.service (attendu inactive). Vous pouvez confirmer en outre que le noyau ne l'invoquera pas avec sysctl kernel.core_pattern (il ne doit pas pointer vers systemd-coredump).
Inspecter et investiguer
Consultez journalctl -u systemd-coredump.service et coredumpctl list, une fois désactivé, aucun nouveau vidage ne doit apparaître après un plantage. Le routage effectif du noyau est donné par sysctl kernel.core_pattern ; une entrée mentionnant systemd-coredump signifie que des vidages sont encore capturés.
Remédiation
Le plan de durcissement de Pavois agit sur la ressource service nommée systemd-coredump : il exécute disable (pour qu'il ne soit pas déclenché au boot) et stop (pour qu'il ne tourne pas maintenant). Il s'applique avec pavois harden apply. Pour une suppression complète, associez-le à une politique sysctl kernel.core_pattern / fs.suid_dumpable=0 et à des limites dans /etc/security/limits.conf.
Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :
| content | [Coredump] Storage=none ProcessSizeMax=0 |
|---|---|
| group | root |
| mode | 0644 |
| owner | root |
| path | /etc/systemd/coredump.conf.d/99-pavois.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 le traitement des core dumps signifie que les plantages ne produisent plus de vidages pour coredumpctl, ce qui supprime une aide au débogage pour les développeurs. C'est acceptable sur des hôtes de production ou durcis, mais cela peut compliquer l'analyse de cause racine de plantages récurrents. Précautions : si vous déboguez activement un service, réactivez temporairement, capturez le vidage sur un hôte contrôlé, puis désactivez à nouveau, et ne stockez jamais de vidages contenant des secrets sur un stockage partagé ou sauvegardé.