Ограничить общий ресурс 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, поэтому решение принадлежит определению ресурса, а наблюдение — процессу реагирования. Держите эти две вещи раздельно, и проект остаётся честным относительно того, что он обеспечивает.

Похожие статьи