Vérifier le groupe propriétaire de cron.yearly
Garantit que le répertoire /etc/cron.yearly est détenu par le groupe root (gid 0).
Vérifié sur les métadonnées d’un chemin, mode, propriétaire, groupe, SUID/SGID.
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 répertoire /etc/cron.yearly contient des scripts que le démon cron exécute en tant que root une fois par an. S'il est détenu par un groupe non privilégié, un membre de ce groupe pourrait y déposer ou y modifier un script et obtenir l'exécution de commandes arbitraires en root. Restreindre la propriété de groupe à root (gid 0) garantit que seuls les comptes hautement privilégiés peuvent modifier ce qui s'exécute chaque année.
Ce que vérifie Pavois
Pavois lit le groupe propriétaire effectif de /etc/cron.yearly sur le système en cours d'exécution via la ressource InSpec file et vérifie gid == 0. Il inspecte les métadonnées réelles de l'inode telles que le noyau les voit, et non une valeur par défaut de paquet : un répertoire dont la propriété a dérivé après l'installation est donc détecté.
only_if { file('/etc/cron.yearly').exist? }
describe file('/etc/cron.yearly') do
its('gid') { should eq 0 }
endComment vérifier qu’elle est appliquée
Exécutez stat -c '%G %g' /etc/cron.yearly. Sortie attendue : root 0. Tout autre nom de groupe ou gid non nul signifie que la règle n'est pas appliquée.
Inspecter et investiguer
Les changements de propriété ne sont pas journalisés par défaut. Surveillez le répertoire avec auditd : auditctl -w /etc/cron.yearly -p wa -k cron-perms, puis examinez grep 'key="cron-perms"' /var/log/audit/audit.log. Les exécutions annuelles apparaissent dans journalctl -u crond (famille RHEL).
Remédiation
Aucune remédiation automatique n'est définie pour cette règle ; elle doit donc être appliquée manuellement. Rétablissez le bon groupe propriétaire avec chgrp root /etc/cron.yearly.
Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :
| group | root |
|---|---|
| path | /etc/cron.yearly |
| resource | file |
pavois harden plan localoù la cible est local, un alias SSH user@hôte, ou un conteneur , Docs
Impact & précautions
Un groupe propriétaire autre que root sur /etc/cron.yearly permet aux membres du groupe d'y déposer des scripts exécutés en root, une voie directe d'élévation de privilèges. Le correctif présente peu de risques : chgrp root ne change que la propriété de groupe, ni les permissions ni le contenu, et cron continue de fonctionner. Précaution : vérifiez qu'aucun outil légitime ne dépend d'un groupe personnalisé sur ce répertoire avant de le modifier.
Mapping des normes
| Norme | Référence | Type | Version | Confiance |
|---|---|---|---|---|
| CIS | 2.4.1.7 | 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.