Begrens en Samba-deling til én bruker og én VPN-adresse

Sambas valid users og hosts allow parer ikke en person med en adresse: to delingsnavn kan uttrykke paret, og tester med kryssede par beviser det.

I dette designet blandes to forskjellige tillatelser: hvem som kan bruke en mappe, og hvilke adresser som i det hele tatt kan koble til. Å skrive en kontoliste ved siden av en kildeliste føles som en paring, men Samba vurderer de to listene som uavhengige predikater. Alle som oppfyller begge, slippes inn, og det er en bredere regel enn de fleste administratorer mener. Løsningen er enten et annet delingsoppsett eller et policylag som kan uttrykke paret.

Myten: to lister gir én regel

smb.conf-referansen definerer valid users og hosts allow som to uavhengige parametere, og det er ved å sette begge på én deling at forvirringen starter. Sett valid users = mira, tomas og hosts allow = 10.77.0.21, 10.77.0.22, og fire kombinasjoner slippes inn: Mira fra begge adressene, Tomas fra begge adressene. Ingenting i konfigurasjonen binder det første navnet til den første adressen, og rekkefølgen navnene står i, betyr ingenting. Å omorganisere dem, legge til enda en hosts allow-linje eller sette ett navn per linje endrer ingenting. Resultatet er produktet av to lister, ikke en kobling mellom dem.

Det de fleste faktisk vil ha, er snevrere: Mira bare fra én adresse, Tomas bare fra en annen. Én delingsdefinisjon har ingen syntaks for den bindingen, og ingen mengde smart ordning skaper en. Det er en policyform som Samba ikke uttrykker innenfor én deling, og det er der myten overlever.

Hva Samba vurderer, og i hvilken rekkefølge

Fasene kjører i fast rekkefølge, og feil rekkefølge gir feil diagnose. En klient åpner en forbindelse; en global vertssjekk kjører hvis en er konfigurert; sesjonsoppsettet autentiserer kontoen; deretter kobler klienten til en deling, der delingens egen vertsliste, valid users og skrivebeskyttelsen brukes; og først når en fil åpnes, avgjør filsystemtillatelsene til den autentiserte identiteten. Hvert trinn kan avvise forespørselen alene, og å passere ett sier ingenting om det neste. Den viktige konsekvensen er at kontoen er kjent når delingens vertsliste vurderes, og vertslisten har fortsatt ingen måte å navngi den kontoen på.

Derfor kan en deling ikke binde én bruker til én adresse: hosts allow og valid users er atskilte predikater som brukes på samme tre-forbindelsestrinn, og hver av dem svarer på sitt eget spørsmål. Vertspredikatet tar aldri kontonavnet som input, så det kan ikke skrives per bruker. Bare en annen deling, eller et policylag utenfor Samba, kan uttrykke paret.

Globale verdier betyr noe på grunn av måten de arves på. En deling som utelater hosts allow, arver den globale verdien, og en deling som setter sin egen, bruker den verdien i stedet for den globale, ikke i tillegg til den. Så en bred global liste utvider delingene som aldri setter parameteren, og gjør ingenting med en deling som definerer sin egen. Kjør testparm -s og les verdiene per deling som den skriver ut, for den utskriften er den effektive policyen, og filen på disken er det ikke.

Å snevre inn én deling gjør heller ingenting for resten av serveren. Andre delinger, skriverkøer og IPC-forbindelsen holder sine egne regler, så et design som hviler på én delings adresseliste, beskytter én vei i stedet for verten.

To delingsnavn over én mappe

Når den samme mappen må kunne nås av to personer fra to adresser, eksponer den to ganger under forskjellige navn. Hver blokk bærer én konto og én kilde, noe som gjør paret til noe konfigurasjonen kan håndheve. Prisen er at hver person bruker et annet delingsnavn for å nå de samme filene, og det må være en bevisst endring på klientsiden.

[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

En delingsport er ikke en filsystemtillatelse. Begge identitetene trenger fortsatt tilgang til mappen gjennom den underliggende ACL-en, og skrivebeskyttelsen er et andre lag, ikke det eneste. Gi skrivetilgang bare hvis arbeidsflyten krever det, og kontroller deretter at filer opprettet av den ene identiteten forblir brukbare for den andre.

Begge blokkene peker på én sti, så en endring i mappen påvirker begge delingene. Det er vanligvis poenget, men det betyr også at en tillatelsesfeil er synlig for begge brukerne samtidig.

Hva kildeadressen kan bevise

Adressen Samba ser, er adressen som nådde serveren, ikke adressen klienten tror den har. En VPN-gateway som oversetter hver klient til én kildeadresse, opphever forskjellen: alle klienter ankommer som samme vert, og kildelisten kan ikke lenger skille dem. Stabil tildeling per klient og en gateway som bevarer kilden, er forutsetninger for å bruke adresser som policy i det hele tatt. Uten begge måler begrensningen gatewayen i stedet for brukeren.

Selv da er en adresse ikke en enhet. To bærbare maskiner bak én tunneladresse, en tildelt lease på nytt og en delt arbeidsstasjon motbeviser alle antagelsen om at en kilde identifiserer en person. Behandle begrensningen som nettverksomfang, og hold autentiserte SMB-kontoer som identitetslaget, med en enhetslegitimasjon som et sertifikat hvis du trenger enhetsautorisasjon.

Det er også derfor designet lukker delinger og ikke serveren. Et avvist par kan fortsatt åpne en sesjon, nå en annen deling eller liste serveren, noe som er et annet utfall enn en autentiseringsfeil ved tilkobling. Hvis kravet er avvisning før autentisering, er Sambas delingsparametere feil verktøy.

Bevis det med kryssede par

Valider konfigurasjonen, og test deretter de fire kombinasjonene med friske forbindelser i stedet for en gjenbrukt sesjon. Det tiltenkte paret skal nå mappen, og begge de kryssede parene skal feile. En bufret sesjon fra en tidligere test svarer gjerne for feil kombinasjon og får en ødelagt regel til å se riktig ut.

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

En syntakssjekk beviser bare at filen parses. Påloggingsdetaljer, ACL-er og vertsbeslutningen utøves av en faktisk forbindelse, så kjør klientkommandoen fra adressen du vil teste, og se hvilket trinn som avviser den. Hvis et krysset par lykkes, er den effektive vertslisten bredere enn blokken antyder, og testparm -s er det første som skal leses. Hvis et krysset par feiler av feil grunn, er kontoen eller ACL-en den mistenkte.

Overvåking av sesjoner med smbstatus og nedstenging av dem er en responshandling som tas etter at tilgangen har startet, ikke tilgangskontroll. Å blokkere en hel observert adresse kan også koble fra uvedkommende brukere bak den samme NAT-en, og derfor hører beslutningen til delingsdefinisjonen og overvåkingen til responsprosessen. Hold de to atskilt, og designet forblir ærlig om hva det håndhever.

Relaterte artikler