Vérifier les permissions sur les fichiers System.map
Garantit que /boot (qui contient les fichiers de symboles noyau System.map) n'est ni lisible, ni modifiable, ni exécutable par le groupe ou les autres.
Vérifié sur le contenu d’un fichier de configuration persistant, la source de vérité qui survit aux redémarrages.
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
Les fichiers System.map associent les noms de symboles du noyau à des adresses mémoire et servent au débogage et au profilage du noyau. Les divulguer fournit à un attaquant les adresses exactes des fonctions et structures du noyau, ce qui contourne KASLR et rend les exploits noyau bien plus fiables. Restreindre l'accès à root (aucune lecture pour le groupe/les autres) garde cette disposition sensible secrète.
Ce que vérifie Pavois
Pavois vérifie les permissions effectives de l'inode de /boot, où résident les fichiers System.map-* du noyau, en s'assurant de l'absence d'accès pour le groupe/les autres et de bits setuid/setgid/sticky. Lire le mode réel (et non un enregistrement de paquet) détecte les dérives introduites par un chmod manuel, des images défectueuses ou des scripts post-installation qu'un manifeste basé sur les fichiers ignorerait.
describe command("find /boot -maxdepth 1 -name 'System.map-*' -perm /077 2>/dev/null") do
its('exit_status') { should_not cmp 124 }
its('stdout.strip') { should eq '' }
endComment vérifier qu’elle est appliquée
Exécutez stat -c '%U %G %a' /boot. Attendu : propriétaire/groupe root avec un mode tel que 700 (ou 0700), c'est-à-dire aucun bit de lecture/écriture/exécution pour le groupe ou les autres, et aucun bit setuid/setgid/sticky positionné.
Inspecter et investiguer
Les dérives de permissions sur les artefacts de démarrage sont signalées par rpm -V kernel (RHEL/Alma) ou en comparant aux métadonnées du paquet sur Debian/Ubuntu. Les détails de montage et d'accès de /boot peuvent être inspectés avec findmnt /boot.
Remédiation
Aucune remédiation automatique n'est fournie pour cette règle. Restreignez le répertoire manuellement avec chmod 700 /boot && chown root:root /boot (ou restreignez les fichiers System.map-* individuels avec chmod 600).
Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :
| command | find /boot -maxdepth 1 -name 'System.map-*' -exec chmod 0600 {} + 2>/dev/null; true |
|---|---|
| name | systemmap-perms |
| not_if | test -z "$(find /boot -maxdepth 1 -name 'System.map-*' -perm /077 2>/dev/null)" |
| resource | exec |
pavois harden plan localoù la cible est local, un alias SSH user@hôte, ou un conteneur , Docs
Impact & précautions
Laisser System.map lisible par tous est un risque de divulgation d'informations qui renforce les exploits noyau, mais la sévérité est faible. Restreindre /boot est sans danger sur la plupart des systèmes. Attention : si /boot est un montage séparé ou une partition EFI, ou si un outil de démarrage/mise à jour non-root doit le lire, un mode trop restrictif peut casser les mises à jour du chargeur d'amorçage (par ex. grub-mkconfig, update-grub), vérifiez qu'ils s'exécutent toujours en root après application.
Mapping des normes
| Norme | Référence | Type | Version | Confiance |
|---|---|---|---|---|
| ANSSI BP-028 | R29 | 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.