Vérifier le groupe propriétaire de cron.daily
Garantit que /etc/cron.daily, le répertoire des scripts cron quotidiens exécutés en root, a root (gid 0) pour groupe propriétaire.
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
/etc/cron.daily est un répertoire de scripts que cron exécute en tant que root chaque jour. Si son groupe propriétaire n'est pas root (gid 0), un groupe non privilégié pourrait ajouter, modifier ou remplacer un script et le faire exécuter avec les privilèges root à la prochaine exécution, une voie directe et fiable d'élévation de privilèges et de persistance.
Ce que vérifie Pavois
Pavois lit la propriété effective de /etc/cron.daily 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 répertoire est absent.
only_if { file('/etc/cron.daily').exist? }
describe file('/etc/cron.daily') do
its('gid') { should eq 0 }
endComment vérifier qu’elle est appliquée
Exécutez stat -c '%G %g' /etc/cron.daily. Sortie attendue : root 0. Pour auditer les scripts contenus : find /etc/cron.daily ! -group root. Si le répertoire 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 -ld /etc/cron.daily ou stat /etc/cron.daily. Avec une surveillance auditd (auditctl -w /etc/cron.daily -p wa), les événements chown apparaissent dans /var/log/audit/audit.log. L'exécution des tâches quotidiennes est visible dans journalctl -u cron (Debian) ou journalctl -u crond (RHEL).
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.daily (ou chown :root /etc/cron.daily) pour restaurer le groupe propriétaire root ; envisagez chgrp -R root /etc/cron.daily pour couvrir les scripts à l'intérieur.
Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :
| group | root |
|---|---|
| path | /etc/cron.daily |
| 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.daily permet à un groupe non privilégié de déposer un script exécuté en root, ouvrant la voie à l'élévation de privilèges et à la persistance. Précautions : restaurer la propriété de groupe root est sûr et n'affecte pas les tâches légitimes existantes. Vérifiez qu'aucun paquet ni gestionnaire de configuration ne l'annulera ; inspectez le contenu du répertoire à la recherche de scripts déjà déposés avant de resécuriser.
Mapping des normes
| Norme | Référence | Type | Version | Confiance |
|---|---|---|---|---|
| CIS | 2.2.6, 2.4.1.4 | direct | per OS, see the benchmark table | haute |
| NIST | AC-6(1), CM-6(a) | support | 800-53 Rev 5 · 800-171 Rev 2 (pinned) | moyenne |
| PCI DSS | 2.2.6 | support | 4.0.1 | moyenne |
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.