Vérifier que tous les répertoires accessibles en écriture par tous ont le bit sticky positionné
Garantit que chaque répertoire accessible en écriture par tous sur un système de fichiers local porte aussi le bit sticky, afin que les utilisateurs ne puissent supprimer ou renommer que les fichiers qu'ils possèdent.
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
Sur un répertoire accessible en écriture par tous sans bit sticky, n'importe quel utilisateur peut supprimer, renommer ou remplacer les fichiers créés par d'autres utilisateurs. Cela ouvre la voie aux attaques par substitution de fichier et lien symbolique, à la destruction de fichiers temporaires/journaux et au déni de service. Le bit sticky (+t, mode 01000) réserve la suppression au propriétaire du fichier, c'est pourquoi les espaces partagés comme /tmp et /var/tmp le positionnent. Tout autre répertoire accessible en écriture par tous qui en est dépourvu est probablement mal configuré.
Ce que vérifie Pavois
Pavois exécute find / -xdev -type d -perm -0002 ! -perm -1000 et vérifie que la sortie est vide, c'est-à-dire qu'aucun répertoire n'est accessible en écriture par tous sans bit sticky. -xdev reste sur le système de fichiers racine pour éviter de parcourir les montages réseau ; 2>/dev/null et timeout 90 bornent le scan en direct. Ce parcours examine l'état réel du système de fichiers plutôt que de se fier aux métadonnées des paquets, détectant ainsi les répertoires créés par des applications, des archives ou des administrateurs après l'installation.
describe command('timeout 90 find / -xdev -type d -perm -0002 ! -perm -1000 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 / -xdev -type d -perm -0002 ! -perm -1000 2>/dev/null. La sortie attendue est vide (aucun répertoire en faute). Tout chemin affiché est accessible en écriture par tous sans bit sticky 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. Pour voir qui peut écrire où, stat -c '%A %n' <rép>. Pour la détection de changements, un outil d'intégrité (AIDE : aide --check) ou une surveillance d'audit sur le répertoire (auditctl -w <rép> -p wa) fera remonter les modifications via /var/log/audit/audit.log.
Remédiation
Aucun plan de durcissement automatisé n'est fourni pour cette règle (les répertoires fautifs varient selon l'hôte et certains peuvent être intentionnels) ; elle doit donc être appliquée manuellement : pour chaque chemin retourné, ajoutez le bit sticky avec chmod a+t <rép> (si le répertoire doit légitimement être partagé) ou retirez l'écriture pour tous avec chmod o-w <rép> (à privilégier quand le partage n'est pas requis).
Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :
| command | find / -xdev -type d -perm -0002 ! -perm -1000 2>/dev/null # for each: chmod +t <dir> (after confirming it is a shared directory) |
|---|---|
| reason | setting the sticky bit on shared dirs is usually safe but verify each is a real shared dir |
| resource | manual |
pavois harden plan localoù la cible est local, un alias SSH user@hôte, ou un conteneur , Docs
Impact & précautions
Sans bit sticky, les répertoires partagés invitent à la suppression de fichiers, aux attaques par lien symbolique/concurrence et à l'altération. Précautions : examinez chaque chemin avant d'agir, appliquer aveuglément chmod o-w sur un répertoire de spool/socket partagé d'une application peut casser celle-ci, tandis qu'ajouter a+t à un répertoire jamais censé être accessible en écriture par tous masque un problème de permissions plus profond. Privilégiez le retrait de l'écriture pour tous, sauf si la finalité du répertoire exige réellement un accès en écriture partagé (comme /tmp). Testez d'abord sur un hôte hors production quand de nombreux chemins sont retournés.
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 |
| DISA STIG | UBTU-22-232145, UBTU-24-600150 | direct | per OS STIG release | 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.