Vérifier le groupe propriétaire de crontab
Garantit que le fichier /etc/crontab 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 fichier /etc/crontab est la table cron à l'échelle du système : chaque tâche qui y figure s'exécute en tant que root (ou sous l'utilisateur indiqué) selon une planification. Si le fichier est détenu par un groupe non privilégié, un membre de ce groupe pourrait modifier une tâche 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 les commandes planifiées.
Ce que vérifie Pavois
Pavois lit le groupe propriétaire effectif de /etc/crontab 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 fichier dont la propriété a dérivé après l'installation est donc détecté.
only_if { file('/etc/crontab').exist? }
describe file('/etc/crontab') do
its('gid') { should eq 0 }
endComment vérifier qu’elle est appliquée
Exécutez stat -c '%G %g' /etc/crontab. 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 fichier avec auditd : auditctl -w /etc/crontab -p wa -k cron-perms, puis examinez grep 'key="cron-perms"' /var/log/audit/audit.log. L'exécution de cron apparaît dans journalctl -u cron (Debian/Ubuntu) ou 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/crontab.
Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :
| group | root |
|---|---|
| path | /etc/crontab |
| 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/crontab permet aux membres du groupe de modifier des tâches exécutées 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 lire le fichier normalement. Précaution : vérifiez qu'aucun outil légitime ne dépend d'un groupe personnalisé avant de le modifier.
Mapping des normes
| Norme | Référence | Type | Version | Confiance |
|---|---|---|---|---|
| CIS | 2.2.6, 2.4.1.2 | 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.