Ограничете споделен ресурс на Samba до един потребител и един VPN адрес

Параметрите valid users и hosts allow на Samba не свързват човек с адрес: две имена на ресурс могат да изразят тази двойка, а тестовете с кръстосани двойки го доказват.

В този дизайн се бъркат две различни разрешения: кой може да използва папка и кои адреси могат изобщо да се свързват. Записването на списък с акаунти до списък с източници изглежда като свързване, но Samba оценява двата списъка като независими предикати. Приема се всеки, който удовлетворява и двете, а това е по-широко правило, отколкото повечето администратори имат предвид. Поправката е или различно оформление на ресурса, или слой за политики, който може да изрази двойката.

Митът: два списъка правят едно правило

Справочникът smb.conf дефинира valid users и hosts allow като два несвързани параметъра и именно задаването на двата на един ресурс е мястото, където започва объркването. Задайте valid users = mira, tomas и hosts allow = 10.77.0.21, 10.77.0.22 и се приемат четири комбинации: Мира от който и да е от двата адреса, Томас от който и да е от двата адреса. Нищо в конфигурацията не свързва първото име с първия адрес и редът, в който се появяват имената, няма значение. Пренареждането им, добавянето на втори ред hosts allow или поставянето на едно име на ред не променя нищо. Резултатът е произведение на два списъка, а не съответствие между тях.

Това, което повечето хора всъщност искат, е по-тясно: Мира само от един адрес, Томас само от друг. Една дефиниция на ресурс няма синтаксис за такова обвързване и никакво хитро подреждане не го създава. Това е форма на политика, която Samba не изразява в рамките на един ресурс, и точно там митът оцелява.

Какво оценява Samba и в какъв ред

Етапите вървят в фиксиран ред и грешният ред дава грешната диагноза. Клиентът отваря връзка; глобална проверка на хоста се изпълнява, ако е зададена; настройването на сесията удостоверява акаунта; след това клиентът се свързва с ресурс, където се прилагат собственият списък с хостове на този ресурс, valid users и режимът само за четене; и едва когато се отвори файл, решават правата на файловата система на удостоверената идентичност. Всеки етап може сам да отхвърли заявката и преминаването през един не казва нищо за следващия. Важното следствие е, че акаунтът е известен още преди да се оцени списъкът с хостове на ресурса, а списъкът с хостове все още няма начин да назове този акаунт.

Ето защо един ресурс не може да обвърже един потребител с един адрес: hosts allow и valid users са отделни предикати, прилагани на един и същ етап на свързване към дървото, и всеки отговаря на своя въпрос. Предикатът за хост никога не приема името на акаунта като вход, затова не може да се запише за отделен потребител. Двойката може да изрази само втори ресурс или слой за политики извън Samba.

Глобалните стойности са важни заради начина, по който се наследяват. Ресурс, който пропуска hosts allow, наследява глобалната стойност, а ресурс, който задава своя, използва тази стойност вместо глобалната, а не в допълнение към нея. Затова широк глобален списък разширява ресурсите, които никога не задават параметъра, и не прави нищо за ресурс, който определя своя. Изпълнете testparm -s и прочетете стойностите за всеки ресурс, които той отпечатва, защото този изход е ефективната политика, а файлът на диска не е.

Стесняването на един ресурс също не прави нищо за останалата част от сървъра. Другите ресурси, опашките за печат и връзката IPC запазват своите правила, така че дизайн, който разчита на списъка с адреси на един ресурс, защитава един път, а не хоста.

Две имена на ресурс върху една папка

Когато една и съща папка трябва да е достъпна за двама души от два адреса, изложете я два пъти под различни имена. Всеки блок носи един акаунт и един източник, което превръща двойката в нещо, което конфигурацията може да наложи. Цената е, че всеки човек използва различно име на ресурс, за да стигне до същите файлове, и това трябва да е умишлена промяна от страна на клиента.

[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

Портата на ресурса не е право на файловата система. И двете идентичности все още се нуждаят от достъп до папката чрез базовия ACL, а режимът само за четене е втори слой, а не единственият. Дайте право за запис само ако работният поток го изисква, после проверете, че файловете, създадени от една идентичност, остават използваеми от другата.

Двата блока сочат към един път, така че промяна в папката засяга и двата ресурса. Обикновено това е целта, но също означава, че грешка в правата е видима за двамата потребители наведнъж.

Какво може да докаже адресът на източника

Адресът, който Samba вижда, е адресът, който е стигнал до сървъра, а не адресът, който клиентът смята, че има. VPN шлюз, който преобразува всеки клиент в един адрес на източник, унищожава разликата: всички клиенти пристигат като един хост и списъкът с източници вече не може да ги различи. Стабилно разпределение за всеки клиент и шлюз, който запазва източника, са предпоставки за използване на адреси като политика изобщо. Без двете ограничението измерва шлюза, а не потребителя.

Дори тогава адресът не е устройство. Два лаптопа зад един адрес на тунел, преназначен лийз и споделена работна станция заедно опровергават предположението, че източникът идентифицира човек. Отнасяйте се към ограничението като към мрежов обхват и пазете удостоверените SMB акаунти като слой за идентичност, с устройствено удостоверение като сертификат, ако ви трябва авторизация на устройство.

Ето защо дизайнът ограничава ресурсите, а не сървъра. Отхвърлена двойка все още може да отвори сесия, да стигне до друг ресурс или да изброи сървъра, което е различен изход от неуспех на удостоверяването при свързване. Ако изискването е отхвърляне преди удостоверяване, параметрите на ресурсите в Samba са грешният инструмент.

Докажете го с кръстосани двойки

Валидирайте конфигурацията, после тествайте четирите комбинации с нови връзки, а не с използвана наново сесия. Желаната двойка трябва да стигне до папката, а двете кръстосани двойки трябва да се провалят. Кеширана сесия от по-ранен тест с готовност ще отговори за грешната комбинация и ще направи счупено правило да изглежда вярно.

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

Проверката на синтаксиса доказва само, че файлът се парсва. Удостоверенията, ACL и решението за хост се упражняват с реална връзка, затова изпълнете клиентската команда от адреса, който искате да тествате, и наблюдавайте кой етап я отхвърля. Ако кръстосана двойка успее, ефективният списък с хостове е по-широк, отколкото подсказва блокът, и testparm -s е първото, което трябва да прочетете. Ако кръстосана двойка се провали по грешна причина, заподозрени са акаунтът или ACL.

Наблюдението на сесии с smbstatus и прекратяването им е действие за отговор след началото на достъпа, а не контрол на допускането. Блокирането на цял наблюдаван адрес може също да прекъсне несвързани потребители зад същия NAT, затова решението принадлежи в дефиницията на ресурса, а мониторингът – в процеса за отговор. Дръжте двете отделно и дизайнът остава честен за това, което налага.

Подобни статии