Vérifier les permissions de la bannière du message du jour (MOTD)
Garantit que /etc/motd n'est ni modifiable, ni exécutable, ni setuid/setgid ni sticky pour le groupe ou les autres, afin que seul root puisse modifier la bannière du message du jour.
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
L'affichage d'une notification d'utilisation normalisée et approuvée avant l'accès au système d'exploitation garantit que le texte de notification de confidentialité et de sécurité reste conforme aux lois, directives, politiques, réglementations et normes applicables. La bannière /etc/motd est présentée aux utilisateurs après leur authentification sur la console ou via SSH. Si le fichier est modifiable par le groupe ou par tous, un utilisateur non privilégié pourrait le réécrire pour tromper les administrateurs ou supprimer la mention légale ; les bits setuid/setgid/exécutable n'ont aucune utilité sur un fichier texte et ne font qu'élargir la surface d'attaque. Restreindre les permissions garantit que seul root peut modifier la bannière.
Ce que vérifie Pavois
Pavois lit les bits de mode réels de /etc/motd sur la cible (exécutable/setuid/setgid/sticky/modifiable par groupe et autres) plutôt qu'une base documentée. Les permissions résident dans l'inode, l'audit reflète donc l'état effectif sur le disque, sans include ni drop-in pour le tromper. La garde only_if ignore le contrôle si le fichier est absent.
only_if { file('/etc/motd').exist? }
describe file('/etc/motd') 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/motd. Attendu : mode -rw-r--r-- (0644) appartenant à root root, sans bit d'écriture pour le groupe/les autres ni bits s/t. Vérification rapide : find /etc/motd -perm /0133 ne doit rien renvoyer.
Inspecter et investiguer
Les changements de permissions ne sont pas journalisés par défaut. Pour détecter une altération, surveillez le fichier avec auditd : auditctl -w /etc/motd -p wa -k banner, puis consultez les événements avec grep 'key="banner"' /var/log/audit/audit.log. Sur les systèmes utilisant pam_motd/update-motd, la bannière rendue peut provenir de /etc/update-motd.d/ ; la propriété et le mode actuels s'affichent avec stat /etc/motd.
Remédiation
Aucun plan de durcissement automatisé n'est fourni pour cette règle, elle doit donc être appliquée manuellement : chown root:root /etc/motd && chmod 0644 /etc/motd. Cela supprime toute écriture groupe/autres et tout bit setuid/setgid/sticky tout en gardant la bannière lisible par tous.
Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :
| mode | 0644 |
|---|---|
| path | /etc/motd |
| resource | file |
pavois harden plan localoù la cible est local, un alias SSH user@hôte, ou un conteneur , Docs
Impact & précautions
Risque si mal réglé : un utilisateur non-root peut réécrire la bannière post-connexion vue par chaque utilisateur et administrateur, supprimant le texte légal ou plaçant un message trompeur. Appliquer le correctif est peu risqué : 0644 root:root est le mode conventionnel. Précaution : conservez le bit de lecture pour other afin que le MOTD s'affiche toujours ; sur Debian/Ubuntu le MOTD dynamique généré sous /etc/update-motd.d/ est un sujet distinct et ses scripts doivent rester la propriété de root.
Mapping des normes
| Norme | Référence | Type | Version | Confiance |
|---|---|---|---|---|
| CIS | 1.6.4, 1.7.4 | 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.