Vérifier le groupe propriétaire du fichier /etc/crypttab
Garantit que le fichier /etc/crypttab est détenu par le groupe root.
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
Le fichier /etc/crypttab déclare les périphériques de bloc chiffrés du système, les noms de mappage, les périphériques sous-jacents et les sources de clés utilisées pour les déverrouiller au démarrage. Attribuer la propriété de groupe de ce fichier à root garantit un contrôle exclusif de la configuration de chiffrement : un groupe propriétaire autre que root pourrait permettre à un attaquant de lire l'emplacement des clés ou d'altérer les mappages, compromettant le chiffrement intégral du disque. Attribuer le groupe à root garantit que seuls les comptes hautement privilégiés peuvent influencer la façon dont les volumes chiffrés sont déverrouillés.
Ce que vérifie Pavois
Pavois lit le groupe propriétaire effectif de /etc/crypttab sur le système en cours d'exécution via la ressource InSpec file et vérifie group == 'root'. Il inspecte les métadonnées réelles de l'inode telles que le noyau les voit, et non une valeur par défaut de paquet : un fichier dont la propriété a dérivé après l'installation est donc détecté.
only_if { file('/etc/crypttab').exist? }
describe file('/etc/crypttab') do
its('group') { should eq 'root' }
endComment vérifier qu’elle est appliquée
Exécutez stat -c '%G' /etc/crypttab. Sortie attendue : root. Tout autre nom de groupe 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 /etc/crypttab -p wa -k crypttab-perms, puis examinez grep 'key="crypttab-perms"' /var/log/audit/audit.log. L'activité de déverrouillage des volumes chiffrés au démarrage est visible via systemctl status 'systemd-cryptsetup@*' et journalctl -b -u 'systemd-cryptsetup@*'.
Remédiation
Le plan de durcissement de Pavois utilise la ressource file pour fixer le groupe de /etc/crypttab à root, sans toucher au contenu ni aux permissions. Appliquez-le avec pavois harden apply ; Pavois relit ensuite la propriété effective pour confirmer que la règle passe.
Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :
| group | root |
|---|---|
| path | /etc/crypttab |
| resource | file |
pavois harden plan localoù 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 /etc/crypttab affaiblit la frontière de confiance autour du chiffrement du disque ; rétablir la propriété root n'a aucun impact fonctionnel sur le démarrage ou le montage. Le correctif ne change que la propriété de groupe, ni le contenu ni les mappages de périphériques : les volumes chiffrés se déverrouillent toujours normalement. Précaution : ne modifiez pas les lignes de mappage ni les chemins de fichiers de clés en appliquant la propriété, une entrée crypttab incorrecte peut rendre un volume chiffré non montable au démarrage et bloquer le système ou le basculer en shell de secours.
Mapping des normes
| Norme | Référence | Type | Version | Confiance |
|---|---|---|---|---|
| ANSSI BP-028 | R50 | 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.