Beperk 'n Samba-deel tot een gebruiker en een VPN-adres

Twee afsonderlike toestemmings raak in hierdie ontwerp deurmekaar: wie mag 'n gids gebruik, en watter adresse mag hoegenaamd verbind. Om 'n rekeninglys langs 'n bronlys te skryf voel soos 'n koppeling, maar Samba beoordeel die twee lyste eerder as onafhanklike predikate. Enigiemand wat albei bevredig, word toegelaat, wat 'n wyer reël is as wat die meeste administrateurs bedoel. Die regstelling is óf 'n ander uitleg van die deel óf 'n beleidslaag wat 'n paar kan uitdruk.

Die mite: twee lyste maak een reël

Die smb.conf-verwysing definieer valid users en hosts allow as twee onverwante parameters, en dit is waar die verwarring begin wanneer albei op een deel gestel word. Stel valid users = mira, tomas en hosts allow = 10.77.0.21, 10.77.0.22 en vier kombinasies word toegelaat: Mira vanaf enige adres, Tomas vanaf enige adres. Niks in die konfigurasie bind die eerste naam aan die eerste adres nie, en die volgorde waarin die name verskyn het geen betekenis nie. Om hulle te herrangskik, 'n tweede lyn hosts allow by te voeg of een naam per lyn te plaas, verander niks. Die resultaat is die produk van twee lyste, nie 'n koppeling tussen hulle nie.

Wat die meeste mense eintlik wil hê, is nouer: Mira net vanaf een adres, Tomas net vanaf 'n ander. 'n Enkele deeldefinisie het geen sintaksis vir daardie binding nie, en geen mate van slim rangskikking skep een nie. Dit is 'n beleidsvorm wat Samba nie binne een deel uitdruk nie, en dit is waar die mite bly voortbestaan.

Wat Samba evalueer, in volgorde

Die fases loop in 'n vaste volgorde, en om die volgorde verkeerd te kry, lewer die verkeerde diagnose. 'n Kliënt maak 'n verbinding oop; 'n globale gasheertoets loop as een geconfigureer is; sessie-opstelling verifieer die rekening; die kliënt verbind dan aan 'n deel, waar daardie deel se eie gasheerlys, valid users en die alleen-lees-instelling toegepas word; eers wanneer 'n lêer oopgemaak word, besluit die lêerstelseltoestemmings van die geauthentiseerde identiteit. Elke fase kan die versoek op sy eie verwerp, en om een te slaag sê niks oor die volgende nie. Die belangrike gevolg is dat die rekening bekend is teen die tyd dat die deel se gasheerlys geëvalueer word, en die gasheerlys het steeds geen manier om daardie rekening te noem nie.

Dit is waarom 'n deel nie een gebruiker aan een adres kan bind nie: hosts allow en valid users is afsonderlike predikate wat by dieselfde boom-verbinding-fase toegepas word, elkeen wat sy eie vraag beantwoord. Die gasheerpredikaat neem nooit die rekeningnaam as 'n invoer nie, so dit kan nie per gebruiker geskryf word nie. Slegs 'n tweede deel, of 'n beleidslaag buite Samba, kan die paar uitdruk.

GloBale waardes maak saak weens hoe hulle geërf word. 'n Deel wat hosts allow weglaat, erf die globale waarde, en 'n deel wat sy eie stel, gebruik daardie waarde in die plek van die globale een eerder as bykomend daartoe. Dus 'n breë globale lys verbreed die dele wat nooit die parameter stel nie, en doen niks aan 'n deel wat sy eie definieer nie. Voer testparm -s uit en lees die per-deel waardes wat dit druk, want daardie uitset is die effektiewe beleid en die lêer op skyf is dit nie.

Om een deel te vernou, doen ook niks vir die res van die bediener nie. Ander dele, drukkerwagtoues en die IPC-verbinding hou hulle eie reëls, so 'n ontwerp wat op een deel se adreslys staatmaak, beskerm een pad eerder as die gasheer.

Twee deelname oor een gids

Wanneer dieselfde gids vir twee mense vanaf twee adresse bereikbaar moet wees, stel dit twee keer onder verskillende name bloot. Elke blok dra een rekening en een bron, wat die koppeling iets maak wat die konfigurasie kan afdwing. Die koste is dat elke persoon 'n ander deelnaam gebruik om by dieselfde lêers uit te kom, en dit moet 'n doelbewuste verandering aan die kliëntkant wees.

[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

'n Deelhek is nie 'n lêerstelseltoestemming nie. Albei identiteite het steeds toegang tot die gids nodig deur die onderliggende ACL, en die deel se alleen-lees-instelling is 'n tweede laag eerder as die enigste een. Verleen skryftoegang slegs as die werkvloei dit vereis, en kontroleer dan dat lêers wat deur een identiteit geskep is, vir die ander bruikbaar bly.

Albei blokke wys na een pad, so 'n verandering aan die gids raak albei dele. Dit is gewoonlik die punt, maar dit beteken ook dat 'n toestemmingsfout vir albei gebruikers gelyktydig sigbaar is.

Wat die bronadres kan bewys

Die adres wat Samba sien, is die adres wat die bediener bereik het, nie die adres wat die kliënt dink hy het nie. 'n VPN-gateway wat elke kliënt na een bronadres vertaal, laat die onderskeid ineenstort: alle kliënte kom as dieselfde gasheer aan en die bronlys kan hulle nie meer uitmekaar hou nie. Stabiele toewysing per kliënt en 'n gateway wat die bron behou, is voorvereistes om adresse hoegenaamd as beleid te gebruik. Sonder albei meet die beperking die gateway eerder as die gebruiker.

Selfs dan is 'n adres nie 'n toestel nie. Twee skootrekenaars agter een tonneladres, 'n hertoegekende huurkontrak en 'n gedeelde werkstasie verydel almal die aanname dat 'n bron 'n persoon identifiseer. Behandel die beperking as netwerkomvang en hou geverifieerde SMB-rekeninge as die identiteitslaag, met 'n toestelbewys soos 'n sertifikaat as jy toestelmagtiging nodig het.

Dit is ook waarom die ontwerp dele en nie die bediener hek nie. 'n Paar wat geweier word, kan steeds 'n sessie oopmaak, 'n ander deel bereik of die bediener lys, wat 'n ander uitkoms is as 'n verifikasiefout by verbindingstyd. As die vereiste verwerping voor verifikasie is, is Samba se deelparameters die verkeerde instrument.

Bewys dit met gekruiste pare

Valideer die konfigurasie en toets dan die vier kombinasies met vars verbindings eerder as 'n hergebruikte sessie. Die bedoelde paar moet die gids bereik, en albei gekruiste pare moet misluk. 'n Gekasde sessie van 'n vroeëre toets sal met graagte vir die verkeerde kombinasie antwoord en 'n gebreekte reël korrek laat lyk.

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

'n Sintaksiscontrole bewys net dat die lêer ontleed. Geloofsbriewe, ACL's en die gasheerbeslissing word deur 'n werklike verbinding uitgeoefen, so voer die kliëntopdrag vanaf die adres uit wat jy wil toets en kyk watter fase dit weier. As 'n gekruiste paar slaag, is die effektiewe gasheerlys wyer as wat die blok aandui, en testparm -s is die eerste ding om te lees. As 'n gekruiste paar om die verkeerde rede misluk, is die rekening of die ACL die verdagte.

Om sessies met smbstatus te monitor en hulle te beëindig, is 'n reaksie-aksie ná toegang begin het, nie toegangsbeheer nie. Om 'n hele waargenome adres te blokkeer, kan ook onverwante gebruikers agter dieselfde NAT ontkoppel, en daarom hoort die besluit in die deeldefinisie en die monitering in die reaksieproses. Hou die twee apart en die ontwerp bly eerlik oor wat dit afdwing.