S'assurer que le groupe utilisé par le module pam_wheel.so existe et est vide
Garantit que le groupe référencé par pam_wheel.so dans /etc/pam.d/su existe et n'a aucun membre, afin qu'aucun utilisateur ne puisse devenir root via su.
Vérifié sur ce qui est installé ou enregistré, paquets présents/absents, bases de comptes.
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 programme su exécute des commandes avec un utilisateur et un groupe de substitution ; c'est la manière classique de devenir root. Le module pam_wheel.so restreint l'usage de su aux membres d'un groupe nommé (par ex. wheel ou sugroup). Si ce groupe est configuré mais vide, aucun utilisateur non privilégié ne peut basculer vers root via su : l'élévation passe alors par sudo, qui est journalisé et limité à chaque commande. Un groupe wheel peuplé accorde silencieusement à ses membres une voie non auditée vers root.
Ce que vérifie Pavois
Pavois lit la configuration PAM effective : il extrait l'argument group= réellement passé à pam_wheel.so dans /etc/pam.d/su, résout ce groupe via getent group (NSS) et vérifie que le champ des membres est vide. Résoudre via getent plutôt que de seulement analyser /etc/group permet de détecter des membres provenant de LDAP, SSSD ou d'autres backends NSS qu'une simple lecture de fichier manquerait.
describe command('g=$(grep -RhoE \'pam_wheel.so.*group=[a-z]+\' /etc/pam.d/su 2>/dev/null | grep -oE \'group=[a-z]+\' | cut -d= -f2 | head -1); { [ -n "$g" ] && [ -z "$(getent group "$g" | cut -d: -f4)" ] && echo ok; } || echo ko') do
its('stdout.strip') { should eq 'ok' }
endComment vérifier qu’elle est appliquée
Trouvez le groupe imposé par PAM et listez ses membres :
grep -E 'pam_wheel.so.*group=' /etc/pam.d/su, lire le nom de groupe configuré (par ex.group=sugroup).getent group sugroup, la sortie attendue se termine par un champ de membres vide, par ex.sugroup:x:1001:(rien après le dernier deux-points).
Inspecter et investiguer
Les événements su de PAM sont journalisés par la pile d'authentification :
journalctl -t suougrep ' su' /var/log/auth.log(Debian/Ubuntu) //var/log/secure(RHEL), affichepam_wheel(su:auth): Access denied ...lorsqu'un non-membre est correctement rejeté.- Les élévations réussies apparaissent comme
su: (to root) <user> on pts/N.
Remédiation
Aucun plan de durcissement automatisé n'est défini pour cette règle ; elle doit être appliquée manuellement : identifiez le groupe nommé dans /etc/pam.d/su (group=), puis retirez chaque membre avec gpasswd --delete <user> <group> (ou modifiez la liste des membres du groupe) jusqu'à ce que getent group <group> n'affiche plus de membres. Vérifiez que le groupe existe toujours.
Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :
| command | getent group wheel # gpasswd -d <user> wheel for each unexpected member |
|---|---|
| reason | removing wheel members revokes their su access, confirm each |
| resource | manual |
pavois harden plan localoù la cible est local, un alias SSH user@hôte, ou un conteneur , Docs
Impact & précautions
Risque si non appliqué : les membres du groupe wheel/su disposent d'une porte de sortie non auditée vers root complet via su, même si la politique sudo est stricte.
Précautions avant application : avant de vider le groupe, vérifiez que chaque administrateur peut encore atteindre root autrement, typiquement une règle sudo fonctionnelle. Retirer le dernier membre alors que sudo est cassé ou que pam_wheel.so est aussi imposé sur la pile sudo peut priver tous les administrateurs d'élévation de privilèges. Gardez une session console root ouverte pendant la modification.
Mapping des normes
| Norme | Référence | Type | Version | Confiance |
|---|---|---|---|---|
| CIS | 2.2.6, 5.2.7 | 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.