Vérifier les permissions de la bannière de connexion système
Garantit que /etc/issue n'est pas modifiable par le groupe ou les autres et ne porte aucun bit exécutable, setuid, setgid ou sticky (mode attendu 0644 root:root).
Vérifié sur le contenu d’un fichier de configuration persistant, la source de vérité qui survit aux redémarrages.
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/issue est la bannière pré-connexion affichée sur les terminaux locaux, généralement un message d'usage légalement approuvé. Elle est destinée à être lisible par tous, mais elle ne doit pas être modifiable par le groupe ou les autres : un attaquant capable de l'éditer pourrait retirer l'avertissement légal (affaiblissant les poursuites) ou injecter un texte trompeur facilitant l'ingénierie sociale. Réserver l'écriture à root garantit que l'avis affiché est authentique et conforme à la politique.
Ce que vérifie Pavois
Pavois lit les permissions réelles de l'inode /etc/issue avec la ressource InSpec file (un stat), sous only_if. La lecture par tous est autorisée (la bannière est affichée à quiconque au prompt de connexion), mais l'écriture groupe, l'écriture autres et tout bit exécutable/setuid/setgid/sticky font échouer la règle, exigeant de fait 0644 root:root. Contrôler le mode réel détecte un faux pas de chmod ou un déploiement ayant relâché le fichier qu'une hypothèse de défaut de paquet manquerait.
only_if { file('/etc/issue').exist? }
describe file('/etc/issue') 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_setgid }
it { should_not be_executable.by('other') }
it { should_not be_writable.by('other') }
it { should_not be_sticky }
endComment vérifier qu’elle est appliquée
Exécutez stat -c '%a %U %G' /etc/issue. La sortie attendue est le mode 644 appartenant à root root, soit 644 root root. Tout droit d'écriture groupe/autres ou bit spécial fait échouer la règle.
Inspecter et investiguer
Il n'existe pas de journal de service pour un fichier de bannière statique ; vérifiez-le directement avec stat /etc/issue et affichez la bannière avec cat /etc/issue. Si auditd surveille /etc/issue, les modifications apparaissent dans /var/log/audit/audit.log. La bannière est rendue par getty/agetty au prompt de connexion.
Remédiation
Aucune remédiation automatique n'est définie ; appliquez-la manuellement : chmod u-x,g-wx,o-wx /etc/issue && chown root:root /etc/issue (cible 0644 root:root). Aucun redémarrage de service n'est nécessaire ; le prochain prompt de connexion lit le fichier corrigé.
Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :
| mode | 0644 |
|---|---|
| path | /etc/issue |
| resource | file |
pavois harden plan localoù la cible est local, un alias SSH user@hôte, ou un conteneur , Docs
Impact & précautions
Rétablir 0644 root:root est très peu risqué, c'est le mode standard et la bannière doit rester lisible par tous pour s'afficher. Ne retirez pas la lecture par tous, sous peine que le prompt de connexion n'affiche rien. Conservez le propriétaire root. Aucun risque de blocage. Laisser le fichier modifiable par un non-root permet à un attaquant de supprimer l'avis légal ou d'y placer un texte trompeur avant l'authentification.
Mapping des normes
| Norme | Référence | Type | Version | Confiance |
|---|---|---|---|---|
| CIS | 1.6.5, 1.7.5 | direct | per OS, see the benchmark table | 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.