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

Vérifier le propriétaire de la bannière Message du jour

Garantit que /etc/motd (le Message du jour post-connexion) appartient à root (UID 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é →
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

Le fichier /etc/motd contient le Message du jour affiché après l'authentification d'un utilisateur. Si un compte non-root le possède, cet utilisateur peut modifier ou remplacer l'avis post-connexion, injectant un contenu trompeur ou malveillant vu par chaque opérateur. Définir root (UID 0) comme propriétaire garantit que seuls les utilisateurs privilégiés peuvent changer la bannière, conformément aux lois, politiques et normes applicables.

Ce que vérifie Pavois

Pavois inspecte le système de fichiers réel via la ressource InSpec file('/etc/motd') et vérifie uid == 0, protégé par only_if afin d'ignorer le test si le fichier est absent. Lire le propriétaire réel de l'inode (plutôt que de se fier à un modèle de déploiement) reflète l'état effectif sur le disque et détecte tout chown post-déploiement. Sur Debian/Ubuntu, le MOTD est souvent assemblé dynamiquement par les scripts /etc/update-motd.d/, mais le /etc/motd statique doit lui aussi appartenir à root.

only_if { file('/etc/motd').exist? }
describe file('/etc/motd') do
  its('uid') { should eq 0 }
end

Comment vérifier qu’elle est appliquée

Exécutez stat -c '%U %u %n' /etc/motd. Sortie attendue : root 0 /etc/motd. Le 0 numérique confirme la règle quel que soit le mappage du service de noms.

Inspecter et investiguer

Les changements de propriétaire ne sont pas journalisés par défaut. Avec le framework d'audit, ajoutez auditctl -w /etc/motd -p wa -k banner puis consultez /var/log/audit/audit.log (filtre grep 'key="banner"'). Le MOTD est rendu à la connexion par PAM (pam_motd), les événements d'affichage apparaissent donc dans /var/log/auth.log / journalctl.

Remédiation

Aucune remédiation automatisée n'est fournie pour cette règle. Appliquez-la manuellement avec chown root /etc/motd (en root ou via sudo) ; le fichier doit rester en groupe root et mode 0644.

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

ownerroot
path/etc/motd
resourcefile
pavois harden plan local

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

Impact & précautions

Un mauvais propriétaire permet à un utilisateur non privilégié de réécrire le message vu par chaque utilisateur authentifié. Risque à l'application : nul en pratique, /etc/motd est un fichier texte statique sans dépendance de service, donc chown root n'affecte pas les connexions. Par précaution, gardez-le lisible par tous (0644) pour que le message s'affiche toujours.

Mapping des normes

NormeRéférenceTypeVersionConfiance
CIS1.6.4, 1.7.4directper OS, see the benchmark tablehaute

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