Garantir l'absence de /etc/at.deny
Garantit que /etc/at.deny n'existe pas, afin que l'accès à at soit régi uniquement par la liste d'autorisation (/etc/at.allow) selon un modèle de refus par défaut.
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
Lorsque les deux fichiers sont présents, at consulte d'abord at.allow et at.deny est ignoré, mais laisser un at.deny obsolète crée de la confusion et un repli par autorisation par défaut si at.allow venait à être supprimé. Une liste d'interdiction est intrinsèquement risquée : tout compte non explicitement interdit est autorisé, si bien qu'un utilisateur oublié ou nouvellement créé obtient silencieusement l'accès. Supprimer at.deny force le recours au modèle de liste d'autorisation, plus sûr.
Ce que vérifie Pavois
Pavois vérifie l'absence réelle de /etc/at.deny sur le système en fonctionnement via la ressource InSpec file, qui interroge le système de fichiers réel plutôt qu'un quelconque modèle. Cette absence constitue l'état de contrôle d'accès effectif lu par le démon at.
describe file('/etc/at.deny') do
it { should_not exist }
endComment vérifier qu’elle est appliquée
Exécutez test ! -e /etc/at.deny && echo absent (attendez absent), ou ls -l /etc/at.deny (attendez Aucun fichier ou dossier de ce nom). La réexécution de la commande InSpec doit réussir.
Inspecter et investiguer
Confirmez l'état du fichier avec stat /etc/at.deny (devrait signaler le fichier manquant). Les décisions d'accès at sont visibles dans les journaux du service at/atd via journalctl -u atd (ou /var/log/syslog / /var/log/cron, selon la distribution).
Remédiation
L'objet remediation est vide ; Pavois ne corrige donc pas automatiquement cette règle. Supprimez le fichier manuellement avec rm -f /etc/at.deny, et assurez-vous que /etc/at.allow existe (voir file-at-allow-exists) afin que l'accès reste contrôlé.
Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :
| action | delete |
|---|---|
| path | /etc/at.deny |
| resource | file |
pavois harden plan localoù la cible est local, un alias SSH user@hôte, ou un conteneur , Docs
Impact & précautions
Risque minime si /etc/at.allow est déjà en place. Supprimer at.deny alors qu'aucun at.allow n'existe pourrait, sur certaines distributions, faire basculer le comportement vers un défaut plus permissif ; appliquez donc file-at-allow-exists conjointement à cette règle. Aucun redémarrage de service n'est nécessaire.
Mapping des normes
| Norme | Référence | Type | Version | Confiance |
|---|---|---|---|---|
| CIS | 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.