Re: [devel] Новый control для sshd: sshd-allow-gssapi

[Evgeny Sinelnikov <sin@altlinux.org>]

чт, 10 окт. 2019 г. в 10:31, Alexey V. Vissarionov <gremlin@altlinux.org>:
>
> On 2019-10-09 23:54:55 +0400, Evgeny Sinelnikov wrote:
>
>  >>> В нашем случае, смысл в этом следующий. У нас довольно активно
>  >>> пользователи из домена (то бишь админы), начинающие управлять
>  >>> рабочими станциями, ходят через пароль/логин. Такой вот
>  >>> windows-подход в домене на базе samba - ничего особенного.
>  >> Аааа... оно для локалки. Тогда вероятность атаки падает до очень
>  >> низкой, и тогда даже при неизменном очень высоком уровне
>  >> ущерба уровень риска падает до приемлемого среднего.
>  > Ну, вот и хорошо.
>
> Ну, не прям "хорошо", но приемлемо.
>
>  >>>> Есть же PubkeyAuthentication - его достаточно для всего (в
>  >>>> том числе для сертификатов ssh-rsa-cert-v01@openssh.com и
>  >>>> ssh-ed25519-cert-v01@openssh.com).
>  >>> Причём тут сертификаты?
>  >> Прежде всего, это штатное средство SSH. Ну и сами сертификаты
>  >> на определенный ключ можно выписывать хоть одноразовые или
>  >> со сроком действия в единицы-десятки секунд.
>
> На всякий случай: здесь я описываю реальную практическую задачу.
>
>  > Прежде всего, речь идёт не только об админах, но и о любом
>  > пользователе в домене. Кроме того, если уж говорить о
>  > сертификатах в таком ключе, то это тоже кромпромиссный
>  > случай. Дело в том, что GSSAPI через Kerberos рулится
>  > централизованно,
>
> Дык и CA (а лучше RA) управляется централизованно.
>
>  > а разбросанные по узлам публичные ключи в разных файлах
>  > настройки поди ещё вычисти при необходимости забрать быстро
>  > доступ.
>
> Ключей там при такой настройке нет - только сертификат CA.
>
>  > Да, можно разные ключи можно делать, но всё равно это не даёт
>  > необходимого функционала.
>
> Ключ в этом случае нужен один. Открытый. Принадлежащий CA (тот
> самый сертификат, упомянутый чуть выше).

Я не понимаю о чём, в данном случае, идёт речь. Можно конкретные
ссылки на документацию для "особо одарённых", вроде меня, о том как
это применять на практике в рассматриваемых рамках? Я не понимаю что я
такого пропустил по теме аутентификации. Как предлагаемый вами
механизм использовать для, к примеру, 100 пользователей на 20 рабочих
станциях одной организации. На основании чего они аутентифицируются
при локальном и удалённом, через ssh, логине? Есть какие-то конкретные
примеры?

Ну, если конкретнее. Вот мы развернули домен на Samba или FreeIPA. Что
предлагается в качестве стека аутентификации авторизации и как он
должен быть интегрирован с этими доменами? На каких носителях
прелагается хранить сертификаты? В токенах? (ну, там много вопросов и
мало готовых решений)

То есть я вот заметил уязвимость:
- не стоит ходить на машины по паролю/логину, как это делается почти у
всех (например, в ГНИВЦе);
- нужно рекомендовать использовать GSSAPI для входа по ssh в домене.

Предлагаю добавить ручку:
- чтобы на всех рабочих станциях это дело можно было централизованно включить;
- для этого хочу control, который это включает.

Ну, можно без control'а обойтись, но в рамках дистрибутивного решения
смысл добавить есть, поскольку это вписывается как расширение
существующего функционала.

А что предлагаете вы?


>  >>> Кроме включения GSSAPI для серверной стороны (sshd-allow-gssapi),
>  >>> нужен аналогичный - для клиентской (ssh-allow-gssapi).
>  >> Оно требует каких-то сборочных зависимостей? Если да - есть
>  >> смысл собирать отдельно openssh и openssh-featured
>  > Никаких сборочных зависимостей это не требует. Всё уже давно
>  > как нужно собрано и работает из коробки.
>
> Вот как раз "из коробки" оно должно быть выключено напрочь.

Что "оно"? О чём вы? openssh собран с поддержкой GSSAPI. GSSAPI, по
умолчанию, выключен. Что вы ещё по пакетам разбить предлагаете?

Подход, который у нас сложился в плане "оно должно быть выключено
напрочь" выглядит так:
- в дистрибутивах всё, по умолчанию, сильно закручено;
- откручивать вручную и объяснять каждому начинающиму пользователю и
администратору где и что у нас нужно открутить, чтобы что-то
заработало - дело утомительное и непродуктивное;
- наши решения из-за этого иногда просто не используют (ресурса не
хватает, чтобы разобраться).

Это компромиссный момент. Я не претендую с ним спорить, и даже сам во
многом, согласен. Но речь-то не об этом. А о том, чтобы было понятно
как "включить". Для этого предлагается расширить список "ручек" для
настройки.

>  >>> Ещё одна настройка, которая кажется интересной и которой я
>  >>> постоянно пользуюсь - это группа remote [...]
>  >> А еще можно просто выкинуть этот параметр и пускать всех,
>  >> у кого есть ключ.
>  > Нет, нельзя так сделать, есть такая категория пользователей,
>  > которым нужен ssh, а рулить ими нужно из домена.
>
> Эта категория все же маргинальна. И как раз для нее я предложил
> openssh-featured

Нет, это вы что-то путаете на счёт маргинальности с точностью до наоборот.

Суть предложения в виде названия openssh-featured я не понял.
Раскройте содержательную часть предложения, пожалуйста.


>  >>> Эти настройки - суть политики. Какие-то из них предполагается
>  >>> включать сразу при вводе компьютеров в домен. Но, в целом, они
>  >>> самоценны и вне контекста какой-либо инфраструктуры.
>  >> В локалке пофигу, но может выйти боком на оборудовании,
>  >> торчащем голой жопой в дикий интернет.
>  > Да нет же. Это предубеждение. Kerberos создан для работы в диком
>  > интернете, как раз.
>
> Помню я этот интернет 20-летней давности...
>
>  >>> Так вот. Как лучше поступить? Держать их в отдельном пакете
>  >>> или сразу интегрировать, в openssh?
>  >> Все же в openssh-featured :-)
>  >> Или, соответственно, в openssh-featured-control-gssapi
>  > Нет, нет, нет. Речь не в том, что необходимо пересобирать
>  > openssh бинарно. На основании чего вы это решили?
>
> Мы - это кто? Я здесь пишу исключительно от собственного имени.

Извини, это я к тебе так обратился на "Вы".

> А разные сборки мне видятся вполне естественным решением.

Прекрасно, делайте, если нужно. У меня нет ни повода, ни желания
делать отдельную сборку openssh в рамках рассматриваемого вопроса.
Текущая сборка openssh меня вполне устраивает.

>  > Далее хочу пояснить всё это детально (для тех, кто в танке).
>  > 1) У нас для настройки локальных политик безопасности уже
>  > давно используется такой инструмент, как control.
>
> Ээээ... Да я в общем-то уже почти 20 лет лично знаком с автором.
>
>  > 2) Этот инструмент позволяет задавать настройки, которые
>  > позволяют понизить или повысить уровень закрученных гаек,
>  > что-то включить или выключить.
>  > 3) Реально эти политики у нас упакованы в разных пакетах,
>  > для ssh - в пакете openssh-server-control
>  > 4) По уму, эти политики есть резон расширить, как минимум
>  > двумя: sshd-allow-gssapi и ssh-allow-gssapi
>  > 5) Таких штук придумано уже достаточно много, но сейчас
>  > нужно запилить ещё больше для конкретных, узких задач.
>  > Так вот. Как лучше поступить? Держать их в отдельном пакете
>  > local-policy или сразу интегрировать, в соответствующие пакеты?
>
> В таком случае - совершенно точно в отдельном пакете.

Не уверен. Я бы хотел услышать мнение каждого отдельного мейнтейнера
на этот счёт, поскольку существующие control'ы у каждого пакета свои.


>  > Понятно, что нужно делать и предлагать по каждому пакету
>  > отдельно.  Пока речь шла об openssh и том, что новые control'ы
>  > можно сразу туда и добавить. Технически, это не столь важно,
>  > как организационно. Тут, скорее, вопрос ставится так: "Мы
>  > хотим напилить много новых control'ов. Просим и предлагаем
>  > подключиться к их разработке и тестированию."
>
> Да сколько угодно. Только в основную систему их не тащите - они
> очень уж маргинальны.

Да нет же. Что тут у нас маргинально я бы поспорил, но не в этом
вопрос. Вопрос в том, зачем вы это слово столько раз употребили? Из
открытых источников известно, что "индивидуальная маргинальность
характеризуется неполным вхождением индивида в группу, которая его
полностью не принимает, и его отчуждением от группы происхождения,
которая его отторгает как отступника."

В каком смысле тут кто маргинален? И что значит "в основную систему их
не тащите"? А куда мне их тащить?

Я то, как раз, и хотел бы в данном случае, чтобы sshd-allow-gssapi и
ssh-allow-gssapi попали в openssh-server-control. Но их нужно написать
и ещё отладить. И меня волновал порядок этой отладки и перехода из
сторонного пакета в основной. А также готовность других мейгтейнеров
(в пакетах которых есть control'ы или в пакеты которых стоило бы их
добавить) этим заниматься в том или ином порядке.

В предложенном к рассмотрению подходе control'ы - это инструмент,
который может быть использован для обобщённого управления множеством
подобных узлов. Каждый отдельный узел, вручную, можно и без всяких
control'ов настраивать. Но даже для этого нужно помнить что и в каком
файле требуется настроить.


-- 
Sin (Sinelnikov Evgeny)