Vérifier que les répertoires des commandes système ont root comme propriétaire
Garantit que chaque répertoire sous les chemins de commandes système (/bin, /sbin, /usr/bin, /usr/sbin, /usr/local/bin, /usr/local/sbin) appartient à root, afin que seul root puisse gérer les binaires qu'ils contiennent.
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
Ces répertoires contiennent les exécutables du système et des programmes privilégiés. Si un répertoire appartient à un compte non-root, ce compte peut ajouter, remplacer ou supprimer des binaires, lui permettant d'injecter une commande piégée que d'autres utilisateurs (root inclus) exécuteront ensuite, contournant la gestion du changement et élevant les privilèges. Les bibliothèques logicielles et les binaires de langages interprétés ici s'exécutent avec des droits élevés ; seul root doit donc contrôler ces chemins.
Ce que vérifie Pavois
Pavois exécute find /bin /sbin /usr/bin /usr/sbin /usr/local/bin /usr/local/sbin -type d ! -user root et vérifie que la sortie est vide, c'est-à-dire qu'aucun répertoire des chemins de commandes n'a un propriétaire non-root. 2>/dev/null et timeout 90 bornent le scan en direct. Ce parcours examine la propriété réelle du système de fichiers au lieu de se fier aux métadonnées des paquets, détectant les répertoires dont le propriétaire a dérivé après un chown manuel, un installateur négligent ou une archive décompressée. (Note : la vérification teste le propriétaire via ! -user root ; le libellé du titre est conservé par compatibilité.)
describe command('timeout 90 find /bin /sbin /usr/bin /usr/sbin /usr/local/bin /usr/local/sbin -type d ! -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
Exécutez find /bin /sbin /usr/bin /usr/sbin /usr/local/bin /usr/local/sbin -type d ! -user root 2>/dev/null. La sortie attendue est vide. Tout chemin affiché est un répertoire de commandes n'appartenant pas à root et doit être corrigé.
Inspecter et investiguer
Il n'existe pas de journal de service pour cette vérification à l'échelle du système de fichiers ; la commande de scan ci-dessus est l'audit. Inspectez la propriété avec stat -c '%U:%G %n' <rép> et ls -ld <rép>. Pour détecter les futurs changements de propriétaire, utilisez un outil d'intégrité (AIDE : aide --check) ou une surveillance d'audit (auditctl -w /usr/bin -p wa) et consultez /var/log/audit/audit.log.
Remédiation
Aucun plan de durcissement automatisé n'est fourni pour cette règle ; elle doit donc être appliquée manuellement : pour chaque chemin retourné, restaurez la propriété root avec chown root <rép> (utilisez chown root:root <rép> pour réinitialiser aussi le groupe). Cherchez pourquoi un répertoire système a changé de propriétaire avant de corriger, au cas où cela signalerait une compromission.
Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :
| command | # Review ownership/permissions of system command directories (e.g. /bin /sbin /usr/bin /usr/sbin): find /bin /sbin /usr/bin /usr/sbin /usr/local/bin /usr/local/sbin -xdev \( -perm -0002 -o ! -user root \) 2>/dev/null # fix each after review: chown root <path> ; chmod o-w <path> |
|---|---|
| reason | tightening perms on system command dirs can break packaged tooling, review |
| resource | manual |
pavois harden plan localoù la cible est local, un alias SSH user@hôte, ou un conteneur , Docs
Impact & précautions
Un répertoire de commandes appartenant à un compte non-root est un vecteur direct d'élévation de privilèges et peut signaler une compromission. Précautions : chown root sur ces répertoires est peu risqué et correspond au défaut du gestionnaire de paquets, mais un répertoire sous /usr/local a pu être délégué intentionnellement à un compte de service, confirmez-le avant de revenir en arrière, sinon le service propriétaire pourrait perdre la capacité de mettre à jour ses propres binaires. Restaurer la propriété ne modifie pas les permissions ; cela ne cassera donc pas l'exécution pour les utilisateurs normaux.
Mapping des normes
| Norme | Référence | Type | Version | Confiance |
|---|---|---|---|---|
| ANSSI BP-028 | R50 | direct | 2.0 | haute |
| NIST | CM-5(6), CM-5(6).1 | support | 800-53 Rev 5 · 800-171 Rev 2 (pinned) | moyenne |
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.