Vérifier qu'aucun fichier accessible en écriture par tous n'existe
Garantit qu'aucun fichier d'un système de fichiers local n'est accessible en écriture par tous (bit de permission o+w / 0002).
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 fichier accessible en écriture par tous (o+w, le bit de permission 0002) peut être modifié par n'importe quel utilisateur du système. Un attaquant ou un compte peu privilégié compromis peut réécrire un tel fichier pour injecter du contenu malveillant, falsifier des données ou préparer une charge d'élévation de privilèges. Presque tous les besoins légitimes de partage se satisfont avec des permissions utilisateur et groupe, donc les fichiers en écriture pour tous constituent un risque gratuit qui ne doit pas exister sur les systèmes de fichiers locaux.
Ce que vérifie Pavois
Pavois lance find / -xdev -type f -perm -0002 et attend une sortie vide : tout chemin renvoyé est un fichier accessible en écriture par tous. Le drapeau -xdev maintient l'analyse sur le système de fichiers local (en ignorant les montages réseau ou pseudo-systèmes). Auditer les permissions réelles des inodes détecte les fichiers créés à l'exécution, extraits d'archives ou modifiés par chmod, qu'un audit de manifeste de paquet ou de fichier de configuration ne peut détecter.
describe command('timeout 90 find / -xdev -type f -perm -0002 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 f -perm -0002
Sortie attendue : rien (vide). Pour chaque chemin affiché, inspectez avec ls -l <fichier> et retirez le bit d'écriture pour tous avec chmod o-w <fichier> une fois la sûreté confirmée.
Inspecter et investiguer
Listez tous les fautifs avec leur mode via find / -xdev -type f -perm -0002 -printf '%M %p\n'. Il n'y a pas de journal système dédié ; les changements de permission ne sont enregistrés que si une surveillance auditd sur chmod/fchmodat est configurée. Relancez le find après correction pour confirmer un résultat vide.
Remédiation
Aucun plan de durcissement automatisé n'est défini pour cette règle ; elle doit être appliquée manuellement. Les fichiers en écriture pour tous sont trop spécifiques pour un balayage aveugle : examinez chacun et retirez le bit avec chmod o-w <fichier>, ou déplacez les données réellement partagées derrière des permissions de groupe appropriées ou un répertoire à sticky bit. Corriger automatiquement chaque occurrence pourrait casser une application qui attend un chemin d'écriture ouvert.
Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :
| command | # List world-writable files (excluding the sticky-bit dirs), then fix each after review: find / -xdev -type f -perm -0002 2>/dev/null # for each legitimate-to-fix: chmod o-w <file> |
|---|---|
| reason | auto-chmod over a find risks breaking apps that rely on a world-writable path, review each |
| 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 : n'importe quel utilisateur peut altérer le contenu du fichier, corrompre des données, y déposer du code ou détourner un script qu'un processus privilégié exécutera ensuite. Avant de corriger : certaines applications reposent légitimement sur un fichier ou un socket accessible en écriture par tous ; en retirer o+w les casserait. Identifiez d'abord l'application propriétaire de chaque occurrence ; préférez un répertoire partagé à sticky bit (mode 1777, comme /tmp) à un fichier en écriture pour tous. Retirez le bit fichier par fichier, jamais avec un chmod récursif sur /.
Mapping des normes
| Norme | Référence | Type | Version | Confiance |
|---|---|---|---|---|
| ANSSI BP-028 | R54 | direct | 2.0 | haute |
| CIS | 2.2.6, 7.1.11 | direct | per OS, see the benchmark table | haute |
| NIST | AC-6(1), CM-6(a) | support | 800-53 Rev 5 · 800-171 Rev 2 (pinned) | moyenne |
| PCI DSS | 2.2.6 | support | 4.0.1 | 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.