SOCLE-RUN-AUD-017// Audit (auditd)moyenneruntime effectif

Enregistrer les événements lorsqu'un exécutable est lancé sous l'identité d'un autre utilisateur

Impose une règle auditd (clé user_emulation) qui enregistre l'exécution d'un processus sous une identité utilisateur différente de l'auid connecté.

Vérifié sur l’état résolu en cours d’exécution (ex. sshd -T, sysctl, systemctl show), attrape les drop-ins et Include qu’une lecture de fichier raterait. Réserve : runtime ≠ persistance ; une valeur correcte maintenant peut ne pas survivre à un redémarrage.

Un PASS prouve✓ actif maintenant✓ sur disque✓ survit au rebootle verdict qualifié →

Debian 12CIS 1.1.0Debian 13CIS 1.0.0FedoraRHEL 10 / Rocky 10 / AlmaLinux 10RHEL 8 / Rocky 8 / AlmaLinux 8CIS 4.0.0RHEL 9 / Rocky 9 / AlmaLinux 9CIS 2.0.0Ubuntu 22.04CIS 3.0.0Ubuntu 24.04CIS 1.0.0Ubuntu 26.04

✓ Un seul check, mappé sur 1 norme

CIS

6.2.3.2 · 6.3.3.2

direct

Pavois vérifie la configuration effective, l’état résolu et réellement appliqué, pas un fichier. Les scanners basés fichier (OVAL/SCAP, Lynis) ratent les Include, drop-ins et défauts runtime ; ce check voit ce qui est réellement en vigueur.

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

Un journal d'audit des utilisateurs exécutant des commandes avec des privilèges temporairement élevés (via sudo/su, où l'uid réel diffère de l'uid d'audit auid) est essentiel au reporting et à la responsabilité. Les administrateurs corrèlent ces enregistrements avec le journal propre de sudo pour confirmer qu'aucune commande non autorisée n'a été exécutée. Le détournement des fonctions privilégiées, par des utilisateurs autorisés négligents ou par un attaquant sur un compte compromis, est une préoccupation sérieuse et permanente, et auditer l'émulation de privilèges est un moyen primordial de détecter cet abus et l'activité d'une menace interne ou persistante avancée.

Ce que vérifie Pavois

Pavois exécute auditctl -l et vérifie qu'une règle de clé user_emulation est chargée. Lire le jeu de règles réellement chargé dans le noyau vaut mieux qu'analyser /etc/audit/rules.d/*.rules : une règle sur disque jamais chargée (pas de augenrules --load, erreur de syntaxe, échec de rechargement) ferait passer à tort un scanner de fichiers. auditctl -l reflète ce que le noyau audite à l'instant présent.

describe command('auditctl -l') do
  its('stdout') { should match(/(-k +|key=)user_emulation\b/) }
end
describe command("grep -rhwsE 'user_emulation' /etc/audit/rules.d/*.rules /etc/audit/audit.rules 2>/dev/null") do
  its('stdout') { should match(/\S/) }
end

Comment vérifier qu’elle est appliquée

Exécutez auditctl -l | grep -E '(-k |key=)user_emulation' (en root). La sortie attendue est l'ensemble des règles d'appel système suivant l'émulation de privilèges, par exemple :

-a always,exit -F arch=b64 -C euid!=uid -F auid!=unset -S execve -k user_emulation
-a always,exit -F arch=b32 -C euid!=uid -F auid!=unset -S execve -k user_emulation

Aucune sortie signifie que les règles ne sont pas chargées.

Inspecter et investiguer

Les événements aboutissent dans /var/log/audit/audit.log. Après avoir lancé une commande via sudo, trouvez l'enregistrement avec grep 'key="user_emulation"' /var/log/audit/audit.log (grep sur le journal brut ; ausearch peut signaler à tort l'absence de correspondance). L'enregistrement indique l'auid, l'uid effectif, le programme exécuté et l'horodatage.

Remédiation

pavois harden apply utilise la ressource audit_ruleset pour ajouter les règles d'appel système user_emulation manquantes dans un drop-in géré par Pavois sous /etc/audit/rules.d/ et les charger. Le sous-système d'audit étant verrouillé une fois lancé, la modification n'est pleinement effective qu'après un redémarrage (reboot_required: true).

Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :

reboot_required	true
resource	audit_ruleset

pavois harden plan local

où la cible est local, un alias SSH user@hôte, ou un conteneur , Docs

Impact & précautions

Ce sont des surveillances d'appels système passives, elles ne bloquent jamais l'émulation de privilèges, donc sudo/su continuent de fonctionner ; elles ajoutent seulement des enregistrements dans /var/log/audit/audit.log. Précautions :

Comme la règle se déclenche à chaque execve où euid != uid, les hôtes à fort usage de sudo (automatisation, runners CI) peuvent générer un volume d'audit important, assurez-vous que /var/log/audit dispose d'espace et de rotation, et surveillez les limites de backlog d'auditd.
Si le jeu de règles est immuable (-e 2), la règle ne peut être ajoutée qu'après un redémarrage.
Confirmez que la règle a été analysée avec augenrules --load puis revérifiez auditctl -l.

Mapping des normes

Norme	Référence	Type	Version	Confiance
CIS	6.2.3.2, 6.3.3.2	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.

Sources & références