← Toutes les règles
SOCLE-CLD-FSP-123// File permissionsmoyenneconfig persistante

Vérifier les permissions de cron.daily

Garantit que le répertoire /etc/cron.daily 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 quotidiens.

Vérifié sur le contenu d’un fichier de configuration persistant, la source de vérité qui survit aux redémarrages.

Un PASS prouve? actif maintenant✓ sur disque✓ survit au rebootle verdict qualifié →
Debian 12CIS 1.1.0Debian 13CIS 1.0.0FedoraRHEL 10 / Rocky 10 / AlmaLinux 10RHEL 8 / Rocky 8 / AlmaLinux 8CIS 4.0.0RHEL 9 / Rocky 9 / AlmaLinux 9CIS 2.0.0Ubuntu 22.04CIS 3.0.0Ubuntu 24.04CIS 1.0.0Ubuntu 26.04
Un seul check, mappé sur 3 normes

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.daily contient les scripts que le démon cron exécute chaque jour 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 altérer un script et le faire exécuter avec les privilèges root, compromission totale du système. S'il est seulement lisible par le groupe/les autres, un attaquant peut énumérer les tâches planifiées pour préparer une attaque. Le restreindre au propriétaire empêche à la fois les modifications non autorisées et la reconnaissance.

Ce que vérifie Pavois

Pavois lit l'inode réel via file('/etc/cron.daily') et vérifie l'absence d'accès groupe/autres et de bits de mode spéciaux. La garde only_if ignore le test si le chemin est absent. Lire les permissions effectives sur le disque détecte les dérives introduites par les mises à jour de paquets, un chmod improvisé ou une restauration de sauvegarde, ce qu'une simple hypothèse sur un modèle de fichier manquerait.

only_if { file('/etc/cron.daily').exist? }
describe file('/etc/cron.daily') do
  it { should_not be_setuid }
  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 }
end

Comment vérifier qu’elle est appliquée

Exécutez stat -c '%a %U %G' /etc/cron.daily. 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.daily ou ls -ld /etc/cron.daily. Pour détecter une altération, ajoutez une surveillance auditd (auditctl -w /etc/cron.daily -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.daily && chmod 700 /etc/cron.daily. 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 :

grouproot
mode0700
ownerroot
path/etc/cron.daily
resourcedirectory
pavois harden plan local

où la cible est local, un alias SSH user@hôte, ou un conteneur , Docs

Impact & précautions

Risque si laissé mal configuré : un cron.daily modifiable par le groupe/les autres est un vecteur direct d'exécution de code root et de persistance ; lisible, il divulgue la planification. Précautions : restreindre ce répertoire à root est sans danger, le démon cron s'exécute en tant que root et n'est pas affecté. Vérifiez simplement qu'aucun service non-root n'a légitimement besoin d'y lire ou écrire (rare) avant de durcir, et gardez le propriétaire à root:root pour que root conserve le contrôle total.

Mapping des normes

NormeRéférenceTypeVersionConfiance
CIS2.2.6, 2.4.1.4directper OS, see the benchmark tablehaute
NISTAC-6(1), CM-6(a)support800-53 Rev 5 · 800-171 Rev 2 (pinned)moyenne
PCI DSS2.2.6support4.0.1moyenne

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.

Sources & références