Vérifier l'utilisateur propriétaire du fichier /etc/at.allow
Garantit que /etc/at.allow appartient à root (uid 0).
Vérifié sur les métadonnées d’un chemin, mode, propriétaire, groupe, SUID/SGID.
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/at.allow est la liste d'autorisation déterminant qui peut planifier des tâches at. S'il n'appartient pas à root (uid 0), un utilisateur non autorisé pourrait le modifier pour s'octroyer l'accès à at, une voie vers l'exécution planifiée de commandes privilégiées, ou le lire pour découvrir quels comptes sont approuvés. La propriété par root est nécessaire pour que la politique de planification reste autoritaire.
Ce que vérifie Pavois
Pavois lit l'uid propriétaire effectif du fichier avec la ressource InSpec file et vérifie qu'il vaut 0 (root), uniquement si le fichier existe. Lire le propriétaire réel du système de fichiers reflète la politique réellement appliquée, détectant toute dérive de chown, plutôt que de faire confiance à une valeur par défaut de paquet qui a pu être modifiée.
only_if { file('/etc/at.allow').exist? }
describe file('/etc/at.allow') do
its('uid') { should eq 0 }
endComment vérifier qu’elle est appliquée
Exécutez stat -c '%U' /etc/at.allow. Sortie attendue : root. Sinon, ls -l /etc/at.allow doit afficher root dans la colonne du propriétaire.
Inspecter et investiguer
Le propriétaire est affiché par ls -l /etc/at.allow et stat /etc/at.allow. L'activité des tâches at est journalisée via journalctl -u atd (ou systemctl status atd) et dans /var/log/syslog//var/log/cron. Si auditd surveille /etc/at.allow, les événements chown et d'écriture apparaissent dans /var/log/audit/audit.log.
Remédiation
Aucun plan de durcissement automatisé n'est fourni pour cette règle : elle doit être corrigée manuellement avec chown root /etc/at.allow (souvent accompagné de chgrp root et chmod 600). Le fichier peut ne pas exister par défaut, ne le créez que si vous comptez utiliser une liste d'autorisation at.
Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :
| owner | root |
|---|---|
| path | /etc/at.allow |
| resource | file |
pavois harden plan localoù la cible est local, un alias SSH user@hôte, ou un conteneur , Docs
Impact & précautions
Une propriété autre que root permet à un attaquant de modifier la liste d'autorisation pour obtenir la planification at, ouvrant la voie à la persistance ou à l'élévation de privilèges. Rétablir la propriété root n'a aucun inconvénient opérationnel, atd tourne en root. Précaution : si le fichier est absent, le contrôle est ignoré ; ne créez pas un /etc/at.allow vide à la légère, car une liste vide refuse at à tous sauf root et peut perturber des tâches planifiées légitimes.
Mapping des normes
| Norme | Référence | Type | Version | Confiance |
|---|---|---|---|---|
| CIS | 2.2.6, 2.4.2.1 | 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.