S'assurer qu'aucun fichier accessible en écriture par tous n'existe
Vérifie que le répertoire partagé /tmp n'est pas accessible en écriture par les autres, sentinelle de la politique plus large d'absence de fichiers accessibles en écriture par tous non autorisés.
Vérifié sur le contenu d’un fichier de configuration persistant, la source de vérité qui survit aux redémarrages.
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 données dans les fichiers et répertoires accessibles en écriture par tous peuvent être modifiées par n'importe quel utilisateur du système. Un attaquant (ou un compte peu privilégié compromis) peut altérer le contenu, déposer des scripts ou écraser des données de confiance, compromettant l'intégrité. Sur un répertoire accessible en écriture par tous comme /tmp, l'absence du sticky bit est particulièrement dangereuse : tout utilisateur pourrait supprimer ou renommer les fichiers d'autrui. Un accès légitime peut presque toujours être accordé via des permissions utilisateur/groupe, sans exposer le fichier à tout le monde.
Ce que vérifie Pavois
Pavois lit le mode réel de /tmp et vérifie que le bit d'écriture pour tous n'est pas positionné de manière non protégée. Note : un /tmp correctement durci est typiquement 1777, accessible en écriture par tous avec le sticky bit. Lorsque ce contrôle échoue, il signale que /tmp a été reconfiguré de manière non sécurisée (par ex. perte de sa protection) et sert de contrôle représentatif du fait que la surface accessible en écriture par tous est maîtrisée. Inspecter l'inode effectif vaut mieux que d'analyser fstab ou un manifeste, qui ne refléteraient pas un chmod effectué à l'exécution.
describe command('find / -xdev -type f -perm -0002 2>/dev/null | head -1') do
its('stdout') { should eq '' }
endComment vérifier qu’elle est appliquée
Exécutez stat -c '%a' /tmp (attendu 1777, sticky bit positionné). Pour auditer tout le système à la recherche de fichiers accessibles en écriture par tous sans sticky bit : find / -xdev -type f -perm -0002 2>/dev/null (ne doit rien retourner) et find / -xdev -type d -perm -0002 ! -perm -1000 2>/dev/null pour les répertoires non protégés.
Inspecter et investiguer
Il n'existe pas de journal de service pour les permissions ; auditez à la demande avec les commandes find ci-dessus. Si auditd surveille les chemins concernés, les changements associés apparaissent dans /var/log/audit/audit.log. Les fichiers fournis par des paquets ayant dérivé apparaissent via dpkg --verify ou rpm -Va.
Remédiation
Aucune remédiation automatique n'est fournie pour cette règle. Restaurez /tmp avec chmod 1777 /tmp, et retirez le bit d'écriture pour tous de tout fichier fautif trouvé par l'audit find : chmod o-w <fichier> (ou ajoutez le sticky bit aux répertoires légitimement partagés avec chmod +t <répertoire>).
Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :
| command | find / -xdev -type f -perm -0002 -exec chmod o-w {} + 2>/dev/null || true |
|---|---|
| name | fix-world-writable |
| not_if | test -z "$(find / -xdev -type f -perm -0002 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
Les fichiers accessibles en écriture par tous permettent à n'importe quel utilisateur local d'altérer les données et de consolider une prise de pied. La remédiation est généralement sans danger, mais retirer aveuglément les bits d'écriture peut casser des applications qui s'appuient légitimement sur un répertoire partagé, examinez chaque résultat de find avant de le modifier. Pour /tmp et /var/tmp, conservez-les accessibles en écriture par tous avec le sticky bit (1777) ; supprimer entièrement l'écriture pour tous casserait de nombreux programmes qui créent des fichiers temporaires.
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.