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

Vérifier les permissions des fichiers /var/log/waagent.log(.*)

Garantit que le journal de l'agent invité Azure Linux /var/log/waagent ne porte aucun bit d'exécution, setuid, setgid ou sticky et n'est pas inscriptible par le groupe ou les autres, afin que ses enregistrements ne puissent être altérés.

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.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

/var/log/waagent.log enregistre les événements de l'agent invité Azure Linux, utilisé pour le provisionnement et le diagnostic des instances cloud. Il peut exposer des métadonnées cloud, l'activité des extensions et des détails d'identité de la VM. Si le fichier est inscriptible par le groupe ou les autres, un attaquant peut injecter des entrées trompeuses ou effacer les traces d'une altération de l'agent. Le restreindre garde fiables les diagnostics de la plateforme cloud.

Ce que vérifie Pavois

Pavois lit l'inode réel de /var/log/waagent et vérifie l'absence de bit d'exécution, setuid, setgid ou sticky et d'écriture groupe/autres. Lire l'objet réel du système de fichiers détecte les dérives qu'une vérification de paquet ou de configuration manquerait, le mode effectif est celui qui régit l'accès à l'exécution.

['/var/log/waagent.log'].each do |f|
  next unless file(f).exist?
  describe file(f) do
    it { should_not be_writable.by('group') }
    it { should_not be_readable.by('other') }
    it { should_not be_writable.by('other') }
    it { should_not be_executable.by('other') }
    it { should_not be_setuid }
    it { should_not be_setgid }
  end
end

Comment vérifier qu’elle est appliquée

Exécutez stat -c '%A %U:%G' /var/log/waagent.log. Attendez un mode du type -rw-r----- root:adm (0640 ou plus strict), sans x, s, S, t, T, ni bit d'écriture groupe/autres.

Inspecter et investiguer

Ce fichier est un journal ; inspectez-le avec tail -n 50 /var/log/waagent.log. L'agent lui-même est un service systemd : systemctl status walinuxagent (ou waagent) et journalctl -u walinuxagent. Pour détecter une altération des permissions, ajoutez auditctl -w /var/log/waagent.log -p wa et consultez /var/log/audit/audit.log.

Remédiation

Aucun plan de durcissement automatisé n'est fourni pour cette règle ; elle doit donc être appliquée manuellement : chown root:adm /var/log/waagent.log et chmod u-x,g-wx,o-wx,u-s,g-s,-t /var/log/waagent.log (généralement chmod 0640).

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

commandfor f in /var/log/waagent.log; do [ -e "$f" ] && chmod g-wx,o-rwx "$f"; done; true
namefileperm-var-log-waagent-tighten
not_if! find /var/log/waagent.log -maxdepth 0 \( -perm /g=wx -o -perm /o=rwx \) 2>/dev/null | grep -q .
resourceexec
pavois harden plan local

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

Impact & précautions

Un journal d'agent inscriptible peut être empoisonné ou tronqué, gênant l'analyse d'incident cloud. Précautions : ce fichier n'existe que sur les VM Azure exécutant walinuxagent ; l'agent tourne en root et recrée le fichier, donc après re-permissionnement vérifiez qu'il écrit toujours (systemctl restart walinuxagent puis tail /var/log/waagent.log). La rotation propre à l'agent peut réinitialiser le mode, vérifiez donc périodiquement. Conservez root:adm lisible plutôt que 0600 si votre supervision le lit sous le groupe adm.

Mapping des normes

NormeRéférenceTypeVersionConfiance
CIS6.1.4.1, 6.2.2.1directper 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