Vérifier les permissions du fichier /etc/at.allow
Garantit que /etc/at.allow n'est ni accessible en écriture/lecture par les autres ni en écriture par le groupe, et ne porte aucun bit exécutable ou spécial (setuid/setgid/sticky), soit le mode 0640 ou plus strict.
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
/etc/at.allow est la liste d'autorisation qui décide quels utilisateurs peuvent planifier des tâches at. S'il est lisible par tous ou modifiable par le groupe/les autres, un utilisateur non autorisé pourrait lire qui est autorisé ou, pire, modifier la liste pour s'octroyer l'exécution de commandes planifiées, un point d'appui pour l'escalade de privilèges et la persistance. Des permissions 0640 ou plus restrictives gardent le contrôle de l'accès à at entre les mains de root.
Ce que vérifie Pavois
Pavois interroge les bits de mode réels du fichier via la ressource InSpec file plutôt que de supposer la valeur par défaut du paquet. Chaque matcher should_not be_writable/readable/executable/setuid… inspecte l'inode réel appliqué par le noyau ; ainsi une permission relâchée après l'installation, par un script, un chmod maladroit ou une sauvegarde restaurée, est détectée. Le contrôle est encadré par only_if { file('/etc/at.allow').exist? }, donc il est ignoré (pas en échec) si at n'est pas configuré.
only_if { file('/etc/at.allow').exist? }
describe file('/etc/at.allow') do
it { should_not be_executable.by('owner') }
it { should_not be_setuid }
it { should_not be_executable.by('group') }
it { should_not be_writable.by('group') }
it { should_not be_setgid }
it { should_not be_executable.by('other') }
it { should_not be_writable.by('other') }
it { should_not be_readable.by('other') }
it { should_not be_sticky }
endComment vérifier qu’elle est appliquée
Exécutez stat -c '%a %U %G %n' /etc/at.allow. La sortie attendue est 640 root root /etc/at.allow (ou plus strict, par exemple 600).
Inspecter et investiguer
L'utilisation de at est enregistrée par journalctl -u atd et dans /var/log/syslog (Debian/Ubuntu) ou /var/log/cron (famille RHEL). Les changements de permissions sur le fichier peuvent être suivis via une règle auditd : grep at.allow /var/log/audit/audit.log.
Remédiation
Aucune remédiation automatique n'est définie ; appliquez-la manuellement : chown root:root /etc/at.allow && chmod u-x,g-wx,o-rwx,a-st /etc/at.allow (un simple chmod 640 /etc/at.allow atteint le même mode cible).
Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :
| mode | 0600 |
|---|---|
| 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
Risque en cas de non-application : une autorisation at divulguée ou falsifiée peut permettre à un utilisateur non autorisé de planifier des commandes. Précautions : durcir ces permissions est sans danger, seuls root et le service atd ont besoin de lire ce fichier, et aucun ne dépend d'un accès groupe/autres. Vérifiez au préalable qu'aucune automatisation non-root ne lit /etc/at.allow directement (rare) ; si c'est le cas, accordez l'accès via le groupe du fichier plutôt que par des bits accessibles à tous avant d'appliquer.
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.