Vérifier le groupe propriétaire du fichier /etc/at.deny
Garantit que /etc/at.deny, la liste des utilisateurs privés du planificateur at, a root (gid 0) pour groupe propriétaire.
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 liste les utilisateurs interdits de planifier des tâches avec at. Si son groupe propriétaire n'est pas root (gid 0), un groupe non privilégié pourrait modifier le fichier pour retirer sa propre entrée et retrouver l'accès au planificateur at, contournant la liste d'interdiction.
Ce que vérifie Pavois
Pavois lit la propriété effective de /etc/at.deny depuis l'inode (via stat) et vérifie gid == 0. Cela reflète l'état réel sur disque au moment du scan plutôt que l'intention d'un modèle de configuration, détectant la dérive de propriété due aux mises à jour de paquets ou aux modifications manuelles. Beaucoup de systèmes durcis préfèrent une liste d'autorisation et suppriment at.deny ; la garde only_if ignore le contrôle lorsque le fichier est absent.
only_if { file('/etc/at.deny').exist? }
describe file('/etc/at.deny') do
its('gid') { should eq 0 }
endComment vérifier qu’elle est appliquée
Exécutez stat -c '%G %g' /etc/at.deny. Sortie attendue : root 0. Si le fichier n'existe pas, le contrôle est ignoré.
Inspecter et investiguer
Les changements de propriété ne sont pas journalisés par défaut. Inspectez avec ls -l /etc/at.deny ou stat /etc/at.deny. Avec une surveillance auditd (auditctl -w /etc/at.deny -p wa), les événements chown apparaissent dans /var/log/audit/audit.log.
Remédiation
Aucun plan de durcissement automatisé n'est encore défini pour cette règle ; elle doit donc être appliquée manuellement : exécutez chgrp root /etc/at.deny (ou chown :root /etc/at.deny) pour restaurer le groupe propriétaire root.
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
Un mauvais groupe propriétaire sur /etc/at.deny permet à un groupe non privilégié de modifier la liste d'interdiction et de contourner la restriction. Précautions : restaurer le groupe root est peu risqué et ne change pas qui est actuellement interdit ; vérifiez qu'aucun gestionnaire de configuration ne l'annulera. Sur les configurations basées sur une liste d'autorisation, envisagez de supprimer entièrement at.deny plutôt que de vous y fier.
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.