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

[Evgeny Sinelnikov <sin@altlinux.org>]

Доброй ночи.

ср, 9 окт. 2019 г. в 17:46, Alexey V. Vissarionov <gremlin@altlinux.org>:
>
> On 2019-10-09 16:10:18 +0400, Evgeny Sinelnikov wrote:
>
>  > по сути речь о том, стоит ли выносить дополнительные control-файлы
>  > в специальный пакет, если они относятся к конкретному пакету? В
>  > данном случае к openssh.
>
> Если они ничего не тянут за собой - в общем случае особого смысла нет.

Хотелось бы ещё мнение мейнтейнера openssh, поскольку "новые штуки",
могут оказаться неожиданностью как для него, так и для опытных
пользователей.

>  >>> Мы в Саратовском офисе сделали новый control для переключения
>  >>> возможности авторизации sshd с использованием GSSAPI
>  >> s/авторизации/аутентификации/ :-)
>  >>> Предлагаем забрать его в пакет openssh, так как функционал
>  >>> относится именно к нему.
>  >> Вопрос номер ноль: кому и зачем может быть нужна эта дырища?
>  > А можно по-подробнее в чём конкретно это дырища, какие конкретно
>  > векторы атак и при каких условиях подразумеваются? Иначе это
>  > звучит слишком голосовно.
>
> Любое включенное, но не настроенное средство аутентификации - дыра,
> пока не доказано обратное.
>
>  > В нашем случае, смысл в этом следующий. У нас довольно активно
>  > пользователи из домена (то бишь админы), начинающие управлять
>  > рабочими станциями, ходят через пароль/логин. Такой вот
>  > windows-подход в домене на базе samba - ничего особенного.
>
> Аааа... оно для локалки. Тогда вероятность атаки падает до очень
> низкой, и тогда даже при неизменном очень высоком уровне ущерба
> уровень риска падает до приемлемого среднего.

Ну, вот и хорошо.

>  >> Есть же PubkeyAuthentication - его достаточно для всего (в
>  >> том числе для сертификатов ssh-rsa-cert-v01@openssh.com и
>  >> ssh-ed25519-cert-v01@openssh.com).
>  > Причём тут сертификаты?
>
> Прежде всего, это штатное средство SSH. Ну и сами сертификаты на
> определенный ключ можно выписывать хоть одноразовые или со сроком
> действия в единицы-десятки секунд.

Прежде всего, речь идёт не только об админах, но и о любом
пользователе в домене. Кроме того, если уж говорить о сертификатах в
таком ключе, то это тоже кромпромиссный случай. Дело в том, что GSSAPI
через Kerberos рулится централизованно, а разбросанные по узлам
публичные ключи в разных файлах настройки поди ещё вычисти при
необходимости забрать быстро доступ.

Да, можно разные ключи можно делать, но всё равно это не даёт
необходимого функционала.

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

Никаких сборочных зависимостей это не требует. Всё уже давно как нужно
собрано и работает из коробки.

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

Нет, нельзя так сделать, есть такая категория пользователей, которым
нужен ssh, а рулить ими нужно из домена. Добавить в схему домена
публичные ключи и привязывать их к пользователям через LDAP - это
прекрасный вариант и он работает во FreeIPA, но у этого варианта своя
ниша.

Если работа идёт с любой машины, на которой ты залогинился. Если
пользователь не привязан к конкретному узлу, то и тема с тасканием с
собой везде всех своих ключей становится уже не столь удобной, да и
безопасной тоже.

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

Да нет же. Это предубеждение. Kerberos создан для работы в диком
интернете, как раз. О доработках в эту тему со стороны Redhat
рассказывал Александр Боковой на конференции в Калуге
(https://www.basealt.ru/about/news/archive/view/programma-xvi-konferencii-razrabotchikov-svobodnykh-prog/).

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

Нет, нет, нет. Речь не в том, что необходимо пересобирать openssh
бинарно. На основании чего вы это решили?

Игорь же (который nir@) привёл в самом первом сообщении ссылку на то,
о чём идёт речь.
http://git.altlinux.org/people/nir/packages/?p=local-policy.git;a=blob;f=controls/sshd-allow-gssapi;h=d30f63e3691632c0c7dcc5e01e6bd91e463a4393;hb=HEAD

Далее хочу пояснить всё это детально (для тех, кто в танке).

1) У нас для настройки локальных политик безопасности уже давно
используется такой инструмент, как control. Список предустановленных
политик, доступных через control, можно получить командой control от
рута без параметров. Если погрепать, то сейчас, для ssh, этот список
выглядит так:
# control | grep ssh
sshd-allow-groups enabled         (enabled disabled)
sshd-password-auth default         (enabled disabled default)

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

3) Реально эти политики у нас упакованы в разных пакетах, для ssh - в
пакете openssh-server-control.
$ rpm -ql openssh-server-control
/etc/control.d/facilities/sftp
/etc/control.d/facilities/sshd-allow-groups
/etc/control.d/facilities/sshd-password-auth

# sudo control sftp
enabled
# sudo control sftp help
enabled: Enable SFTP subsystem
disabled: Disable SFTP subsystem

# sudo control sshd-allow-groups
enabled
# sudo control sshd-allow-groups help
enabled: Enable AllowGroups restriction
disabled: Disable AllowGroups restriction

# sudo control sshd-password-auth
default
# sudo control sshd-password-auth help
enabled: Enable password authentication
disabled: Disable password authentication
default: Reset password authentication setting to the package default

4) По уму, эти политики есть резон расширить, как минимум двумя:
sshd-allow-gssapi и ssh-allow-gssapi

Пример:
# control sshd-allow-gssapi help
disabled: Disable GSSAPI authentication (Single Sign-On feature)
enabled: Use GSSAPI authentication (Single Sign-On feature)
default: Disable GSSAPI authentication (Single Sign-On feature)

5) Таких штук придумано уже достаточно много, но сейчас нужно запилить
ещё больше для конкретных, узких задач.

Так вот. Как лучше поступить? Держать их в отдельном пакете local-policy
или сразу интегрировать, в соответствующие пакеты?

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


-- 
Sin (Sinelnikov Evgeny)