Vérifier les permissions du fichier /etc/cron.allow
Garantit que /etc/cron.allow n'est ni modifiable ni lisible par le groupe ou les autres et ne porte aucun bit setuid/setgid/sticky ni exécution, afin que seul le propriétaire (root) contrôle qui peut planifier des tâches cron.
Vérifié sur le contenu d’un fichier de configuration persistant, la source de vérité qui survit aux redémarrages.
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 est la liste d'autorisation qui décide quels utilisateurs peuvent soumettre des tâches cron. Si ses permissions ne sont pas 0640 ou plus restrictives, un utilisateur non autorisé pourrait lire la liste (divulgation d'information) ou, pire, la modifier pour s'octroyer l'accès à cron. Toute commande qu'il planifierait ensuite s'exécuterait via cron, souvent avec des privilèges élevés, ouvrant la voie à une élévation de privilèges et à de la persistance.
Ce que vérifie Pavois
Pavois lit les métadonnées réelles du fichier via file('/etc/cron.allow') et vérifie l'absence de bits de mode dangereux (pas d'écriture groupe/autres, pas de lecture autres, pas de setuid/setgid/sticky/exécution). Le contrôle est conditionné par only_if et donc ignoré si le fichier n'existe pas. Inspecter l'inode vivant reflète les permissions effectives sur le disque, y compris toute modification faite hors bande par un paquet, un script ou un opérateur, plutôt qu'une valeur supposée d'après un modèle de configuration.
only_if { file('/etc/cron.allow').exist? }
describe file('/etc/cron.allow') do
it { should_not be_executable.by('owner') }
it { should_not be_setuid }
it { should_not be_executable.by('group') }
it { should_not be_writable.by('group') }
it { should_not be_setgid }
it { should_not be_executable.by('other') }
it { should_not be_writable.by('other') }
it { should_not be_readable.by('other') }
it { should_not be_sticky }
endComment vérifier qu’elle est appliquée
Exécutez stat -c '%a %U %G' /etc/cron.allow. Attendu : mode 640 (ou plus strict, ex. 600), propriétaire root, groupe root, aucune lecture/écriture pour other, aucune écriture pour group, et aucun bit setuid/setgid/sticky.
Inspecter et investiguer
Il n'y a pas de journal de service pour les permissions de fichier ; inspectez le fichier directement avec stat /etc/cron.allow ou ls -l /etc/cron.allow. Les modifications du fichier peuvent être suivies si auditd le surveille, par ex. auditctl -w /etc/cron.allow -p wa puis recherchez la clé de règle dans /var/log/audit/audit.log.
Remédiation
Aucune remédiation automatique n'est définie pour cette règle ; elle doit donc être appliquée manuellement : chown root:root /etc/cron.allow && chmod u-x,g-wx,o-rwx /etc/cron.allow (mode résultant 640 ou plus strict). Relancez le scan pour confirmer que la règle passe.
Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :
| mode | 0600 |
|---|---|
| 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
Risque si laissé mal configuré : un attaquant capable de lire /etc/cron.allow apprend quels comptes peuvent utiliser cron, et celui qui peut l'écrire s'octroie l'exécution de tâches planifiées, un vecteur classique de persistance et d'élévation de privilèges. Précautions : durcir les permissions de ce fichier est sans impact ; cron continue de le lire en tant que root. Vérifiez simplement que le fichier appartient à root:root avant de retirer l'accès groupe/autres, afin de ne pas priver par mégarde un outillage légitime qui dépendrait de la lecture par le groupe.
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 |
| 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.