Ogranicz udział Samba do jednego użytkownika i jednego adresu VPN

Parametry valid users i hosts allow Samby nie kojarzą osoby z adresem: dwie nazwy udziałów mogą wyrazić tę parę, a testy par krzyżowych to potwierdzają.

W tym projekcie mylone są dwa różne uprawnienia: kto może korzystać z katalogu i które adresy mogą się w ogóle łączyć. Zapisanie listy kont obok listy źródeł wygląda jak kojarzenie, ale Samba ocenia obie listy jako niezależne predykaty. Przyjmowany jest każdy, kto spełnia oba warunki, a to szersza reguła, niż zamierza większość administratorów. Rozwiązaniem jest inny układ udziału albo warstwa polityki, która potrafi wyrazić parę.

Mit: dwie listy dają jedną regułę

Dokumentacja smb.conf definiuje valid users i hosts allow jako dwa niepowiązane parametry, i właśnie ustawienie obu na jednym udziale jest miejscem, gdzie zaczyna się zamieszanie. Ustaw valid users = mira, tomas i hosts allow = 10.77.0.21, 10.77.0.22, a przyjmowane są cztery kombinacje: Mira z obu adresów, Tomas z obu adresów. Nic w konfiguracji nie wiąże pierwszego imienia z pierwszym adresem, a kolejność pojawiania się imion nie ma znaczenia. Zmiana kolejności, dodanie drugiej linii hosts allow albo umieszczenie jednego imienia w linii niczego nie zmienia. Wynikiem jest iloczyn dwóch list, a nie odwzorowanie między nimi.

To, czego większość naprawdę chce, jest węższe: Mira tylko z jednego adresu, Tomas tylko z innego. Jedna definicja udziału nie ma składni dla takiego powiązania i żadna sprytna kolejność go nie tworzy. To kształt polityki, którego Samba nie wyraża w obrębie jednego udziału, i tam mit przetrwa.

Co Samba ocenia i w jakiej kolejności

Etapy biegną w ustalonej kolejności, a zła kolejność daje złą diagnozę. Klient otwiera połączenie; globalne sprawdzenie hosta odbywa się, jeśli jest skonfigurowane; konfiguracja sesji uwierzytelnia konto; następnie klient łączy się z udziałem, gdzie stosowane są jego własna lista hostów, valid users i ustawienie tylko do odczytu; i dopiero gdy plik zostanie otwarty, decydują uprawnienia systemu plików uwierzytelnionej tożsamości. Każdy etap może sam odrzucić żądanie, a przejście jednego nic nie mówi o następnym. Ważnym skutkiem jest to, że konto jest znane, zanim oceniana jest lista hostów udziału, a lista hostów wciąż nie ma sposobu, by nazwać to konto.

Dlatego udział nie może powiązać jednego użytkownika z jednym adresem: hosts allow i valid users to osobne predykaty stosowane na tym samym etapie łączenia drzewa, a każdy odpowiada na własne pytanie. Predykat hosta nigdy nie przyjmuje nazwy konta jako danych wejściowych, więc nie można go zapisać dla użytkownika. Parę może wyrazić tylko drugi udział albo warstwa polityki poza Sambą.

Wartości globalne mają znaczenie z powodu sposobu dziedziczenia. Udział, który pomija hosts allow, dziedziczy wartość globalną, a udział, który ustawia własną, używa jej zamiast globalnej, a nie dodatkowo. Szeroka lista globalna rozszerza więc udziały, które nigdy nie ustawiają parametru, i niczego nie zmienia w udziale, który definiuje własną. Uruchom testparm -s i przeczytaj wypisywane wartości dla każdego udziału, bo ten wynik jest skuteczną polityką, a plik na dysku nie jest.

Zwężenie jednego udziału niczego też nie zmienia w reszcie serwera. Inne udziały, kolejki drukarek i połączenie IPC zachowują własne reguły, więc projekt oparty na liście adresów jednego udziału chroni jedną ścieżkę, a nie hosta.

Dwie nazwy udziałów nad jednym katalogiem

Gdy ten sam katalog musi być osiągalny dla dwóch osób z dwóch adresów, udostępnij go dwa razy pod różnymi nazwami. Każdy blok niesie jedno konto i jedno źródło, co zamienia parę w coś, co konfiguracja może wymusić. Kosztem jest to, że każda osoba używa innej nazwy udziału, by dotrzeć do tych samych plików, i musi to być świadoma zmiana po stronie klienta.

[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

Brama udziału nie jest uprawnieniem systemu plików. Obie tożsamości nadal potrzebują dostępu do katalogu przez bazową ACL, a ustawienie tylko do odczytu jest drugą warstwą, nie jedyną. Przyznaj prawo zapisu tylko wtedy, gdy wymaga tego przepływ pracy, a potem sprawdź, czy pliki utworzone przez jedną tożsamość pozostają użyteczne dla drugiej.

Oba bloki wskazują jedną ścieżkę, więc zmiana w katalogu dotyczy obu udziałów. Zwykle o to chodzi, ale oznacza też, że błąd uprawnień jest widoczny dla obu użytkowników naraz.

Co może udowodnić adres źródłowy

Adres, który widzi Samba, to adres, który dotarł do serwera, a nie ten, który klient uważa za swój. Brama VPN tłumacząca każdego klienta na jeden adres źródłowy znosi tę różnicę: wszyscy klienci przychodzą jako ten sam host i lista źródeł nie może ich już rozróżnić. Stabilne przydzielanie na klienta i brama zachowująca źródło są warunkami wstępnymi używania adresów jako polityki. Bez obu ograniczenie mierzy bramę, a nie użytkownika.

Nawet wtedy adres nie jest urządzeniem. Dwa laptopy za jednym adresem tunelu, ponownie przydzielony leasing i współdzielona stacja robocza obalają założenie, że źródło identyfikuje osobę. Traktuj ograniczenie jako zasięg sieci i utrzymuj uwierzytelnione konta SMB jako warstwę tożsamości, z poświadczeniem urządzenia, na przykład certyfikatem, jeśli potrzebujesz autoryzacji urządzenia.

Dlatego projekt zamyka udziały, a nie serwer. Odrzucona para nadal może otworzyć sesję, dotrzeć do innego udziału lub wylistować serwer, co jest innym wynikiem niż błąd uwierzytelniania przy połączeniu. Jeśli wymaganiem jest odrzucenie przed uwierzytelnieniem, parametry udziałów Samby są niewłaściwym narzędziem.

Udowodnij to parami krzyżowymi

Zweryfikuj konfigurację, a następnie przetestuj cztery kombinacje świeżymi połączeniami, a nie ponownie używaną sesją. Zamierzona para powinna dotrzeć do katalogu, a obie pary krzyżowe powinny zawieść. Sesja z pamięci podręcznej wcześniejszego testu chętnie odpowie za niewłaściwą kombinację i sprawi, że zepsuta reguła wygląda na poprawną.

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

Kontrola składni dowodzi tylko, że plik się parsuje. Dane logowania, ACL i decyzja hosta są sprawdzane przez rzeczywiste połączenie, więc uruchom polecenie klienta z adresu, który chcesz przetestować, i obserwuj, który etap je odrzuca. Jeśli para krzyżowa się powiedzie, skuteczna lista hostów jest szersza, niż sugeruje blok, a testparm -s jest pierwszą rzeczą do przeczytania. Jeśli para krzyżowa zawiedzie z niewłaściwego powodu, podejrzane są konto lub ACL.

Monitorowanie sesji za pomocą smbstatus i ich zabijanie to reakcja po rozpoczęciu dostępu, a nie kontrola wstępu. Zablokowanie całego obserwowanego adresu może też odciąć niepowiązanych użytkowników za tym samym NAT, dlatego decyzja należy do definicji udziału, a monitorowanie do procesu reakcji. Trzymaj te dwie rzeczy osobno, a projekt pozostanie uczciwy co do tego, co wymusza.

Powiązane artykuły