Vérifier le groupe propriétaire du fichier /etc/cron.allow
Garantit que /etc/cron.allow, la liste des utilisateurs autorisés à utiliser 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.
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.allow décide quels utilisateurs peuvent créer des tâches cron. Si son groupe propriétaire n'est pas root (gid 0), un groupe non privilégié pourrait s'ajouter à la liste d'autorisation et planifier des commandes récurrentes, ou lire la liste des utilisateurs autorisés. Comme les tâches cron s'exécutent sans surveillance, c'est un vecteur courant de persistance et d'élévation de privilèges.
Ce que vérifie Pavois
Pavois lit la propriété effective de /etc/cron.allow 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 (certains systèmes ne s'appuient que sur cron.deny).
only_if { file('/etc/cron.allow').exist? }
describe file('/etc/cron.allow') do
its('group') { should eq 'crontab' }
endComment vérifier qu’elle est appliquée
Exécutez stat -c '%G %g' /etc/cron.allow. 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.allow ou stat /etc/cron.allow. Avec une surveillance auditd (auditctl -w /etc/cron.allow -p wa), les événements chown apparaissent dans /var/log/audit/audit.log. L'exécution des tâches cron est journalisée dans /var/log/syslog / 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.allow (ou chown :root /etc/cron.allow) pour restaurer le groupe propriétaire root.
Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :
| group | crontab |
|---|---|
| path | /etc/cron.allow |
| 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.allow permet à un groupe non privilégié de s'octroyer 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 autorisé ; vérifiez qu'aucun gestionnaire de configuration ne l'annulera, et rappelez-vous que la présence de cron.allow rend cron interdit par défaut, confirmez que tous les utilisateurs cron légitimes y figurent avant de vous y fier.
Mapping des normes
| Norme | Référence | Type | Version | Confiance |
|---|---|---|---|---|
| CIS | 2.2.6, 2.4.1.8, 2.4.1.9 | 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.