S'assurer que le binaire sudo possède les permissions correctes
Restreint les permissions du binaire /usr/bin/sudo afin qu'il ne soit ni lisible ni modifiable par le groupe/les autres, ni modifiable par son propriétaire.
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 binaire sudo est setuid root : quiconque peut l'exécuter dispose d'un chemin vers les privilèges root. Ses permissions doivent rester strictement contrôlées (---x--x--x avec le bit setuid). Si sudo devient modifiable par un utilisateur non-root, celui-ci peut remplacer ou altérer le binaire et capturer chaque invocation, y compris les identifiants et commandes des administrateurs, un vecteur immédiat d'escalade de privilèges et de vol d'identifiants. Un accès en lecture trop large aide aussi un attaquant à analyser le binaire pour concevoir des exploits.
Ce que vérifie Pavois
Pavois inspecte le mode réel sur disque de /usr/bin/sudo et vérifie qu'il n'est modifiable ni par le propriétaire, ni par le groupe, ni par les autres, et qu'il n'est ni lisible ni exécutable par le groupe/les autres. La ressource InSpec file lit les permissions effectives de l'inode résolues par le noyau, exactement celles avec lesquelles sudo s'exécute, plutôt que de se fier à un manifeste de paquet potentiellement altéré après installation.
only_if { file('/usr/bin/sudo').exist? }
describe file('/usr/bin/sudo') do
it { should be_owned_by 'root' }
it { should_not be_writable.by('group') }
it { should_not be_writable.by('other') }
endComment vérifier qu’elle est appliquée
Exécutez stat -c '%U %G %a' /usr/bin/sudo. Attendu : propriétaire et groupe root avec un mode tel que 4111 (setuid, ---x--x--x). Le binaire ne doit présenter aucun bit d'écriture pour le groupe ou les autres, ni de bit de lecture pour le groupe/les autres.
Inspecter et investiguer
Les changements d'intégrité du paquet sont visibles via dpkg --verify sudo (Debian/Ubuntu) ou rpm -V sudo (RHEL/Alma) ; un indicateur ..?...... ou M sur le binaire signale un changement de mode. L'utilisation de sudo est elle-même journalisée dans /var/log/auth.log (Debian/Ubuntu) ou /var/log/secure (RHEL).
Remédiation
Aucune remédiation automatique n'est fournie pour cette règle. Restaurez la valeur par défaut du paquet manuellement : chown root:root /usr/bin/sudo puis chmod 4111 /usr/bin/sudo (ou réinstallez le paquet sudo pour rétablir le mode éditeur).
Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :
| mode | 4755 |
|---|---|
| path | /usr/bin/sudo |
| resource | file |
pavois harden plan localoù la cible est local, un alias SSH user@hôte, ou un conteneur , Docs
Impact & précautions
Un binaire sudo modifiable ou lisible par tous permet à un attaquant local de détourner l'escalade de privilèges et de voler les identifiants administrateur. La correction est peu risquée : le mode correct est la valeur par défaut de l'éditeur. Ne retirez pas le bit setuid (chmod 0111), sudo ne pourrait plus élever les privilèges et chaque commande sudo échouerait avec une erreur de permissions. Conservez le mode 4111 pour préserver le comportement setuid-root.
Mapping des normes
| Norme | Référence | Type | Version | Confiance |
|---|---|---|---|---|
| ANSSI BP-028 | R38 | direct | 2.0 | 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.