Garantir l'absence de /etc/cron.deny
Garantit que /etc/cron.deny n'existe pas, afin que l'accès à crontab soit régi uniquement par la liste d'autorisation (/etc/cron.allow) selon un modèle de refus par défaut.
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
Lorsque cron.allow est présent, crond ignore cron.deny, mais un cron.deny résiduel est trompeur et devient un repli permissif si cron.allow venait à être supprimé. Une liste d'interdiction est intrinsèquement risquée : tout compte non explicitement listé est autorisé, si bien qu'un utilisateur oublié ou nouvellement créé obtient silencieusement la capacité de planifier des tâches. Supprimer cron.deny force le recours au modèle de liste d'autorisation, plus sûr.
Ce que vérifie Pavois
Pavois vérifie l'absence réelle de /etc/cron.deny sur le système en fonctionnement via la ressource InSpec file, qui interroge le système de fichiers réel plutôt qu'un quelconque modèle. Cette absence constitue l'état de contrôle d'accès effectif lu par crond.
describe file('/etc/cron.deny') do
it { should_not exist }
endComment vérifier qu’elle est appliquée
Exécutez test ! -e /etc/cron.deny && echo absent (attendez absent), ou ls -l /etc/cron.deny (attendez Aucun fichier ou dossier de ce nom). La réexécution de la commande InSpec doit réussir.
Inspecter et investiguer
Confirmez l'état du fichier avec stat /etc/cron.deny (devrait signaler le fichier manquant). Les décisions d'accès cron sont visibles dans les journaux du service cron via journalctl -u cron (Debian/Ubuntu) ou journalctl -u crond (famille RHEL), ou dans /var/log/cron / /var/log/syslog.
Remédiation
L'objet remediation est vide ; Pavois ne corrige donc pas automatiquement cette règle. Supprimez le fichier manuellement avec rm -f /etc/cron.deny, et assurez-vous que /etc/cron.allow existe (voir file-cron-allow-exists) afin que l'accès reste contrôlé.
Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :
| action | delete |
|---|---|
| path | /etc/cron.deny |
| resource | file |
pavois harden plan localoù la cible est local, un alias SSH user@hôte, ou un conteneur , Docs
Impact & précautions
Risque minime si /etc/cron.allow est déjà en place. Supprimer cron.deny sans cron.allow pourrait, sur certaines distributions, laisser cron ouvert à tous les utilisateurs ; appliquez donc file-cron-allow-exists conjointement à cette règle. Aucun redémarrage de service n'est nécessaire ; le changement prend effet à la prochaine invocation de crontab.
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.