← Toutes les règles
SOCLE-CLD-FSP-134// File permissionsmoyenneconfig persistante

Vérifier les permissions du fichier /etc/crypttab

Garantit que /etc/crypttab appartient à root et n'est ni lisible ni modifiable par le groupe ou les autres, sans bit exécutable, setuid, setgid ou sticky.

Vérifié sur le contenu d’un fichier de configuration persistant, la source de vérité qui survit aux redémarrages.

Un PASS prouve? actif maintenant✓ sur disque✓ survit au rebootle verdict qualifié →
Debian 12CIS 1.1.0Debian 13CIS 1.0.0FedoraRHEL 10 / Rocky 10 / AlmaLinux 10RHEL 8 / Rocky 8 / AlmaLinux 8CIS 4.0.0RHEL 9 / Rocky 9 / AlmaLinux 9CIS 2.0.0Ubuntu 22.04CIS 3.0.0Ubuntu 24.04CIS 1.0.0Ubuntu 26.04
Un seul check, mappé sur 1 norme

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

/etc/crypttab déclare les périphériques bloc chiffrés déverrouillés au démarrage, leurs correspondances, options et, surtout, le chemin des fichiers de clés. S'il est lisible par le groupe ou les autres, un attaquant découvre l'emplacement des clés de chiffrement de disque et l'agencement des volumes protégés ; s'il est modifiable par un non-root, il peut rediriger une correspondance vers un périphérique qu'il contrôle ou affaiblir les options de chiffrement. Le restreindre à root garde la configuration de chiffrement confidentielle et inaltérable.

Ce que vérifie Pavois

Pavois lit les permissions réelles de l'inode /etc/crypttab avec la ressource InSpec file (un stat), sous only_if pour ignorer les hôtes sans chiffrement de disque. Elle exige un mode effectif au plus permissif égal à 0600 root:root, aucune lecture ni écriture groupe/autres, aucun bit spécial. Inspecter les permissions réelles détecte une dérive due à une édition manuelle ou une restauration, qu'une hypothèse de défaut de paquet manquerait.

only_if { file('/etc/crypttab').exist? }
describe file('/etc/crypttab') do
  it { should_not be_executable.by('owner') }
  it { should_not be_setuid }
  it { should_not be_executable.by('group') }
  it { should_not be_writable.by('group') }
  it { should_not be_readable.by('group') }
  it { should_not be_setgid }
  it { should_not be_executable.by('other') }
  it { should_not be_writable.by('other') }
  it { should_not be_readable.by('other') }
  it { should_not be_sticky }
end

Comment vérifier qu’elle est appliquée

Exécutez stat -c '%a %U %G' /etc/crypttab. La sortie attendue est le mode 600 (ou plus strict) appartenant à root root, par ex. 600 root root. Toute lecture ou écriture groupe/autres, ou un bit spécial, fait échouer la règle.

Inspecter et investiguer

Crypttab est exploité par systemd-cryptsetup au démarrage ; vérifiez systemctl status 'systemd-cryptsetup@*' et journalctl -b -u 'systemd-cryptsetup@*' pour confirmer le déverrouillage des volumes après une modification. Il n'existe pas de journal dédié à la permission elle-même, vérifiez-la avec stat / getfacl /etc/crypttab.

Remédiation

Aucune remédiation automatique n'est définie ; appliquez-la manuellement : chmod 0600 /etc/crypttab && chown root:root /etc/crypttab. Aucun rechargement de service n'est nécessaire ; les nouvelles permissions prennent effet immédiatement et sont lues au prochain démarrage.

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

mode0600
path/etc/crypttab
resourcefile
pavois harden plan local

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

Impact & précautions

Le durcissement à 0600 root:root est sûr, seul le processus de démarrage (en root) lit /etc/crypttab. Le changement de permissions ne présente aucun risque de blocage. Précaution : ne modifiez pas le contenu du fichier pendant le durcissement ; un crypttab mal formé peut empêcher le montage des volumes chiffrés au prochain démarrage. Testez sur une fenêtre de redémarrage non critique si l'hôte utilise root-sur-LUKS. Laisser le fichier lisible par tous expose les chemins des fichiers de clés à n'importe quel utilisateur local.

Mapping des normes

NormeRéférenceTypeVersionConfiance
ANSSI BP-028R50direct2.0haute

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