Garantir l'existence de /etc/at.allow
Garantit l'existence de /etc/at.allow (propriété root:root, mode 0600) afin que la planification de tâches at soit limitée à une liste d'autorisation explicite.
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
Le démon at décide qui peut planifier des tâches selon at.allow/at.deny. Lorsque at.allow existe, seuls les utilisateurs qui y figurent (et root) peuvent planifier des tâches, une posture par défaut de refus. Une liste d'autorisation est bien plus sûre qu'une liste d'interdiction : oublier d'ajouter un nouveau compte à une liste d'interdiction accorde silencieusement l'accès, alors qu'une liste d'autorisation n'accorde rien par défaut. Un at.allow vide appartenant à root bloque toute planification non-root.
Ce que vérifie Pavois
Pavois vérifie que le fichier réel /etc/at.allow existe sur le système en fonctionnement (la ressource InSpec file interroge l'inode réel, pas un modèle de configuration). La présence de ce fichier constitue elle-même l'état de contrôle d'accès effectif que le démon at lit au moment de la soumission d'une tâche.
describe file('/etc/at.allow') do
it { should exist }
endComment vérifier qu’elle est appliquée
Exécutez ls -l /etc/at.allow et confirmez qu'il existe avec le propriétaire root, le groupe root et le mode 0600. Testez l'application en tentant echo 'true' | at now + 1 minute en tant qu'utilisateur non listé (cela devrait être refusé). La réexécution de la commande InSpec doit réussir.
Inspecter et investiguer
Inspectez l'état du fichier avec stat /etc/at.allow. Les soumissions at rejetées et les tâches acceptées sont journalisées par le service at/atd via journalctl -u atd (ou /var/log/syslog / /var/log/cron, selon la distribution).
Remédiation
pavois harden apply utilise la ressource file pour créer /etc/at.allow en tant que fichier vide appartenant à root:root avec le mode 0600. Une liste d'autorisation vide signifie que seul root peut planifier des tâches at ; ajoutez ensuite des noms d'utilisateurs (un par ligne) pour autoriser des comptes spécifiques.
Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :
| content | |
|---|---|
| group | daemon |
| mode | 0640 |
| owner | root |
| 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
Créer un at.allow vide bloque immédiatement tous les utilisateurs non-root de l'usage d'at. Si des utilisateurs ou scripts légitimes dépendent d'at, ajoutez leurs noms d'utilisateurs au fichier avant ou juste après l'application, sinon leur planification échouera silencieusement. Aucun redémarrage de service n'est requis ; le changement prend effet à la prochaine soumission at.
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.