Vérifier les permissions du fichier /etc/at.deny
Garantit que /etc/at.deny 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.deny est la liste d'interdiction des utilisateurs interdits de planifier des tâches at (consultée uniquement en l'absence de at.allow). S'il est lisible par tous ou modifiable par le groupe/les autres, un utilisateur non autorisé pourrait lire qui est bloqué ou modifier la liste pour retirer son propre nom, contournant la restriction et obtenant la capacité d'exécuter des commandes planifiées. Des permissions 0640 ou plus strictes maintiennent la politique d'accès at sous le contrôle de root.
Ce que vérifie Pavois
Pavois lit les bits de mode réels du fichier via la ressource InSpec file, pas une valeur par défaut de paquet. Chaque matcher should_not be_writable/readable/executable/setuid… inspecte l'inode réel appliqué par le noyau, détectant toute permission relâchée après installation. La garde only_if { file('/etc/at.deny').exist? } ignore le contrôle (sans échec) si le fichier est absent.
only_if { file('/etc/at.deny').exist? }
describe file('/etc/at.deny') 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.deny. La sortie attendue est 640 root root /etc/at.deny (ou plus strict, par exemple 600).
Inspecter et investiguer
L'activité at est enregistrée par journalctl -u atd et dans /var/log/syslog. Les changements de permissions sur le fichier peuvent être suivis via une règle auditd : grep at.deny /var/log/audit/audit.log.
Remédiation
Aucune remédiation automatique n'est définie ; appliquez-la manuellement : chown root:root /etc/at.deny && chmod 640 /etc/at.deny. Notez que le durcissement CIS préfère généralement un at.allow explicite et la suppression de at.deny ; si vous conservez at.deny, cette règle garantit qu'il reste protégé.
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
Risque en cas de non-application : une liste d'interdiction modifiable peut être éditée pour échapper à la restriction at. Précautions : durcir ces permissions est sans danger, seuls root et atd lisent ce fichier. Aucun risque de blocage ; vérifiez simplement qu'aucun outil non-root n'analyse /etc/at.deny avant de restreindre l'accès en lecture.
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.