Vérifier les permissions du fichier /etc/sudoers
Garantit que /etc/sudoers n'est ni modifiable, ni exécutable, ni lisible au-delà du propriétaire root, afin que la politique de privilèges sudo ne puisse être altérée ni divulguée.
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
Définir des permissions correctes sur le fichier /etc/sudoers est important car ce fichier définit quels utilisateurs peuvent exécuter des commandes en tant que root via sudo. Si le fichier est modifiable par un utilisateur non privilégié, celui-ci pourrait s'octroyer un accès sudo illimité et obtenir les pleins privilèges root. S'il est lisible par tous au-delà du nécessaire, la cartographie des privilèges du système est exposée, aidant un attaquant à cibler des comptes. Restreindre les permissions à lecture/écriture pour le propriétaire uniquement (aucune écriture ni exécution pour le groupe/autres, aucune lecture pour les autres) garantit le contrôle exclusif de la politique sudo.
Ce que vérifie Pavois
Pavois inspecte les métadonnées effectives de /etc/sudoers et vérifie que les classes groupe et autres n'ont aucun bit d'écriture/exécution, aucun bit de lecture pour autres, et qu'aucun bit setuid/setgid/sticky n'est positionné. Le contrôle est protégé par only_if { file('/etc/sudoers').exist? }, donc ignoré si le fichier est absent. La lecture de l'inode réel (mode, propriétaire) reflète l'état que le noyau applique réellement à l'appel de sudo, y compris toute dérive introduite après l'installation.
only_if { file('/etc/sudoers').exist? }
describe file('/etc/sudoers') do
it { should_not be_executable.by('owner') }
it { should_not be_writable.by('owner') }
it { should_not be_setuid }
it { should_not be_executable.by('group') }
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. La sortie attendue est 440 root root (ou un mode plus restrictif comme 400/640) ; aucun bit d'écriture pour le groupe ou les autres, aucun bit de lecture pour les autres. Vous pouvez aussi exécuter visudo -c pour confirmer que le fichier est syntaxiquement valide.
Inspecter et investiguer
Utilisez l'état du système de fichiers et la piste d'audit : stat /etc/sudoers affiche le mode courant. Si le sous-système d'audit le surveille, les modifications apparaissent dans /var/log/audit/audit.log (cherchez name="/etc/sudoers"). Chaque commande privilégiée exécutée via sudo est journalisée dans /var/log/auth.log (Debian/Ubuntu) ou journalctl -t sudo (famille RHEL).
Remédiation
Aucun plan de durcissement automatisé n'est défini pour cette règle, elle doit donc être appliquée manuellement : exécutez chown root:root /etc/sudoers puis chmod 0440 /etc/sudoers. Validez le résultat avec visudo -c avant de vous y fier.
Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :
| mode | 0440 |
|---|---|
| path | /etc/sudoers |
| resource | file |
pavois harden plan localoù la cible est local, un alias SSH user@hôte, ou un conteneur , Docs
Impact & précautions
Si /etc/sudoers est modifiable ou exécutable par le groupe/les autres, tout utilisateur local pouvant l'éditer peut passer root et compromettre entièrement l'hôte ; un fichier trop lisible divulgue la carte des privilèges. Précautions : n'éditez pas /etc/sudoers avec un éditeur ordinaire, utilisez toujours visudo, qui valide la syntaxe et empêche d'enregistrer un fichier cassé qui bloquerait sudo pour tout le monde. Le resserrement à 0440 root:root est sûr et correspond au défaut du paquet ; le seul vrai risque est une édition malformée, atténué par visudo -c.
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.