Restreindre un partage Samba à un utilisateur et une adresse VPN

Les paramètres valid users et hosts allow de Samba n’associent pas une personne à une adresse : deux noms de partage peuvent exprimer la paire, et les tests de paires croisées le prouvent.

Dans cette conception, deux autorisations distinctes se confondent : qui peut utiliser un répertoire et quelles adresses peuvent se connecter tout court. Écrire une liste de comptes à côté d’une liste de sources ressemble à un appariement, mais Samba évalue les deux listes comme des prédicats indépendants. Quiconque satisfait les deux est admis, ce qui est une règle plus large que ce que la plupart des administrateurs veulent. Le correctif est soit une autre disposition du partage, soit une couche de politique capable d’exprimer la paire.

Le mythe : deux listes font une règle

La référence smb.conf définit valid users et hosts allow comme deux paramètres sans rapport, et c’est en mettant les deux sur un même partage que la confusion commence. Définissez valid users = mira, tomas et hosts allow = 10.77.0.21, 10.77.0.22 et quatre combinaisons sont admises : Mira depuis l’une ou l’autre adresse, Tomas depuis l’une ou l’autre adresse. Rien dans la configuration ne lie le premier nom à la première adresse, et l’ordre d’apparition des noms n’a aucune signification. Les réordonner, ajouter une seconde ligne hosts allow ou mettre un nom par ligne ne change rien. Le résultat est le produit de deux listes, pas une correspondance entre elles.

Ce que la plupart des gens veulent réellement est plus étroit : Mira depuis une seule adresse, Tomas depuis une autre. Une seule définition de partage n’a pas de syntaxe pour cette liaison, et aucun ordre ingénieux ne la crée. C’est une forme de politique que Samba n’exprime pas dans un seul partage, et c’est là que le mythe survit.

Ce que Samba évalue, et dans quel ordre

Les étapes s’exécutent dans un ordre fixe, et se tromper d’ordre produit le mauvais diagnostic. Un client ouvre une connexion ; une vérification globale d’hôte s’exécute si elle est configurée ; la configuration de session authentifie le compte ; puis le client se connecte à un partage, où s’appliquent sa propre liste d’hôtes, valid users et le réglage en lecture seule ; et ce n’est que lorsqu’un fichier est ouvert que les autorisations du système de fichiers de l’identité authentifiée décident. Chaque étape peut refuser la demande à elle seule, et en passer une ne dit rien de la suivante. La conséquence importante est que le compte est connu au moment où la liste d’hôtes du partage est évaluée, et la liste d’hôtes n’a toujours aucun moyen de nommer ce compte.

C’est pourquoi un partage ne peut pas lier un utilisateur à une adresse : hosts allow et valid users sont des prédicats distincts appliqués à la même étape de connexion d’arborescence, et chacun répond à sa propre question. Le prédicat d’hôte ne prend jamais le nom du compte comme entrée, il ne peut donc pas être écrit par utilisateur. Seul un second partage, ou une couche de politique hors de Samba, peut exprimer la paire.

Les valeurs globales comptent à cause de la manière dont elles sont héritées. Un partage qui omet hosts allow hérite de la valeur globale, et un partage qui définit la sienne utilise cette valeur à la place de la globale, non en plus. Une liste globale large élargit donc les partages qui ne définissent jamais le paramètre et ne fait rien à un partage qui définit le sien. Lancez testparm -s et lisez les valeurs par partage qu’il imprime, car cette sortie est la politique effective, et le fichier sur le disque ne l’est pas.

Restreindre un partage ne fait rien non plus pour le reste du serveur. Les autres partages, les files d’impression et la connexion IPC gardent leurs propres règles, si bien qu’une conception qui repose sur la liste d’adresses d’un seul partage protège un chemin et non l’hôte.

Deux noms de partage sur un répertoire

Lorsque le même répertoire doit être accessible par deux personnes depuis deux adresses, exposez-le deux fois sous des noms différents. Chaque bloc porte un compte et une source, ce qui transforme la paire en quelque chose que la configuration peut imposer. Le coût est que chaque personne utilise un nom de partage différent pour atteindre les mêmes fichiers, et cela doit être un changement délibéré côté client.

[shared-mira]
    path = /srv/shared
    guest ok = no
    read only = yes
    valid users = mira
    hosts allow = 10.77.0.21
    hosts deny = ALL

[shared-tomas]
    path = /srv/shared
    guest ok = no
    read only = yes
    valid users = tomas
    hosts allow = 10.77.0.22
    hosts deny = ALL

Une porte de partage n’est pas une autorisation de système de fichiers. Les deux identités ont toujours besoin d’accéder au répertoire via l’ACL sous-jacente, et le réglage en lecture seule est une seconde couche et non la seule. N’accordez l’accès en écriture que si le flux de travail l’exige, puis vérifiez que les fichiers créés par une identité restent utilisables par l’autre.

Les deux blocs pointent vers un seul chemin, donc un changement dans le répertoire affecte les deux partages. C’est généralement le but, mais cela signifie aussi qu’une erreur d’autorisation est visible par les deux utilisateurs à la fois.

Ce que l’adresse source peut prouver

L’adresse que Samba voit est celle qui a atteint le serveur, pas celle que le client croit avoir. Une passerelle VPN qui traduit chaque client vers une seule adresse source efface la distinction : tous les clients arrivent comme le même hôte et la liste de sources ne peut plus les distinguer. Une attribution stable par client et une passerelle qui préserve la source sont des prérequis pour utiliser des adresses comme politique. Sans les deux, la restriction mesure la passerelle et non l’utilisateur.

Même alors, une adresse n’est pas un appareil. Deux portables derrière une adresse de tunnel, un bail réattribué et un poste de travail partagé démentent tous l’hypothèse qu’une source identifie une personne. Traitez la restriction comme un périmètre réseau et gardez les comptes SMB authentifiés comme couche d’identité, avec un justificatif d’appareil comme un certificat si vous avez besoin d’une autorisation d’appareil.

C’est aussi pourquoi la conception ferme des partages et non le serveur. Une paire refusée peut encore ouvrir une session, atteindre un autre partage ou lister le serveur, ce qui est un résultat différent d’un échec d’authentification à la connexion. Si l’exigence est un rejet avant l’authentification, les paramètres de partage de Samba sont le mauvais outil.

Prouvez-le avec des paires croisées

Validez la configuration, puis testez les quatre combinaisons avec des connexions neuves plutôt qu’une session réutilisée. La paire prévue doit atteindre le répertoire, et les deux paires croisées doivent échouer. Une session en cache d’un test antérieur répondra volontiers pour la mauvaise combinaison et fera passer une règle cassée pour correcte.

testparm -s
smbclient //fileserver/shared-mira -U mira -c 'ls'
smbclient //fileserver/shared-tomas -U tomas -c 'ls'
smbstatus --shares

Une vérification de syntaxe ne prouve que la lecture du fichier. Les identifiants, les ACL et la décision d’hôte s’exercent par une connexion réelle, alors lancez la commande client depuis l’adresse que vous voulez tester et observez quelle étape la refuse. Si une paire croisée réussit, la liste d’hôtes effective est plus large que le bloc ne le suggère, et testparm -s est la première chose à lire. Si une paire croisée échoue pour la mauvaise raison, le compte ou l’ACL sont les suspects.

Surveiller des sessions avec smbstatus et les tuer est une action de réponse après le début de l’accès, pas un contrôle d’admission. Bloquer une adresse entière observée peut aussi déconnecter des utilisateurs sans rapport derrière le même NAT, et c’est pourquoi la décision appartient à la définition du partage et la surveillance au processus de réponse. Gardez les deux séparés et la conception reste honnête sur ce qu’elle impose.

Articles similaires