Limitare una condivisione Samba a un utente e un indirizzo VPN

In questo progetto si confondono due permessi diversi: chi può usare una directory e quali indirizzi possono connettersi. Scrivere un elenco di account accanto a un elenco di origini sembra un abbinamento, ma Samba valuta i due elenchi come predicati indipendenti. Chi soddisfa entrambi viene ammesso, ed è una regola più ampia di quanto la maggior parte degli amministratori intenda. La correzione è una diversa disposizione della condivisione oppure uno strato di politica che sappia esprimere la coppia.

Il mito: due elenchi fanno una regola

Il riferimento di smb.conf definisce valid users e hosts allow come due parametri non correlati, ed è impostando entrambi su una condivisione che inizia la confusione. Imposta valid users = mira, tomas e hosts allow = 10.77.0.21, 10.77.0.22 e vengono ammesse quattro combinazioni: Mira da uno o l’altro indirizzo, Tomas da uno o l’altro indirizzo. Nulla nella configurazione lega il primo nome al primo indirizzo, e l’ordine in cui compaiono i nomi non ha alcun significato. Riordinarli, aggiungere una seconda riga hosts allow o mettere un nome per riga non cambia nulla. Il risultato è il prodotto di due elenchi, non una corrispondenza tra loro.

Ciò che la maggior parte delle persone vuole davvero è più stretto: Mira solo da un indirizzo, Tomas solo da un altro. Una singola definizione di condivisione non ha sintassi per quel legame, e nessun ordine ingegnoso lo crea. È una forma di politica che Samba non esprime dentro una sola condivisione, ed è lì che il mito sopravvive.

Cosa valuta Samba, e in quale ordine

Le fasi seguono un ordine fisso, e sbagliare l’ordine produce la diagnosi sbagliata. Un client apre una connessione; un controllo globale dell’host viene eseguito se è configurato; la configurazione della sessione autentica l’account; poi il client si connette a una condivisione, dove si applicano il suo elenco di host, valid users e l’impostazione di sola lettura; e solo quando un file viene aperto decidono i permessi del file system dell’identità autenticata. Ogni fase può rifiutare la richiesta da sola, e superarne una non dice nulla sulla successiva. La conseguenza importante è che l’account è noto quando viene valutato l’elenco di host della condivisione, e l’elenco di host non ha ancora modo di nominare quell’account.

Perciò una condivisione non può legare un utente a un indirizzo: hosts allow e valid users sono predicati separati applicati nella stessa fase di connessione dell’albero, e ciascuno risponde alla propria domanda. Il predicato dell’host non prende mai il nome dell’account come input, quindi non può essere scritto per utente. Solo una seconda condivisione, o uno strato di politica fuori da Samba, può esprimere la coppia.

I valori globali contano per come vengono ereditati. Una condivisione che omette hosts allow eredita il valore globale, e una condivisione che imposta il proprio usa quel valore al posto di quello globale, non in aggiunta. Quindi un elenco globale ampio allarga le condivisioni che non impostano mai il parametro e non fa nulla a una condivisione che definisce il proprio. Esegui testparm -s e leggi i valori per condivisione che stampa, perché quell’output è la politica effettiva, e il file su disco non lo è.

Restringere una condivisione non fa nulla neppure per il resto del server. Le altre condivisioni, le code di stampa e la connessione IPC mantengono le proprie regole, quindi un progetto che si basa sull’elenco di indirizzi di una sola condivisione protegge un percorso e non l’host.

Due nomi di condivisione su una directory

Quando la stessa directory deve essere raggiungibile da due persone da due indirizzi, esponila due volte con nomi diversi. Ogni blocco porta un account e un’origine, il che trasforma la coppia in qualcosa che la configurazione può imporre. Il costo è che ogni persona usa un nome di condivisione diverso per raggiungere gli stessi file, e questo deve essere un cambiamento deliberato sul lato 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

Un cancello di condivisione non è un permesso del file system. Entrambe le identità hanno ancora bisogno di accedere alla directory tramite l’ACL sottostante, e l’impostazione di sola lettura è un secondo strato e non l’unico. Concedi l’accesso in scrittura solo se il flusso di lavoro lo richiede, poi verifica che i file creati da un’identità restino utilizzabili dall’altra.

Entrambi i blocchi puntano a un solo percorso, quindi una modifica nella directory influisce su entrambe le condivisioni. Di solito è il punto, ma significa anche che un errore di permessi è visibile a entrambi gli utenti insieme.

Cosa può dimostrare l’indirizzo di origine

L’indirizzo che Samba vede è quello che ha raggiunto il server, non quello che il client crede di avere. Un gateway VPN che traduce ogni client in un solo indirizzo di origine annulla la distinzione: tutti i client arrivano come lo stesso host e l’elenco delle origini non può più distinguerli. Un’assegnazione stabile per client e un gateway che preserva l’origine sono prerequisiti per usare gli indirizzi come politica. Senza entrambi, la restrizione misura il gateway e non l’utente.

Anche allora, un indirizzo non è un dispositivo. Due portatili dietro un indirizzo di tunnel, un lease riassegnato e una postazione condivisa smentiscono l’ipotesi che un’origine identifichi una persona. Tratta la restrizione come perimetro di rete e mantieni gli account SMB autenticati come strato di identità, con una credenziale di dispositivo come un certificato se ti serve l’autorizzazione del dispositivo.

È anche per questo che il progetto chiude condivisioni e non il server. Una coppia rifiutata può comunque aprire una sessione, raggiungere un’altra condivisione o elencare il server, che è un esito diverso da un errore di autenticazione al momento della connessione. Se il requisito è il rifiuto prima dell’autenticazione, i parametri di condivisione di Samba sono lo strumento sbagliato.

Dimostralo con coppie incrociate

Valida la configurazione, poi prova le quattro combinazioni con connessioni nuove invece di una sessione riutilizzata. La coppia prevista dovrebbe raggiungere la directory, ed entrambe le coppie incrociate dovrebbero fallire. Una sessione in cache di un test precedente risponderà volentieri per la combinazione sbagliata e farà sembrare corretta una regola rotta.

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

Un controllo di sintassi dimostra solo che il file viene analizzato. Credenziali, ACL e la decisione sull’host si esercitano con una connessione reale, quindi esegui il comando client dall’indirizzo che vuoi provare e osserva quale fase lo rifiuta. Se una coppia incrociata riesce, l’elenco effettivo di host è più ampio di quanto suggerisca il blocco, e testparm -s è la prima cosa da leggere. Se una coppia incrociata fallisce per il motivo sbagliato, l’account o l’ACL sono i sospetti.

Monitorare le sessioni con smbstatus e terminarle è un’azione di risposta dopo l’inizio dell’accesso, non un controllo di ammissione. Bloccare un intero indirizzo osservato può anche disconnettere utenti non correlati dietro lo stesso NAT, ed è per questo che la decisione appartiene alla definizione della condivisione e il monitoraggio al processo di risposta. Tieni le due cose separate e il progetto resta onesto su ciò che impone.