Vérifier les permissions de cron.yearly
Garantit que le répertoire /etc/cron.yearly appartient à root et n'est ni lisible, ni modifiable, ni exécutable par le groupe ou les autres, sans bits setuid/setgid/sticky, afin que seul root puisse ajouter ou modifier les scripts cron annuels.
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.yearly contient les scripts que le démon cron exécute une fois par an en tant que root. Si le répertoire est modifiable par le groupe ou les autres, un utilisateur non autorisé peut y déposer ou y modifier un script qui s'exécutera avec les privilèges root, compromission totale. S'il est lisible par le groupe/les autres, les tâches peuvent être énumérées à des fins de reconnaissance. Le restreindre au propriétaire empêche à la fois les modifications non autorisées et la divulgation.
Ce que vérifie Pavois
Pavois lit l'inode réel via file('/etc/cron.yearly') et vérifie l'absence d'accès groupe/autres et de bits spéciaux, avec une garde only_if qui l'ignore en cas d'absence. Inspecter les permissions effectives sur le disque détecte les dérives dues aux mises à jour de paquets, à un chmod manuel ou à des restaurations de sauvegarde, ce qu'une hypothèse sur un modèle de configuration manquerait.
only_if { file('/etc/cron.yearly').exist? }
describe file('/etc/cron.yearly') do
it { should_not be_setuid }
it { should_not be_executable.by('group') }
it { should_not be_writable.by('group') }
it { should_not be_readable.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.yearly. Attendu : mode 700 (ou plus strict), propriétaire root, groupe root, aucune lecture/écriture/exécution pour group ni other, et aucun bit setuid/setgid/sticky.
Inspecter et investiguer
Aucun journal de service ne s'applique ; inspectez avec stat /etc/cron.yearly ou ls -ld /etc/cron.yearly. Pour détecter une altération, ajoutez une surveillance auditd (auditctl -w /etc/cron.yearly -p wa -k cron) et recherchez key="cron" dans /var/log/audit/audit.log.
Remédiation
Aucune remédiation automatique n'est définie ; appliquez-la manuellement : chown root:root /etc/cron.yearly && chmod 700 /etc/cron.yearly. 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 | 0700 |
|---|---|
| path | /etc/cron.yearly |
| 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 cron.yearly modifiable par le groupe/les autres est un vecteur d'exécution de code root et de persistance ; lisible, il divulgue la planification. Précautions : restreindre à root:root 700 est sans danger, le démon cron s'exécute en tant que root. Vérifiez qu'aucun outillage non-root n'y écrit légitimement avant de durcir, et gardez le propriétaire à root:root.
Mapping des normes
| Norme | Référence | Type | Version | Confiance |
|---|---|---|---|---|
| CIS | 2.4.1.7 | direct | per OS, see the benchmark table | haute |
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.