Vérifier les permissions du répertoire /etc/sudoers.d
Garantit que le répertoire /etc/sudoers.d n'est ni modifiable par le groupe/les autres, ni lisible ou exécutable par les autres, et ne porte aucun bit setuid/setgid/sticky, afin que seul root contrôle les règles sudo en drop-in.
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
/etc/sudoers.d contient les règles sudo en drop-in que sudo inclut en plus de /etc/sudoers. Un seul fichier déposé ici peut accorder un accès root complet via sudo à n'importe quel utilisateur. Si le répertoire est modifiable par le groupe ou les autres, un utilisateur non privilégié pourrait y ajouter sa propre règle et obtenir root, une élévation de privilèges directe ; s'il est lisible par les autres, l'agencement précis des privilèges est divulgué, aidant un attaquant. Les bits setuid/setgid et un bit sticky non standard indiquent une altération. Seul root doit pouvoir écrire, et lire, ce répertoire.
Ce que vérifie Pavois
Pavois lit les bits de mode réels du répertoire /etc/sudoers.d sur la cible (écriture groupe/autres, lecture/exécution autres, setuid/setgid/sticky), exactement ce que le noyau applique, et non une base documentée. C'est précisément le genre d'emplacement drop-in qu'un scanner de fichiers peut négliger ; Pavois inspecte le répertoire lui-même. La garde only_if ignore le contrôle si le répertoire est absent.
only_if { file('/etc/sudoers.d').exist? }
describe file('/etc/sudoers.d') do
it { should_not be_setuid }
it { should_not be_writable.by('group') }
it { should_not be_setgid }
it { should_not be_executable.by('other') }
it { should_not be_writable.by('other') }
it { should_not be_readable.by('other') }
it { should_not be_sticky }
endComment vérifier qu’elle est appliquée
Exécutez stat -c '%A %U %G' /etc/sudoers.d. Attendu : mode drwxr-x--- (0750), ou 0755 selon certaines bases, mais 0750 root:root est préférable, appartenant à root root, sans bit d'écriture pour le groupe/les autres ni lecture/exéc pour les autres en 0750. Vérification rapide : find /etc/sudoers.d -maxdepth 0 -perm /7027 ne doit rien renvoyer. Confirmez que sudo s'analyse correctement avec visudo -c.
Inspecter et investiguer
Les changements de permissions ne sont pas journalisés par défaut. Surveillez le répertoire avec auditd : auditctl -w /etc/sudoers.d/ -p wa -k scope, puis consultez avec grep 'key="scope"' /var/log/audit/audit.log. Les invocations sudo réelles sont journalisées dans /var/log/auth.log (Debian/Ubuntu) ou /var/log/secure / journalctl _COMM=sudo (RHEL). Mode et propriété actuels : stat /etc/sudoers.d.
Remédiation
Aucun plan de durcissement automatisé n'est fourni pour cette règle, elle doit donc être appliquée manuellement : chown root:root /etc/sudoers.d && chmod 0750 /etc/sudoers.d. Cela supprime toute écriture groupe/autres, retire la lecture/exécution pour les autres et efface tout bit setuid/setgid/sticky. Note : les fichiers de règles à l'intérieur doivent eux-mêmes être en 0440 root:root, sinon sudo les ignore.
Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :
| mode | 0750 |
|---|---|
| path | /etc/sudoers.d |
| resource | file |
pavois harden plan localoù la cible est local, un alias SSH user@hôte, ou un conteneur , Docs
Impact & précautions
Risque si mal réglé : un /etc/sudoers.d modifiable est une voie directe vers root, un utilisateur non-root y dépose un fichier s'octroyant sudo. Appliquer le correctif est sûr : 0750 root:root permet à sudo (exécuté en root) de lire les drop-ins tout en refusant l'accès à tous les autres. Précaution : conservez la propriété root:root et ne mettez pas les fichiers de règles individuels à autre chose que 0440, sudo/visudo refuse les includes modifiables par tous ou au mauvais mode et signalera une erreur d'analyse. Exécutez visudo -c après toute modification pour éviter de vous verrouiller hors de sudo.
Mapping des normes
| Norme | Référence | Type | Version | Confiance |
|---|---|---|---|---|
| ANSSI BP-028 | R50 | 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.