← Toutes les règles
SOCLE-CLD-SYS-005// Kernel & network (sysctl)moyenneruntime effectif

Activer le paramètre noyau pour appliquer le DAC sur les liens symboliques

Définit fs.protected_symlinks=1 pour que les liens symboliques dans les répertoires sticky accessibles en écriture par tous ne soient suivis que si les contraintes de propriété correspondent, bloquant les courses par suivi de lien symbolique.

Vérifié sur l’état résolu en cours d’exécution (ex. sshd -T, sysctl, systemctl show), attrape les drop-ins et Include qu’une lecture de fichier raterait. Réserve : runtime ≠ persistance ; une valeur correcte maintenant peut ne pas survivre à un redémarrage.

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

Pavois vérifie la configuration effective, l’état résolu et réellement appliqué, pas un fichier. Les scanners basés fichier (OVAL/SCAP, Lynis) ratent les Include, drop-ins et défauts runtime ; ce check voit ce qui est réellement en vigueur.

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

Avec fs.protected_symlinks=1, le noyau ne suit un lien symbolique dans un répertoire sticky accessible en écriture par tous que lorsque le propriétaire du lien correspond à celui qui le suit, ou que les propriétaires du lien et du répertoire correspondent. Cela bloque la course par suivi de lien symbolique classique, où un attaquant place un lien symbolique dans /tmp pointant vers un fichier sensible afin qu'un programme privilégié écrive à travers lui. Appliquer le DAC à la résolution des liens symboliques ferme un vecteur d'exploitation contre un usage non sûr de open() ou creat().

Ce que vérifie Pavois

Pavois lit la valeur effective du noyau via la ressource kernel_parameter (équivalent à sysctl fs.protected_symlinks), et non /etc/sysctl.conf ou un drop-in *.conf. Un fichier configuré peut n'avoir jamais été appliqué (faute de frappe, ordre de chargement, drop-in qui l'écrase) ; lire le noyau en cours d'exécution montre ce qui est réellement appliqué.

describe kernel_parameter('fs.protected_symlinks') do
  its('value') { should cmp 1 }
end
describe command("grep -hsE '^[[:space:]]*fs.protected_symlinks[[:space:]]*=[[:space:]]*1([[:space:]]|$)' /etc/sysctl.conf /etc/sysctl.d/*.conf /run/sysctl.d/*.conf /usr/lib/sysctl.d/*.conf /lib/sysctl.d/*.conf 2>/dev/null") do
  its('stdout') { should match(/\S/) }
end

Comment vérifier qu’elle est appliquée

Exécutez sysctl fs.protected_symlinks, sortie attendue fs.protected_symlinks = 1.

Inspecter et investiguer

Lisez la valeur courante avec sysctl fs.protected_symlinks ou cat /proc/sys/fs/protected_symlinks. Un suivi de lien symbolique bloqué renvoie EACCES à l'appelant ; le noyau ne le journalise pas par défaut, consultez donc la sortie d'erreur du programme affecté.

Remédiation

Le plan de durcissement de Pavois définit la clé sysctl fs.protected_symlinks à 1, la persiste dans un drop-in géré et l'applique à chaud, de sorte que le noyau en cours d'exécution comme les démarrages futurs l'utilisent. Appliqué avec pavois harden apply.

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

keyfs.protected_symlinks
resourcesysctl
value1
pavois harden plan local

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

Impact & précautions

Risque négligeable ; activé par défaut sur la plupart des distributions modernes. Les logiciels normaux ne sont pas affectés car ils ne dépendent pas du suivi des liens symboliques d'autres utilisateurs dans les répertoires partagés. Réversible en remettant la clé à 0.

Mapping des normes

NormeRéférenceTypeVersionConfiance
ANSSI BP-028R14direct2.0haute
NISTAC-6(1), CM-6(a)support800-53 Rev 5 · 800-171 Rev 2 (pinned)moyenne
CIS1.5.3directper OS, see the benchmark tablehaute

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