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

[Evgeny Sinelnikov <sin@altlinux.org>]

Здравствуйте,

по сути речь о том, стоит ли выносить дополнительные control-файлы в
специальный пакет, если они относятся к конкретному пакету? В данном
случае к openssh.

вт, 8 окт. 2019 г. в 18:21, Alexey V. Vissarionov <gremlin@altlinux.org>:
>
> On 2019-10-08 15:11:22 +0300, Igor Chudov wrote:
>
>  > Мы в Саратовском офисе сделали новый control для переключения
>  > возможности авторизации sshd с использованием GSSAPI
>
> s/авторизации/аутентификации/ :-)
>
>  > Предлагаем забрать его в пакет openssh, так как функционал
>  > относится именно к нему.
>
> Вопрос номер ноль: кому и зачем может быть нужна эта дырища?

А можно по-подробнее в чём конкретно это дырища, какие конкретно
векторы атак и при каких условиях подразумеваются? Иначе это звучит
слишком голосовно.

В нашем случае, смысл в этом следующий. У нас довольно активно
пользователи из домена (то бишь админы), начинающие управлять рабочими
станциями, ходят через пароль/логин. Такой вот windows-подход в домене
на базе samba - ничего особенного.

Но... Если рабочая станция в домене Active Directory (впрочем это
относится также к FreeIPA и любому другому домену на базе Kerberos) и
на ней у пользователя имеются рутовые права, то заходить на неё по
паролю/логину удалённо, в целом, уже небезопасно. При таком логине не
контролируется явно получение TGT, которым можно воспользоваться. Это
раз. При таком логине, можно "подслушать" пароль, поскольку доверие в
домене построено не по узлам. Это два. То есть, по умолчанию, в общем
случае, хост заранее скомпроментирован возможным недобросовсестным
пользователем.

Вход по GSSAPI этот вектор атаки позволяет обойти.

> Есть же PubkeyAuthentication - его достаточно для всего (в
> том числе для сертификатов ssh-rsa-cert-v01@openssh.com и
> ssh-ed25519-cert-v01@openssh.com).

Причём тут сертификаты?

>  > Было бы здорово услышать Вашу оценку касательно того, стоит ли
>  > держать такие вещи в отдельном пакете или сразу интегрировать
>  > в соответствующие настройкам пакеты?
>
> В демоне sshd всю нечисть наподобие паролей, сабжа и PAM следует
> ампутировать если не на этапе сборки, то в изкоробочном конфиге
> уж точно.
>
> С клиентом ssh, увы, сложнее...

Кроме включения GSSAPI для серверной стороны (sshd-allow-gssapi),
нужен аналогичный - для клиентской (ssh-allow-gssapi).

Ещё одна настройка, которая кажется интересной и которой я постоянно
пользуюсь - это группа remote:
# grep remote /etc/openssh/sshd_config
AllowGroups wheel remote

Суть наличия дополнительной группы в том, чтобы дать право на
удалённый логин через ssh, не выдавая права на запуск su (то есть не
добавляя в группу wheel).

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

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


-- 
Sin (Sinelnikov Evgeny)