Vérifier l'utilisateur propriétaire du fichier /etc/cron.allow
Garantit que la liste d'autorisation cron /etc/cron.allow appartient à l'utilisateur root (UID 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/cron.allow définit quels utilisateurs sont autorisés à planifier des tâches cron. S'il n'appartient pas à root, un utilisateur non autorisé pourrait y ajouter son propre nom pour obtenir un accès cron, et donc un point d'ancrage pour une persistance planifiée ou une élévation de privilèges, ou le lire pour découvrir quels comptes disposent de droits cron. Maîtriser la propriété garantit l'autorité de la liste d'autorisation.
Ce que vérifie Pavois
Pavois lit le propriétaire effectif de /etc/cron.allow via la ressource file d'InSpec et vérifie uid == 0, uniquement si le fichier existe (only_if). Lire la propriété réelle de l'inode reflète l'état exact sur le disque, détectant une dérive due à des éditions manuelles ou des scripts d'administration plutôt que de se fier à une valeur par défaut supposée.
only_if { file('/etc/cron.allow').exist? }
describe file('/etc/cron.allow') do
its('uid') { should eq 0 }
endComment vérifier qu’elle est appliquée
Exécutez stat -c '%U %u' /etc/cron.allow. Résultat attendu : root 0. Sinon, ls -l /etc/cron.allow doit afficher root dans la colonne du propriétaire.
Inspecter et investiguer
La propriété ne génère aucun journal de service. Vérifiez l'état avec stat -c '%U %u' /etc/cron.allow. Pour tracer les changements, une surveillance auditd telle que auditctl -w /etc/cron.allow -p wa -k cron-access enregistre les écritures/changements d'attributs dans /var/log/audit/audit.log.
Remédiation
Aucun plan de durcissement automatisé n'est défini pour cette règle ; elle doit être appliquée manuellement : exécutez chown root /etc/cron.allow en root pour fixer le propriétaire à root.
Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :
| owner | root |
|---|---|
| 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
En cas de mauvaise configuration, un utilisateur non autorisé pourrait s'ajouter à la liste d'autorisation cron et exécuter des tâches planifiées, permettant persistance ou élévation.
Précautions avant application : chown root /etc/cron.allow est sûr et réversible, sans redémarrage de service. Notez que la simple présence de cron.allow prévaut sur cron.deny ; ne créez pas le fichier comme effet de bord de la remédiation, ne changez la propriété que s'il existe déjà, sinon vous pourriez restreindre cron aux seuls utilisateurs listés.
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.