← Toutes les règles
SOCLE-CLD-FSP-018// File ownershipmoyenneétat du système de fichiers

Vérifier le groupe propriétaire de /boot/efi/EFI/redhat/user.cfg

Garantit que le fichier de mot de passe GRUB UEFI /boot/efi/EFI/redhat/user.cfg est détenu par le groupe root (gid 0).

Vérifié sur les métadonnées d’un chemin, mode, propriétaire, groupe, SUID/SGID.

Un PASS prouve✓ actif maintenant✓ sur disque✓ survit au rebootle verdict qualifié →
FedoraRHEL 10 / Rocky 10 / AlmaLinux 10RHEL 8 / Rocky 8 / AlmaLinux 8CIS 4.0.0RHEL 9 / Rocky 9 / AlmaLinux 9CIS 2.0.0
Un seul check, mappé sur 3 normes

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

Le fichier UEFI user.cfg (/boot/efi/EFI/redhat/user.cfg) stocke généralement le hachage du mot de passe du chargeur GRUB qui protège l'édition des entrées de démarrage et de la ligne de commande du noyau. Le groupe root est hautement privilégié et le groupe propriétaire de ce fichier ne devrait de toute façon disposer d'aucun privilège d'accès. Si un groupe autre que root le détient, ses membres pourraient lire les paramètres de démarrage et le hachage du mot de passe pour identifier des faiblesses et les exploiter au démarrage, avant que tout contrôle de sécurité au niveau de l'OS ne soit actif.

Ce que vérifie Pavois

Pavois lit le groupe propriétaire effectif de /boot/efi/EFI/redhat/user.cfg sur le système en cours d'exécution via la ressource InSpec file et vérifie gid == 0. Il inspecte les métadonnées réelles de l'inode telles que le noyau les voit sur la partition système EFI montée, et non une valeur par défaut de paquet : une dérive après installation est donc détectée. Le contrôle est ignoré (only_if) lorsque le fichier est absent (par exemple aucun mot de passe GRUB défini, ou amorçage BIOS).

only_if { file('/boot/efi/EFI/redhat/user.cfg').exist? }
describe file('/boot/efi/EFI/redhat/user.cfg') do
  its('gid') { should eq 0 }
end

Comment vérifier qu’elle est appliquée

Exécutez stat -c '%G %g' /boot/efi/EFI/redhat/user.cfg. Sortie attendue : root 0. Tout autre nom de groupe ou gid non nul signifie que la règle n'est pas appliquée.

Inspecter et investiguer

Les changements de propriété ne sont pas journalisés par défaut. Surveillez le fichier avec auditd : auditctl -w /boot/efi/EFI/redhat/user.cfg -p wa -k grub-perms, puis examinez grep 'key="grub-perms"' /var/log/audit/audit.log. L'activité du chargeur d'amorçage est visible dans le tampon noyau (dmesg) et journalctl -b après un redémarrage.

Remédiation

Aucune remédiation automatique n'est définie pour cette règle ; elle doit donc être appliquée manuellement. Rétablissez le bon groupe propriétaire avec chgrp root /boot/efi/EFI/redhat/user.cfg.

Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :

grouproot
path/boot/efi/EFI/redhat/user.cfg
resourcefile
pavois harden plan local

où la cible est local, un alias SSH user@hôte, ou un conteneur , Docs

Impact & précautions

Un groupe propriétaire autre que root sur user.cfg expose le hachage du mot de passe GRUB et les paramètres de démarrage, utile à un attaquant préparant une compromission au démarrage. Le correctif présente peu de risques : chgrp root ne change que la propriété de groupe, pas le contenu, et n'affecte ni le démarrage ni le mot de passe enregistré. Précaution : la partition système EFI est généralement en VFAT et ne stocke pas la propriété Unix ; chgrp prend alors effet via les options de montage (gid=/umask= dans /etc/fstab). Associez-le à des permissions restrictives (0600/0700) pour que le hachage ne soit pas lisible par tous, et ne supprimez ni ne réécrivez le fichier, uniquement sa propriété.

Mapping des normes

NormeRéférenceTypeVersionConfiance
ANSSI BP-028R29direct2.0haute
CIS1.4.2directper OS, see the benchmark tablehaute
NIST3.4.5support800-53 Rev 5 · 800-171 Rev 2 (pinned)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.

Sources & références