Vérifier que les exécutables système appartiennent à root
Garantit que chaque exécutable des répertoires de commandes système (/bin, /sbin, /usr/bin, /usr/sbin, /usr/local/bin, /usr/local/sbin) appartient à root.
Vérifié sur les métadonnées d’un chemin, mode, propriétaire, groupe, SUID/SGID.
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
Les binaires système sont exécutés par des utilisateurs privilégiés et par des services système, souvent avec des droits élevés. Si un exécutable d'un répertoire de commandes système appartient à un utilisateur non root, celui-ci peut réécrire le binaire et faire exécuter son code avec les privilèges du prochain appelant, un vecteur classique d'élévation de privilèges et de persistance. Restreindre la propriété à root garantit que ces programmes ne peuvent être détournés.
Ce que vérifie Pavois
Pavois lance find /bin /sbin /usr/bin /usr/sbin /usr/local/bin /usr/local/sbin -type f ! -user root et attend une sortie vide : tout chemin renvoyé est un binaire appartenant à un utilisateur non root. Analyser les fichiers réellement sur le disque (et non la base de paquets) détecte les outils installés manuellement, les scripts déposés dans /usr/local/bin et les binaires dont le propriétaire a changé après installation, qu'un audit de manifeste de paquet ne signalerait jamais.
describe command('timeout 90 find /bin /sbin /usr/bin /usr/sbin /usr/local/bin /usr/local/sbin -type f ! -user root 2>/dev/null') do
its('exit_status') { should_not cmp 124 } # timeout killed the scan: no evidence, not a pass
its('stdout.strip') { should eq '' }
endComment vérifier qu’elle est appliquée
Lancez l'analyse manuellement :
find /bin /sbin /usr/bin /usr/sbin /usr/local/bin /usr/local/sbin -type f ! -user root
Sortie attendue : rien (vide). Inspectez tout chemin affiché avec ls -l <fichier>.
Inspecter et investiguer
Listez les fautifs et leur propriétaire avec find /bin /sbin /usr/bin /usr/sbin /usr/local/bin /usr/local/sbin -type f ! -user root -printf '%u %p\n'. Sur les systèmes RPM, recoupez avec rpm -Vf <fichier> (le drapeau U signale une dérive de propriété) ; un propriétaire non root sur un binaire empaqueté révèle presque toujours une modification locale à investiguer.
Remédiation
Aucun plan de durcissement automatisé n'est défini pour cette règle ; elle doit être appliquée manuellement. Après avoir confirmé que le fichier doit légitimement appartenir à root, rétablissez la propriété avec chown root <fichier>. Comme un binaire système non détenu par root peut indiquer une compromission, recherchez la cause avant de le modifier.
Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :
| command | find /bin /sbin /usr/bin /usr/sbin /usr/local/bin /usr/local/sbin -type f \( ! -user root -o ! -group root \) -exec chown root:root {} + 2>/dev/null; true |
|---|---|
| name | fix-bindir-ownership |
| not_if | test -z "$(find /bin /sbin /usr/bin /usr/sbin /usr/local/bin /usr/local/sbin -type f \( ! -user root -o ! -group root \) 2>/dev/null | head -1)" |
| resource | exec |
pavois harden plan localoù la cible est local, un alias SSH user@hôte, ou un conteneur , Docs
Impact & précautions
Risque en l'état : un binaire système non détenu par root permet à son propriétaire de le remplacer et de détourner tout processus privilégié qui l'exécutera ensuite. Avant de corriger : un très petit nombre de paquets tiers installent légitimement des utilitaires appartenant à un compte de service dédié ; leur appliquer chown root pourrait casser l'outil. Changez la propriété fichier par fichier, vérifiez d'abord l'intégrité du binaire (rpm -Vf ou une somme de contrôle de confiance), et n'exécutez jamais un chown récursif sur /usr aveuglément.
Mapping des normes
| Norme | Référence | Type | Version | Confiance |
|---|---|---|---|---|
| ANSSI BP-028 | R50 | direct | 2.0 | haute |
| NIST | AC-6(1), CM-5(6), CM-5(6).1, CM-6(a) | support | 800-53 Rev 5 · 800-171 Rev 2 (pinned) | moyenne |
| DISA STIG | UBTU-22-232050, UBTU-24-300012 | direct | per OS STIG release | 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.