Lien symbolique de dossier en réseau - granularité

Question

Lien symbolique de dossier en réseau - granularité

MOUTRET Olivier 0

Bonjour,

nous pouvons utiliser "MKlink /d" pour créer un dossier de liaison dans un chemin réseau vers un autre dossier du réseau (Distant vers Distant).
Par défaut, nous ne pouvons pas traverser ce dossier réseau, car l'habilitation est désactivé sur le système :

CD %SymLinkD%
Le lien symbolique ne peut pas être suivi car son type est désactivé.

fsutil behavior query mlinkEvaluation
 
Les liens symboliques local à local sont activés
Les liens symboliques local à distant sont activés.
Les liens symboliques distant à local sont désactivés.
Les liens symboliques distant à distant sont désactivés.

Pour un usage sur un poste isolé, la configuration via la commande fsutil est suffisante pour piloter les quatre cas possible. En revanche, pour un déploiement en entreprise, nous privilégierons une GPO, via la stratégie intitulée « Autoriser l’évaluation d’un lien symbolique ».

Cependant, je m’étonne de l'absence de notion de "masque" de chemin : la configuration actuelle impose un choix binaire ("tout ou rien") par catégorie (Local/Distant). Or, la description de cette fonctionnalité souligne des risques de vulnérabilité non négligeables.

Compte tenu du danger potentiel, pourquoi n'existe-t-il pas de granularité permettant de définir une liste de masques pour les sources et les cibles autorisées ?

Pourriez-vous étudier la possibilité de restreindre l'application de cette GPO afin de réduire l'exposition au risque, idéalement via la mise en place d'une liste blanche (whitelist) ?

0 commentaires

1 réponse

Votre réponse

Answer 1

Bonjour,

Vous avez bien identifié le comportement : par défaut, Windows ne permet pas de suivre les liens symboliques « distant → distant » ou « distant → local », et la GPO Autoriser l’évaluation d’un lien symbolique ne propose qu’un contrôle binaire par catégorie. Il n’existe pas de mécanisme natif dans Windows permettant de définir une granularité par masque de chemin ou une liste blanche de sources/cibles autorisées. L’implémentation est volontairement simplifiée pour limiter la complexité et réduire les risques de contournement.

La raison est essentiellement sécuritaire. L’évaluation des symlinks sur des chemins réseau ouvre la porte à des attaques de type traversal ou spoofing si un client peut rediriger vers un partage non approuvé. Microsoft a donc choisi une approche « tout ou rien » par catégorie (local/local, local/distant, distant/local, distant/distant) afin de garantir une cohérence et éviter des scénarios où une règle trop permissive pourrait exposer des données sensibles.

Si vous souhaitez restreindre l’exposition tout en permettant certains cas d’usage, la seule approche supportée est de combiner la GPO avec des ACL et des stratégies réseau. En pratique, vous autorisez l’évaluation des symlinks pour une catégorie donnée, mais vous contrôlez l’accès aux partages via NTFS permissions, SMB share permissions et éventuellement AppLocker ou WDAC pour limiter les processus qui peuvent exploiter ces liens. Cela permet de réduire le risque sans modifier le comportement binaire de la GPO.

Il n’existe pas aujourd’hui de paramètre officiel permettant de définir une liste blanche de chemins pour l’évaluation des symlinks. Si ce besoin est critique dans votre environnement, la seule voie est de mettre en place des contrôles complémentaires au niveau du réseau et des permissions, et de soumettre une demande de fonctionnalité via le canal Feedback Hub ou votre support Microsoft Premier.

En résumé : la granularité par masque n’est pas prévue dans Windows, et la réduction du risque passe par une combinaison de GPO + ACL + contrôle applicatif.

J'espère que vous avez trouvé ces informations utiles. Si elles vous ont permis de mieux comprendre le problème, n'hésitez pas à accepter la réponse. Si vous avez d'autres questions, laissez un message. Bonne journée !

Domic Vo