Vérifier le groupe propriétaire de cron.deny
Garantit que /etc/cron.deny, la liste des utilisateurs privés de cron, a root (gid 0) pour groupe propriétaire.
Vérifié sur les métadonnées d’un chemin, mode, propriétaire, groupe, SUID/SGID.
Pourquoi cette règle
/etc/cron.deny liste les utilisateurs interdits de créer des tâches cron. Si son groupe propriétaire n'est pas root (gid 0), un groupe non privilégié pourrait modifier le fichier pour retirer sa propre entrée et retrouver l'accès à cron, contournant la liste d'interdiction. Comme les tâches cron s'exécutent sans surveillance, cela permet la persistance et l'élévation de privilèges.
Ce que vérifie Pavois
Pavois lit la propriété effective de /etc/cron.deny depuis l'inode (via stat) et vérifie gid == 0. Contrôler l'inode réel détecte la dérive due aux mises à jour de paquets ou aux modifications manuelles plutôt que de se fier à un modèle. La garde only_if ignore le contrôle lorsque le fichier est absent (les systèmes durcis utilisent souvent cron.allow à la place et suppriment cron.deny).
only_if { file('/etc/cron.deny').exist? }
describe file('/etc/cron.deny') do
its('gid') { should eq 0 }
endComment vérifier qu’elle est appliquée
Exécutez stat -c '%G %g' /etc/cron.deny. Sortie attendue : root 0. Si le fichier n'existe pas, le contrôle est ignoré.
Inspecter et investiguer
Les changements de propriété ne sont pas journalisés par défaut. Inspectez avec ls -l /etc/cron.deny ou stat /etc/cron.deny. Avec une surveillance auditd (auditctl -w /etc/cron.deny -p wa), les événements chown apparaissent dans /var/log/audit/audit.log. L'exécution des tâches cron est visible dans journalctl -u crond sur RHEL 9.
Remédiation
Aucun plan de durcissement automatisé n'est encore défini pour cette règle ; elle doit donc être appliquée manuellement : exécutez chgrp root /etc/cron.deny (ou chown :root /etc/cron.deny) pour restaurer le groupe propriétaire root.
Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :
| group | root |
|---|---|
| path | /etc/cron.deny |
| resource | file |
pavois harden plan localoù la cible est local, un alias SSH user@hôte, ou un conteneur , Docs
Impact & précautions
Un mauvais groupe propriétaire sur /etc/cron.deny permet à un groupe non privilégié de modifier la liste d'interdiction et de retrouver l'accès à cron, une voie vers la persistance et l'élévation de privilèges. Précautions : restaurer la propriété de groupe root est peu risqué et ne change pas qui est actuellement interdit. Vérifiez qu'aucun gestionnaire de configuration ne l'annulera. Notez que cron.allow, lorsqu'il est présent, a priorité sur cron.deny ; préférez un modèle de liste d'autorisation pour un contrôle plus strict.