Vérifier l'utilisateur propriétaire du fichier /etc/at.deny
Garantit que /etc/at.deny 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.deny est la liste d'interdiction déterminant qui est interdit de planifier des tâches at. S'il n'appartient pas à root (uid 0), un utilisateur non autorisé pourrait retirer sa propre entrée pour obtenir l'accès à at, ou le lire pour découvrir la politique de planification. La propriété par root maintient la liste d'interdiction autoritaire et résistante à l'altération.
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 maintenant, détectant la dérive de chown, au lieu de faire confiance à une valeur par défaut de paquet.
only_if { file('/etc/at.deny').exist? }
describe file('/etc/at.deny') do
its('uid') { should eq 0 }
endComment vérifier qu’elle est appliquée
Exécutez stat -c '%U' /etc/at.deny. Sortie attendue : root. Sinon, ls -l /etc/at.deny doit afficher root dans la colonne du propriétaire.
Inspecter et investiguer
Le propriétaire est affiché par ls -l /etc/at.deny et stat /etc/at.deny. L'activité 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.deny, 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.deny (souvent accompagné de chgrp root et chmod 600). Notez que les guides de durcissement recommandent souvent de supprimer at.deny au profit d'une liste d'autorisation at.allow ; si vous le conservez, root doit en être propriétaire.
Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :
| command | test -e /etc/at.deny && { chown root:root /etc/at.deny; chmod 0640 /etc/at.deny; }; true |
|---|---|
| name | at-deny-perms |
| not_if | ! test -e /etc/at.deny |
| resource | exec |
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 utilisateur de modifier la liste d'interdiction pour contourner les restrictions at, affaiblissant les contrôles de planification. Rétablir la propriété root est sans danger opérationnel car atd tourne en root. Précaution : si le fichier est absent, le contrôle est ignoré ; supprimer at.deny sans qu'un at.allow existe rend at accessible à tous, définissez votre politique de planification avant de modifier l'un ou l'autre fichier.
Mapping des normes
| Norme | Référence | Type | Version | Confiance |
|---|---|---|---|---|
| CIS | 2.4.2.1 | 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.