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

[Alexey V. Vissarionov]

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 (тот
самый сертификат, упомянутый чуть выше).

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

Вот как раз "из коробки" оно должно быть выключено напрочь.

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

Эта категория все же маргинальна. И как раз для нее я предложил
openssh-featured

 >>> Эти настройки - суть политики. Какие-то из них предполагается
 >>> включать сразу при вводе компьютеров в домен. Но, в целом, они
 >>> самоценны и вне контекста какой-либо инфраструктуры.
 >> В локалке пофигу, но может выйти боком на оборудовании,
 >> торчащем голой жопой в дикий интернет.
 > Да нет же. Это предубеждение. Kerberos создан для работы в диком
 > интернете, как раз.

Помню я этот интернет 20-летней давности...

 >>> Так вот. Как лучше поступить? Держать их в отдельном пакете
 >>> или сразу интегрировать, в openssh?
 >> Все же в openssh-featured :-)
 >> Или, соответственно, в openssh-featured-control-gssapi
 > Нет, нет, нет. Речь не в том, что необходимо пересобирать
 > openssh бинарно. На основании чего вы это решили?

Мы - это кто? Я здесь пишу исключительно от собственного имени.

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

 > Далее хочу пояснить всё это детально (для тех, кто в танке).
 > 1) У нас для настройки локальных политик безопасности уже
 > давно используется такой инструмент, как control.

Ээээ... Да я в общем-то уже почти 20 лет лично знаком с автором.

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

В таком случае - совершенно точно в отдельном пакете.

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

Да сколько угодно. Только в основную систему их не тащите - они
очень уж маргинальны.


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net