Vérifier qu'aucun répertoire n'est sans utilisateur propriétaire valide
Garantit qu'aucun répertoire d'un système de fichiers local n'a un utilisateur propriétaire non attribué (un UID absent de /etc/passwd).
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
Un répertoire sans propriétaire valide (son UID ne correspond à aucune entrée de /etc/passwd) est un signe fort d'anomalie : résidu d'un compte supprimé, installation bâclée ou artefact d'intrus. Si un nouveau compte réutilise plus tard cet UID, il hérite silencieusement de la propriété, et du contrôle en écriture, du répertoire orphelin et de tout ce qui y est créé. Des répertoires de chemins privilégiés sans propriétaire valide (idéalement root) peuvent laisser un utilisateur non privilégié manipuler l'environnement d'exécution, ouvrant une voie d'élévation de privilèges.
Ce que vérifie Pavois
Pavois lance find / -xdev -type d -nouser et attend une sortie vide : tout chemin renvoyé est un répertoire dont l'UID ne correspond à aucun utilisateur. Le drapeau -xdev maintient l'analyse sur le système de fichiers local. Résoudre les UID par rapport au /etc/passwd réel (pas un rapport statique) détecte les orphelins laissés par des comptes récemment supprimés et les répertoires extraits d'archives étrangères, qu'un audit de fichier de configuration ne révélerait jamais.
describe command("timeout 90 find / -xdev -type d -nouser -not -path '/var/lib/private/*' -not -path '/var/cache/private/*' 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 / -xdev -type d -nouser
Sortie attendue : rien (vide). Pour chaque chemin affiché, vérifiez l'UID brut avec stat -c '%u %n' <rép> et attribuez un propriétaire valide avec chown root <rép> une fois la cause de l'orphelinat comprise.
Inspecter et investiguer
Listez les fautifs avec leur UID brut via find / -xdev -type d -nouser -printf '%U %p\n'. Recoupez tout UID réutilisé avec getent passwd. Il n'y a pas de journal dédié ; les réattributions de propriété ne sont enregistrées que si une surveillance auditd sur chown est configurée.
Remédiation
Aucun plan de durcissement automatisé n'est défini pour cette règle ; elle doit être appliquée manuellement. Ne réattribuez pas aveuglément : recherchez d'abord pourquoi chaque répertoire est orphelin (compte supprimé, mauvaise installation, intrusion). Une fois compris, donnez-lui un propriétaire valide avec chown root <rép> (ou l'utilisateur légitime), ou supprimez-le s'il s'agit de vrais débris résiduels.
Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :
| command | find / -xdev -type d -nouser 2>/dev/null # chown <user> <dir> per directory after review |
|---|---|
| reason | review unowned directories and assign ownership deliberately |
| resource | manual |
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 futur compte créé avec le même UID prend silencieusement la propriété et le contrôle en écriture du répertoire et de son contenu, et l'orphelin peut masquer des artefacts d'intrusion. Avant de corriger : un répertoire orphelin peut être une preuve, conservez-le pour investigation avant de le modifier. Vérifiez le propriétaire prévu avant de lancer chown (attribuer le mauvais utilisateur pourrait accorder un contrôle non voulu), et ne supprimez que les répertoires confirmés comme débris.
Mapping des normes
| Norme | Référence | Type | Version | Confiance |
|---|---|---|---|---|
| CIS | 5.4.2.5 | direct | per OS, see the benchmark table | 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.