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

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

[Igor Chudov]

Добрый день, коллеги.

Мы в Саратовском офисе сделали новый control для переключения возможности авторизации sshd с использованием GSSAPI:

http://git.altlinux.org/people/nir/packages/?p=local-policy.git;a=blob;f=controls/sshd-allow-gssapi;h=d30f63e3691632c0c7dcc5e01e6bd91e463a4393;hb=HEAD

Предлагаем забрать его в пакет openssh, так как функционал относится именно к нему.

Было бы здорово услышать Вашу оценку касательно того, стоит ли держать такие вещи в отдельном пакете или сразу интегрировать в соответствующие настройкам пакеты?

-- 
С наилучшими пожеланиями, Чудов Игорь.

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

[Alexey V. Vissarionov]

On 2019-10-08 15:11:22 +0300, Igor Chudov wrote:

 > Мы в Саратовском офисе сделали новый control для переключения
 > возможности авторизации sshd с использованием GSSAPI

s/авторизации/аутентификации/ :-)

 > Предлагаем забрать его в пакет openssh, так как функционал
 > относится именно к нему.

Вопрос номер ноль: кому и зачем может быть нужна эта дырища?

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

 > Было бы здорово услышать Вашу оценку касательно того, стоит ли
 > держать такие вещи в отдельном пакете или сразу интегрировать
 > в соответствующие настройкам пакеты?

В демоне sshd всю нечисть наподобие паролей, сабжа и PAM следует
ампутировать если не на этапе сборки, то в изкоробочном конфиге
уж точно.

С клиентом ssh, увы, сложнее...


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

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

[Dmitry V. Levin]

On Tue, Oct 08, 2019 at 05:21:11PM +0300, Alexey V. Vissarionov wrote:
[...]
> В демоне sshd всю нечисть наподобие паролей, сабжа и PAM следует
> ампутировать

PAM ампутировать?  А если подумать?


-- 
ldv

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

[Alexey V. Vissarionov]

On 2019-10-08 20:30:05 +0300, Dmitry V. Levin wrote:

 >> В демоне sshd всю нечисть наподобие паролей, сабжа и PAM следует
 >> ампутировать
 > PAM ампутировать? А если подумать?

А если подумать, то и список алгоритмов основательно сократить.


З.Ы. (Замечу Ышо): я прекрасно знаю, для чего нужен PAM, но в 99%
рабочих систем не нужно (и даже мешает) то, для чего он нужен.

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

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

[Michael Shigorin]

On Wed, Oct 09, 2019 at 02:58:35PM +0300, Alexey V. Vissarionov wrote:
>  > PAM ампутировать? А если подумать?
> А если подумать, то и список алгоритмов основательно сократить.
> 
> З.Ы. (Замечу Ышо): я прекрасно знаю, для чего нужен PAM, но в 99%
> рабочих систем не нужно (и даже мешает) то, для чего он нужен.

Лёш, у нас репозиторий -- универсальный, а не узкоспециализированный.

Урежь осетра и как вариант -- посмотрите с Димой, получается ли
сделать ручку времени сборки пакета, чтоб тебе для узких задач
получалось легко оторвать то, чего в твоей сборке быть не должно,
при этом в том "1%" случаев не приходилось уродоваться.

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

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

[Alexey V. Vissarionov]

On 2019-10-09 17:53:38 +0300, Michael Shigorin wrote:

 >>> PAM ампутировать? А если подумать?
 >> А если подумать, то и список алгоритмов основательно сократить.
 >> З.Ы. (Замечу Ышо): я прекрасно знаю, для чего нужен PAM, но в
 >> 99% рабочих систем не нужно (и даже мешает) то, для чего он
 >> нужен.
 > Лёш, у нас репозиторий -- универсальный, а не
 > узкоспециализированный.

Я знаю. И именно поэтому системы на его основе для реальных задач
подходят ээээ... так себе.

Добавлять функциональность нужно не по принципу "а чтобы если кому
понадобится, можно было %s", а под конкретные применения. То есть,
должна быть хотя бы явно выраженная хотелка, а не измышления.

 > Урежь осетра и как вариант -- посмотрите с Димой, получается
 > ли сделать ручку времени сборки пакета, чтоб тебе для узких
 > задач получалось легко оторвать то, чего в твоей сборке быть
 > не должно, при этом в том "1%" случаев не приходилось уродоваться.

Ручку-то приделать недолго... но, может, просто сделать отдельную
сборку для этих однопроцентных "меньшинств"?


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

[devel] [JT] задачи альта (was: Новый control для sshd: sshd-allow-gssapi)

[Michael Shigorin]

On Thu, Oct 10, 2019 at 07:55:36AM +0300, Alexey V. Vissarionov wrote:
>  >> З.Ы. (Замечу Ышо): я прекрасно знаю, для чего нужен PAM, но
>  >> в 99% рабочих систем не нужно (и даже мешает) то, для чего
>  >> он нужен.
>  > Лёш, у нас репозиторий -- универсальный, а не
>  > узкоспециализированный.
> Я знаю. И именно поэтому системы на его основе для реальных задач
> подходят ээээ... так себе.

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

> Добавлять функциональность нужно не по принципу "а чтобы если кому
> понадобится, можно было %s", а под конкретные применения. То есть,
> должна быть хотя бы явно выраженная хотелка, а не измышления.

Ну так это обсуждение с такой и началось, если что.

Ты спроси cas@, съезди как-нить на внедрение, посмотри
своими глазами, с чем люди сталкиваются -- а там уже
соображай, наотмашь ли рубить али надо бережно скальпелем
поработать.

У нас нет задачи "сделать всем хорошо".  Равно как и задачи
"сделать офигеть как хорошо одним магистральщикам".

А по факту сборки openssh имени ldv@ за последние лет двадцать
в диких интернетах подвели меня один раз, и это была та самая
первая удалённо эксплуатируемая дырка в установке опёнка по
умолчанию (не уезжай я ровно тем вечером за границу, может,
и подвести-то не успело бы, а так подозрения закрались).

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

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

[Evgeny Sinelnikov]

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

по сути речь о том, стоит ли выносить дополнительные 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)

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

[Alexey V. Vissarionov]

On 2019-10-09 16:10:18 +0400, Evgeny Sinelnikov wrote:

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

Если они ничего не тянут за собой - в общем случае особого смысла нет.

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

Любое включенное, но не настроенное средство аутентификации - дыра,
пока не доказано обратное.

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

Аааа... оно для локалки. Тогда вероятность атаки падает до очень
низкой, и тогда даже при неизменном очень высоком уровне ущерба
уровень риска падает до приемлемого среднего.

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

Прежде всего, это штатное средство SSH. Ну и сами сертификаты на
определенный ключ можно выписывать хоть одноразовые или со сроком
действия в единицы-десятки секунд.

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

Оно требует каких-то сборочных зависимостей? Если да - есть смысл
собирать отдельно openssh и openssh-featured

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

А еще можно просто выкинуть этот параметр и пускать всех, у кого
есть ключ.

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

В локалке пофигу, но может выйти боком на оборудовании, торчащем
голой жопой в дикий интернет.

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

Все же в openssh-featured :-)
Или, соответственно, в openssh-featured-control-gssapi


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

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

[Evgeny Sinelnikov]

Доброй ночи.

ср, 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)

Re: [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

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

[Evgeny Sinelnikov]

чт, 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)

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

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 710 bytes --]

On Tue, Oct 08, 2019 at 03:11:22PM +0300, Igor Chudov wrote:
> Добрый день, коллеги.
> 
> Мы в Саратовском офисе сделали новый control для переключения возможности авторизации sshd с использованием GSSAPI:
> 
> http://git.altlinux.org/people/nir/packages/?p=local-policy.git;a=blob;f=controls/sshd-allow-gssapi;h=d30f63e3691632c0c7dcc5e01e6bd91e463a4393;hb=HEAD
> 
> Предлагаем забрать его в пакет openssh, так как функционал относится именно к нему.

А зачем вы делаете kill -HUP `pgrep -f "sshd -D"` &> /dev/null
- в /etc/control.d/facilities/sshd-password-auth ничего подобного нет.

По аналогии с sshd-password-auth предлагаю переименовать sshd-allow-gssapi
в sshd-gssapi-auth.


-- 
ldv

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

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

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 473 bytes --]

On Thu, Oct 10, 2019 at 09:04:04PM +0400, Evgeny Sinelnikov wrote:
> чт, 10 окт. 2019 г., 19:36 Dmitry V. Levin <ldv@altlinux.org>:
[...]
> > По аналогии с sshd-password-auth предлагаю переименовать sshd-allow-gssapi
> > в sshd-gssapi-auth.
> 
> Почему бы и нет? Давайте так его назовём.
> 
> А клиентский вариант, разрешающий gssapi аутентификацию тогда
> ssh-gssapi-auth. Так получается?

Выглядит нормально, никто не возразил, пусть будет так.


-- 
ldv

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]