Garantir l'existence de /etc/cron.allow
Garantit l'existence de /etc/cron.allow (propriété root:root, mode 0600) afin que l'usage de crontab soit limité à une liste d'autorisation explicite.
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
crond décide qui peut exécuter crontab selon cron.allow/cron.deny. Lorsque cron.allow existe, seuls les utilisateurs qui y figurent (et root) peuvent installer des tâches cron, une posture par défaut de refus. Une liste d'autorisation est plus sûre qu'une liste d'interdiction : oublier d'interdire un nouveau compte lui accorde silencieusement la planification, alors qu'une liste d'autorisation n'accorde rien par défaut. Un cron.allow vide appartenant à root bloque toutes les crontabs non-root, limitant un point d'appui qu'un attaquant pourrait utiliser pour la persistance.
Ce que vérifie Pavois
Pavois vérifie que le fichier réel /etc/cron.allow existe sur le système en fonctionnement via la ressource InSpec file, qui interroge l'inode réel plutôt qu'un modèle de configuration. La présence de ce fichier constitue l'état de contrôle d'accès effectif que crond lit lorsqu'un utilisateur exécute crontab.
describe file('/etc/cron.allow') do
it { should exist }
endComment vérifier qu’elle est appliquée
Exécutez ls -l /etc/cron.allow et confirmez qu'il existe avec le propriétaire root, le groupe root et le mode 0600. Testez l'application en lançant crontab -e en tant qu'utilisateur non listé (cela devrait être refusé : You (user) are not allowed to use this program). La réexécution de la commande InSpec doit réussir.
Inspecter et investiguer
Inspectez l'état du fichier avec stat /etc/cron.allow. Les refus d'accès cron et l'activité des tâches sont journalisés par le service cron via journalctl -u cron (Debian/Ubuntu) ou journalctl -u crond (famille RHEL), ou dans /var/log/cron / /var/log/syslog.
Remédiation
pavois harden apply utilise la ressource file pour créer /etc/cron.allow en tant que fichier vide appartenant à root:root avec le mode 0600. Une liste d'autorisation vide signifie que seul root peut utiliser crontab ; ajoutez ensuite des noms d'utilisateurs (un par ligne) pour autoriser des comptes spécifiques.
Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :
| content | |
|---|---|
| group | crontab |
| mode | 0640 |
| 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
Créer un cron.allow vide bloque immédiatement tous les utilisateurs non-root de l'installation de crontabs. Les crontabs déjà installées continuent de s'exécuter, mais les utilisateurs concernés ne peuvent plus les modifier. Si des utilisateurs légitimes dépendent de crontab, ajoutez leurs noms d'utilisateurs au fichier avant ou juste après l'application. Aucun redémarrage de service n'est requis ; le changement prend effet à la prochaine invocation de crontab.
Mapping des normes
| Norme | Référence | Type | Version | Confiance |
|---|---|---|---|---|
| CIS | 2.4.1.2, 2.4.1.8, 2.4.1.9 | 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.