Vérifier les permissions des fichiers /var/log/cloud-init.log(.*)
Garantit que /var/log/cloud-init (et ses fichiers de journaux) n'est pas modifiable par le groupe/les autres et ne porte aucun bit d'exécution/setuid/setgid/sticky.
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
cloud-init journalise tout l'approvisionnement au premier démarrage : user-data, configuration réseau et parfois des secrets injectés au déploiement (mots de passe, jetons, clés SSH, métadonnées d'instance). Si des utilisateurs non-root peuvent écrire dans ces journaux, ils peuvent altérer les preuves d'approvisionnement ; si les journaux sont trop exposés, des données d'amorçage sensibles fuitent. L'accès doit être confiné à root afin que ces détails de débogage restent réservés au personnel autorisé.
Ce que vérifie Pavois
Pavois lit le mode effectif de l'inode de /var/log/cloud-init et vérifie l'absence d'écriture groupe/autres et l'absence de bits spéciaux. Lire le mode réel détecte le cas fréquent où une image cloud personnalisée ou un script d'approvisionnement a créé le journal lisible par tous ou modifiable par le groupe, une dérive qu'un manifeste de paquet statique ne révélerait jamais.
['/var/log/cloud-init.log', '/var/log/cloud-init-output.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
endComment vérifier qu’elle est appliquée
Exécutez stat -c '%U %G %a' /var/log/cloud-init et stat -c '%a' /var/log/cloud-init.log. Attendu : propriétaire root, mode 640 ou plus strict, aucune écriture pour le groupe/les autres.
Inspecter et investiguer
Le détail de l'approvisionnement est dans /var/log/cloud-init.log et /var/log/cloud-init-output.log ; l'état de cloud-init est affiché par cloud-init status --long et journalctl -u cloud-init. Re-vérifiez le mode après toute réexécution de cloud-init.
Remédiation
Aucune remédiation automatique n'est fournie pour cette règle. Restreignez manuellement : chown root:adm /var/log/cloud-init.log && chmod 640 /var/log/cloud-init.log et appliquez de même au répertoire /var/log/cloud-init. Le def_log_file_mode de cloud-init (dans /etc/cloud/cloud.cfg) peut définir le mode du journal à la création.
Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :
| command | for f in /var/log/cloud-init.log /var/log/cloud-init-output.log; do [ -e "$f" ] && chmod g-wx,o-rwx "$f"; done; true |
|---|---|
| name | fileperm-var-log-cloud-init-tighten |
| not_if | ! find /var/log/cloud-init.log /var/log/cloud-init-output.log -maxdepth 0 \( -perm /g=wx -o -perm /o=rwx \) 2>/dev/null | grep -q . |
| resource | exec |
pavois harden plan localoù la cible est local, un alias SSH user@hôte, ou un conteneur , Docs
Impact & précautions
Des journaux cloud-init trop exposés peuvent divulguer des secrets d'approvisionnement et permettre aux attaquants d'altérer les preuves de déploiement. Restreindre à root/adm est sans danger. Précaution : sur les systèmes qui réexécutent cloud-init (redéploiements, reconstructions d'image de référence), le journal peut être recréé avec le mode par défaut, définissez def_log_file_mode dans la configuration cloud-init pour que le durcissement persiste au lieu d'être annulé au prochain démarrage.
Mapping des normes
| Norme | Référence | Type | Version | Confiance |
|---|---|---|---|---|
| CIS | 6.1.4.1, 6.2.2.1 | 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.