← Toutes les règles
SOCLE-CLD-FSP-191// Filesystem (scan)moyenneétat du système de fichiers

S'assurer que tous les fichiers appartiennent à un utilisateur

Garantit que chaque fichier ordinaire des systèmes de fichiers locaux appartient à un compte utilisateur valide (aucun fichier -nouser).

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 4 normes

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 fichiers sans propriétaire n'impliquent pas directement un problème de sécurité, mais ils signalent généralement une anomalie. Ils peuvent provenir d'un intrus, d'une installation logicielle incorrecte ou d'une suppression incomplète, ou de l'oubli de supprimer tous les fichiers d'un compte retiré. Un fichier sans propriétaire devient un risque caché : lorsqu'un nouveau compte est créé et réutilise l'UID orphelin, ce compte hérite silencieusement de tous ces fichiers, ce qui peut exposer des données ou accorder un accès en écriture imprévu. Les fichiers doivent être corrigés et la cause profonde investiguée.

Ce que vérifie Pavois

Pavois exécute find / -xdev -type f -nouser et attend une sortie vide, signifiant qu'aucun fichier ne référence un UID sans entrée correspondante dans /etc/passwd. L'option -xdev limite l'analyse au système de fichiers local (sans franchir les points de montage), de sorte que les montages réseau et pseudo-systèmes ne sont pas signalés. Il s'agit d'une analyse en direct des inodes réels sur disque, et non d'une déduction depuis un fichier de configuration.

describe command("timeout 90 find / -xdev -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 '' }
end

Comment vérifier qu’elle est appliquée

Exécutez sudo find / -xdev -type f -nouser 2>/dev/null en tant qu'administrateur. Sortie attendue : rien (résultat vide). Tout chemin affiché est un fichier sans propriétaire à corriger ou supprimer.

Inspecter et investiguer

Aucun journal de service n'existe pour ce contrôle. Auditez à la demande avec find / -xdev -type f -nouser -ls pour lister les fichiers fautifs avec leur UID numérique, ou find / -xdev -nouser -o -nogroup pour détecter aussi les groupes sans propriétaire.

Remédiation

Aucun plan de durcissement automatisé n'est fourni : un fichier sans propriétaire est un symptôme, et réattribuer aveuglément la propriété pourrait masquer une intrusion ou casser une application. Investiguez chaque fichier, puis supprimez-le ou attribuez-le (chown) manuellement au bon compte.

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

commandfind / -xdev -nouser 2>/dev/null # review each, then assign a real owner: chown <user> <file> (or remove if orphaned)
reasonan unowned file usually signals a deleted user, assign ownership deliberately, do not blindly chown
resourcemanual
pavois harden plan local

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

Impact & précautions

Si rien n'est fait, un compte futur réutilisant un UID orphelin acquiert silencieusement la propriété de ces fichiers, exposant potentiellement des données ou accordant un accès en écriture. Avant de remédier, ne faites pas de chown massif aveugle : identifiez pourquoi le fichier est sans propriétaire (compte récemment supprimé, installation échouée ou compromission). Réattribuer les données d'une application au mauvais utilisateur peut casser ce service ; supprimer des fichiers encore utilisés peut entraîner une perte de données.

Mapping des normes

NormeRéférenceTypeVersionConfiance
ANSSI BP-028R53direct2.0haute
CIS2.2.6, 7.1.12directper OS, see the benchmark tablehaute
NISTAC-6(1), CM-6(a)support800-53 Rev 5 · 800-171 Rev 2 (pinned)moyenne
PCI DSS2.2.6support4.0.1moyenne

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