Enregistrer les événements lorsqu'un exécutable privilégié est lancé
Impose une règle auditd (clé setuid) qui enregistre chaque exécution d'un exécutable privilégié setuid/setgid.
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.
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
Les binaires SUID/SGID s'exécutent avec les privilèges de leur propriétaire (souvent root) quel que soit l'utilisateur qui les lance, ce qui en fait un vecteur privilégié d'élévation de privilèges. Le détournement de ces fonctions, par des utilisateurs autorisés négligents ou par un attaquant sur un compte compromis, est une préoccupation sérieuse et permanente, au potentiel d'impact sévère. Auditer chaque exécution d'un exécutable privilégié (setuid) est un moyen primordial de détecter cet abus et l'activité d'une menace interne ou persistante avancée et d'établir la responsabilité des actions élevées.
Ce que vérifie Pavois
Pavois exécute auditctl -l et vérifie qu'une règle de clé setuid 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=)setuid\b/) }
endComment vérifier qu’elle est appliquée
Exécutez auditctl -l | grep -E '(-k |key=)setuid' (en root). La sortie attendue est l'ensemble des règles d'appel système suivant l'exécution setuid, par exemple :
-a always,exit -F arch=b64 -C euid=0 -F auid>=1000 -F auid!=unset -S execve -k setuid-a always,exit -F arch=b32 -C euid=0 -F auid>=1000 -F auid!=unset -S execve -k setuid
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é un binaire setuid, trouvez l'enregistrement avec grep 'key="setuid"' /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 setuid 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 localoù 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'exécution setuid, donc passwd, sudo, mount et autres outils privilégiés continuent de fonctionner ; elles ajoutent seulement des enregistrements dans /var/log/audit/audit.log. Précautions :
- La règle se déclenche à chaque
execveprivilégié par un utilisateur normal : les hôtes où les utilisateurs lancent souvent des outils setuid peuvent produire un volume d'audit important, assurez-vous que/var/log/auditdispose d'espace et de rotation, et surveillez la limite 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 --loadpuis revérifiezauditctl -l.
Mapping des normes
| Norme | Référence | Type | Version | Confiance |
|---|---|---|---|---|
| NIST | AC-6(9), AU-12(3), AU-7(a), AU-7(b), AU-8(b), CM-5(1) | support | 800-53 Rev 5 · 800-171 Rev 2 (pinned) | moyenne |
| PCI DSS | 10.2.1.2 | support | 4.0.1 | moyenne |
| DISA STIG | UBTU-22-654230, UBTU-24-200580 | direct | per OS STIG release | haute |
| CIS | 10.2.1.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.