Vérifier le propriétaire du fichier /boot/grub2/user.cfg
Garantit que /boot/grub2/user.cfg, qui stocke le hachage du mot de passe superutilisateur GRUB 2, est détenu par 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
Seul root doit pouvoir modifier les paramètres de démarrage importants. Le fichier /boot/grub2/user.cfg contient le hachage du mot de passe superutilisateur GRUB 2 (PBKDF2). Si un utilisateur non-root peut le lire ou le réécrire, il peut extraire le hachage pour le casser hors ligne, ou le remplacer pour prendre le contrôle non autorisé du menu de démarrage, ce qui annule la protection empêchant la falsification des arguments de la ligne de commande du noyau (par ex. ajouter init=/bin/bash pour obtenir un shell root).
Ce que vérifie Pavois
Pavois vérifie que l'UID propriétaire de /boot/grub2/user.cfg est 0 (root), mais uniquement lorsque le fichier existe réellement (only_if), car il n'est créé que lorsqu'un mot de passe GRUB est configuré. Le contrôle inspecte le propriétaire effectif rapporté par le système de fichiers (les métadonnées stat lues en direct par CINC sur la cible), pas un modèle de configuration ni un manifeste de paquet, il reflète donc l'état réel sur le disque, quelle que soit la façon dont le fichier a été créé.
only_if { file('/boot/grub/user.cfg').exist? }
describe file('/boot/grub/user.cfg') do
its('uid') { should eq 0 }
endComment vérifier qu’elle est appliquée
Confirmez le propriétaire avec :
stat -c '%U %u' /boot/grub2/user.cfg
La sortie attendue est root 0. Le fichier est conforme lorsque l'UID numérique est 0.
Inspecter et investiguer
Il n'existe pas de journal de service pour la propriété d'un fichier. Auditez les accès et changements via les métadonnées du système de fichiers :
stat /boot/grub2/user.cfg
ls -l /boot/grub2/user.cfg
Si le cadre de surveillance de fichiers d'auditd est activé, les changements de propriété (chown) peuvent être suivis en recherchant le chemin dans le journal d'audit brut :
grep 'user.cfg' /var/log/audit/audit.log
Remédiation
Aucun plan de remédiation automatisé n'est défini pour cette règle ; elle doit donc être appliquée manuellement. Restaurez la propriété root avec :
chown root:root /boot/grub2/user.cfg
(pavois harden apply ne modifiera pas ce fichier tant qu'une ressource de remédiation n'aura pas été ajoutée à la règle.)
Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :
| owner | root |
|---|---|
| path | /boot/grub/user.cfg |
| resource | file |
pavois harden plan localoù la cible est local, un alias SSH user@hôte, ou un conteneur , Docs
Impact & précautions
Conséquences en cas de mauvaise configuration : un hachage lisible peut être cassé hors ligne ; un fichier modifiable permet à un attaquant de réinitialiser le mot de passe superutilisateur GRUB et de déverrouiller le menu de démarrage, menant à un accès mono-utilisateur/root ou à la falsification des paramètres du noyau.
Précautions avant application : remettre le propriétaire à root est sans impact, GRUB s'exécute toujours en root au démarrage, donc aucun processus légitime ne perd l'accès. Ne modifiez pas le mot de passe GRUB lui-même en corrigeant la propriété, et après tout changement d'identifiant GRUB conservez une entrée valide : un mot de passe superutilisateur sans --unrestricted bloque chaque démarrage et peut rendre inutilisable un hôte sans écran (il se fige à l'invite GRUB). Vérifiez que vous pouvez toujours démarrer avant de considérer le système comme durci.
Mapping des normes
| Norme | Référence | Type | Version | Confiance |
|---|---|---|---|---|
| ANSSI BP-028 | R29 | direct | 2.0 | haute |
| CIS | 2.2.6, 1.4.2 | direct | per OS, see the benchmark table | haute |
| NIST | 3.4.5, AC-6(1), CM-6(a) | support | 800-53 Rev 5 · 800-171 Rev 2 (pinned) | moyenne |
| PCI DSS | 2.2.6 | support | 4.0.1 | moyenne |
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.