← Toutes les règles
SOCLE-CLD-FSP-089// File ownershipmoyenneétat du système de fichiers

Vérifier l'utilisateur propriétaire du fichier /etc/sudoers

Garantit que le fichier de politique sudo /etc/sudoers appartient à root (UID 0).

Vérifié sur les métadonnées d’un chemin, mode, propriétaire, groupe, SUID/SGID.

Un PASS prouve✓ actif maintenant✓ sur disque✓ survit au rebootle verdict qualifié →
Debian 12CIS 1.1.0Debian 13CIS 1.0.0FedoraRHEL 10 / Rocky 10 / AlmaLinux 10RHEL 8 / Rocky 8 / AlmaLinux 8CIS 4.0.0RHEL 9 / Rocky 9 / AlmaLinux 9CIS 2.0.0Ubuntu 22.04CIS 3.0.0Ubuntu 24.04CIS 1.0.0Ubuntu 26.04
Un seul check, mappé sur 1 norme

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 fichier /etc/sudoers définit quels utilisateurs peuvent exécuter des commandes en tant que root via sudo. Si un compte non-root le possède, cet utilisateur pourrait s'octroyer des droits sudo illimités, une escalade de privilèges immédiate et totale. Définir root (UID 0) comme propriétaire garantit un contrôle privilégié exclusif de la politique sudo. (sudo lui-même refuse de s'exécuter si sudoers n'appartient pas à root.)

Ce que vérifie Pavois

Pavois inspecte le système de fichiers réel via la ressource InSpec file('/etc/sudoers') et vérifie uid == 0, protégé par only_if. Lire le propriétaire réel de l'inode reflète l'état effectif sur le disque et détecte un chown qui permettrait à un utilisateur de réécrire la politique sudo. (Note : les règles sous /etc/sudoers.d/ comptent aussi et sont couvertes par leurs propres contrôles.)

only_if { file('/etc/sudoers').exist? }
describe file('/etc/sudoers') do
  its('uid') { should eq 0 }
end

Comment vérifier qu’elle est appliquée

Exécutez stat -c '%U %u %n' /etc/sudoers. Sortie attendue : root 0 /etc/sudoers. Le 0 numérique confirme la propriété par root.

Inspecter et investiguer

Les distributions livrent généralement une règle d'audit sur ce fichier (clés actions/privileged) ; inspectez /var/log/audit/audit.log avec grep 'key="actions"'. Si absente, ajoutez auditctl -w /etc/sudoers -p wa -k actions. Chaque invocation de sudo est journalisée dans /var/log/auth.log / journalctl (et /var/log/secure sur RHEL).

Remédiation

Aucune remédiation automatisée n'est fournie pour cette règle. Appliquez-la manuellement avec chown root /etc/sudoers (en root ou via sudo) ; le fichier doit rester en groupe root et mode 0440. Éditez toujours sudoers avec visudo, qui valide la syntaxe avant l'enregistrement.

Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :

ownerroot
path/etc/sudoers
resourcefile
pavois harden plan local

où la cible est local, un alias SSH user@hôte, ou un conteneur , Docs

Impact & précautions

Un propriétaire non-root de /etc/sudoers est un vecteur d'escalade total. Risque à l'application : très faible, la propriété root est obligatoire au fonctionnement de sudo, la restaurer ne peut qu'aider. Précaution : si sudo est votre seul accès à root et que le fichier est cassé, récupérez via un shell root ou le mode mono-utilisateur ; gardez le mode 0440 et validez avec visudo -c ensuite.

Mapping des normes

NormeRéférenceTypeVersionConfiance
ANSSI BP-028R50direct2.0haute

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.

Sources & références