Vérifier le groupe propriétaire du fichier /etc/at.allow
Garantit que /etc/at.allow, la liste des utilisateurs autorisés à utiliser le 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.allow décide quels utilisateurs peuvent planifier des tâches avec at. Si son groupe propriétaire n'est pas root (gid 0), un groupe non privilégié pourrait s'ajouter à la liste d'autorisation et obtenir la possibilité d'exécuter des commandes planifiées, ou lire la liste des utilisateurs autorisés, une information utile à un attaquant cartographiant les comptes privilégiés.
Ce que vérifie Pavois
Pavois lit la propriété effective de /etc/at.allow telle que résolue par le noyau et vérifie gid == 0. La ressource InSpec file interroge l'identifiant de groupe réel de l'inode via stat, reflétant ainsi l'état réel sur disque au moment du scan, y compris une dérive de propriété causée par des mises à jour de paquets, des scripts de restauration ou des modifications manuelles, plutôt que ce qu'un modèle de configuration prétend.
only_if { file('/etc/at.allow').exist? }
describe file('/etc/at.allow') do
its('group') { should eq 'daemon' }
endComment vérifier qu’elle est appliquée
Exécutez stat -c '%G %g' /etc/at.allow. Sortie attendue : root 0. Le fichier peut légitimement ne pas exister ; dans ce cas le contrôle est ignoré (garde only_if).
Inspecter et investiguer
Les changements de propriété ne sont pas journalisés par défaut. Inspectez l'état courant avec ls -l /etc/at.allow ou stat /etc/at.allow. Si auditd surveille ce chemin (auditctl -w /etc/at.allow -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.allow (ou chown :root /etc/at.allow) pour restaurer le groupe propriétaire root.
Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :
| group | daemon |
|---|---|
| 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
Un mauvais groupe propriétaire sur /etc/at.allow permet à un groupe non privilégié de lire ou modifier qui peut utiliser at, avec un risque d'escalade vers l'exécution de commandes planifiées. Précautions : changer le groupe pour root est peu risqué et n'affecte pas les utilisateurs déjà listés ; vérifiez que le fichier n'est pas géré intentionnellement par un outil de configuration (Ansible/Puppet) qui annulerait la modification, et confirmez qu'at est toujours installé avant de supposer que le fichier doit exister.
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.