Restringeix un recurs compartit de Samba a un usuari i una adreça VPN

En aquest disseny es confonen dos permisos diferents: qui pot utilitzar un directori i quines adreces es poden connectar. Escriure una llista de comptes al costat d’una llista d’orígens sembla un aparellament, però Samba avalua les dues llistes com a predicats independents. S’admet qualsevol que satisfaci les dues, cosa que és una regla més àmplia del que la majoria d’administradors volen. La solució és o bé un altre disseny del recurs o bé una capa de política que pugui expressar el parell.

El mite: dues llistes fan una regla

La referència d’smb.conf defineix valid users i hosts allow com dos paràmetres no relacionats, i és en posar tots dos en un sol recurs on comença la confusió. Posa valid users = mira, tomas i hosts allow = 10.77.0.21, 10.77.0.22 i s’admeten quatre combinacions: la Mira des de qualsevol de les dues adreces i en Tomas des de qualsevol de les dues adreces. Res a la configuració no lliga el primer nom amb la primera adreça, i l’ordre en què apareixen els noms no té cap significat. Reordenar-los, afegir una segona línia hosts allow o posar un nom per línia no canvia res. El resultat és el producte de dues llistes, no una correspondència entre elles.

El que la majoria de la gent vol de debò és més estret: la Mira només des d’una adreça i en Tomas només des d’una altra. Una sola definició de recurs no té cap sintaxi per a aquesta vinculació, i cap ordre enginyós no la crea. Aquesta és una forma de política que Samba no expressa dins d’un sol recurs, i aquí és on sobreviu el mite.

Què avalua Samba i en quin ordre

Les etapes segueixen un ordre fix, i equivocar l’ordre produeix el diagnòstic equivocat. Un client obre una connexió; es fa una comprovació global d’amfitrió si n’hi ha una de configurada; la configuració de la sessió autentica el compte; després el client es connecta a un recurs, on s’apliquen la seva pròpia llista d’amfitrions, valid users i el paràmetre de només lectura; i només quan s’obre un fitxer decideixen els permisos del sistema de fitxers de la identitat autenticada. Cada etapa pot rebutjar la petició per si sola, i passar-ne una no diu res de la següent. La conseqüència important és que el compte ja es coneix quan s’avalua la llista d’amfitrions del recurs, i la llista d’amfitrions encara no té cap manera de nomenar aquest compte.

Per això un recurs no pot lligar un usuari amb una adreça: hosts allow i valid users són predicats separats que s’apliquen a la mateixa etapa de connexió de l’arbre, i cadascun respon la seva pròpia pregunta. El predicat d’amfitrió no pren mai el nom del compte com a entrada, així que no es pot escriure per usuari. Només un segon recurs o una capa de política fora de Samba poden expressar el parell.

Els valors globals importen per com s’hereten. Un recurs que omet hosts allow hereta el valor global, i un recurs que estableix el seu propi utilitza aquest valor en lloc del global, no a més a més. Per tant, una llista global àmplia amplia els recursos que mai no defineixen el paràmetre i no fa res a un recurs que defineix el seu. Executa testparm -s i llegeix els valors per recurs que imprimeix, perquè aquesta sortida és la política efectiva i el fitxer del disc no ho és.

Restringir un recurs tampoc no fa res per la resta del servidor. Els altres recursos, les cues d’impressió i la connexió IPC mantenen les seves regles, així que un disseny que es basa en la llista d’adreces d’un sol recurs protegeix un camí i no l’amfitrió.

Dos noms de recurs sobre un directori

Quan el mateix directori ha de ser accessible per dues persones des de dues adreces, exposa’l dues vegades amb noms diferents. Cada bloc porta un compte i un origen, cosa que converteix el parell en una cosa que la configuració pot fer complir. El cost és que cada persona fa servir un nom de recurs diferent per arribar als mateixos fitxers, i això ha de ser un canvi deliberat al costat del 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

Una porta de recurs no és un permís del sistema de fitxers. Totes dues identitats encara necessiten accés al directori a través de l’ACL subjacent, i el paràmetre de només lectura és una segona capa i no l’única. Concedeix accés d’escriptura només si el flux de treball ho requereix, i després comprova que els fitxers creats per una identitat continuen sent utilitzables per l’altra.

Tots dos blocs apunten a un sol camí, així que un canvi al directori afecta els dos recursos. Normalment aquest és el punt, però també vol dir que un error de permisos és visible per als dos usuaris alhora.

Què pot demostrar l’adreça d’origen

L’adreça que veu Samba és l’adreça que ha arribat al servidor, no la que el client creu que té. Una passarel·la VPN que tradueix cada client a una sola adreça d’origen fa desaparèixer la distinció: tots els clients arriben com el mateix amfitrió i la llista d’orígens ja no els pot distingir. Una assignació estable per client i una passarel·la que preservi l’origen són requisits previs per fer servir adreces com a política. Sense totes dues, la restricció mesura la passarel·la i no l’usuari.

I encara així, una adreça no és un dispositiu. Dos portàtils darrere d’una adreça de túnel, una concessió reassignada i una estació de treball compartida desmenteixen la suposició que un origen identifica una persona. Tracta la restricció com a abast de xarxa i mantén els comptes SMB autenticats com a capa d’identitat, amb una credencial de dispositiu com un certificat si necessites autorització de dispositiu.

Això també explica per què el disseny tanca recursos i no el servidor. Un parell rebutjat encara pot obrir una sessió, arribar a un altre recurs o llistar el servidor, cosa que és un resultat diferent d’un error d’autenticació en el moment de la connexió. Si el requisit és el rebuig abans de l’autenticació, els paràmetres de recurs de Samba són l’eina equivocada.

Demostra-ho amb parells encreuats

Valida la configuració i després prova les quatre combinacions amb connexions noves i no amb una sessió reutilitzada. El parell previst ha d’arribar al directori, i tots dos parells encreuats han de fallar. Una sessió en memòria cau d’una prova anterior respondrà de bon grat per la combinació equivocada i farà que una regla trencada sembli correcta.

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

Una comprovació de sintaxi només demostra que el fitxer s’analitza. Les credencials, les ACL i la decisió d’amfitrió s’exerceixen amb una connexió real, així que executa l’ordre del client des de l’adreça que vols provar i mira quina etapa la rebutja. Si un parell encreuat té èxit, la llista efectiva d’amfitrions és més àmplia del que suggereix el bloc, i testparm -s és el primer que cal llegir. Si un parell encreuat falla pel motiu equivocat, el compte o l’ACL són els sospitosos.

Monitorar sessions amb smbstatus i matar-les és una acció de resposta posterior a l’inici de l’accés, no un control d’admissió. Bloquejar tota una adreça observada també pot desconnectar usuaris no relacionats darrere del mateix NAT, i per això la decisió pertany a la definició del recurs i el monitoratge al procés de resposta. Mantén les dues coses separades i el disseny continuarà sent honest sobre què fa complir.