Vérifier l'utilisateur propriétaire des fichiers System.map
Garantit que le répertoire /boot (qui contient System.map et le noyau) appartient à root (uid 0).
Vérifié sur les métadonnées d’un chemin, mode, propriétaire, groupe, SUID/SGID.
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 (sous /boot) associent les symboles du noyau à des adresses et existent principalement pour le débogage et le profilage. Exposés à un attaquant, ils révèlent l'agencement exact du noyau, facilitant le développement d'exploits fiables (par ex. contourner KASLR ou localiser des fonctions pour un rootkit). Le répertoire /boot contient aussi le noyau, l'initramfs et la configuration du chargeur d'amorçage. S'ils appartiennent à un utilisateur non-root, ils peuvent être lus à des fins de reconnaissance ou modifiés pour compromettre la chaîne de démarrage. Conserver /boot sous la propriété de root (uid 0) réserve ce matériel sensible au superutilisateur.
Ce que vérifie Pavois
Pavois vérifie que le répertoire réel /boot a l'uid de propriétaire 0, ignoré via only_if s'il est absent. Il lit le propriétaire effectif depuis le système de fichiers (stat), de sorte qu'un chown manuel sur le matériel de démarrage est détecté même si aucun outil de gestion de configuration ne signale de dérive.
describe command("find /boot -maxdepth 1 -name 'System.map-*' ! -user root 2>/dev/null") do
its('stdout.strip') { should eq '' }
endComment vérifier qu’elle est appliquée
Exécutez stat -c '%U %u' /boot. Sortie attendue : root 0. Pour couvrir spécifiquement les fichiers System.map, exécutez find /boot -name 'System.map*' -not -user root, il ne doit rien afficher.
Inspecter et investiguer
La propriété ne génère pas de journal continu ; interrogez-la avec stat /boot. Si /boot est surveillé par auditd (auditctl -w /boot -p wa), les changements de propriété ou de contenu apparaissent dans /var/log/audit/audit.log, recherchez directement dans le journal brut, par ex. grep System.map /var/log/audit/audit.log.
Remédiation
Aucun plan de durcissement automatisé n'est défini, appliquez-la donc manuellement : chown root:root /boot et, pour les tables de symboles, chown root:root /boot/System.map*.
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 chown root {} + 2>/dev/null; true |
|---|---|
| name | systemmap-user |
| not_if | test -z "$(find /boot -maxdepth 1 -name 'System.map-*' ! -user root 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
Un propriétaire non-root de /boot peut lire l'agencement des symboles du noyau (aidant au développement d'exploits) ou falsifier la chaîne de démarrage. Restaurer la propriété root est sans danger et n'affecte pas un système en fonctionnement. Précaution : en corrigeant la propriété, n'assouplissez pas les permissions, les fichiers System.map et l'image du noyau doivent rester lisibles uniquement par root (mode 0600/0644 selon le référentiel) afin que l'agencement des symboles ne soit pas divulgué ; évitez chown -R sur une partition EFI montée séparément (/boot/efi est généralement en VFAT et insensible au propriétaire).
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.