Re: [devel] Нелокальный вариант настроек PAM (system-auth и system-policy)

[Mikhail Novosyolov <mikhailnov@altlinux.org>]

05.12.2019 03:49, Evgeny Sinelnikov пишет:
> Доброй ночи.
>
> вт, 3 дек. 2019 г. в 17:58, Mikhail Novosyolov <mikhailnov@altlinux.org>:
>> 29.11.2019 00:38, Evgeny Sinelnikov пишет:
>>> пт, 29 нояб. 2019 г. в 00:51, Mikhail Novosyolov <mikhailnov@altlinux.org>:
>>>> 28.11.2019 22:47, Evgeny Sinelnikov пишет:
>>>>> чт, 28 нояб. 2019 г. в 17:56, Mikhail Novosyolov <mikhailnov@altlinux.org>:
>>>>>> Добрый вечер!
>>>>>>
>>>>>> 28.11.2019 08:52, Evgeny Sinelnikov пишет:
>>>>>>> Доброе утро!
>>>>>>>
>>>>>>> чт, 28 нояб. 2019 г. в 05:14, Mikhail Novosyolov <mikhailnov@altlinux.org>:
>>>>>>>> 27.11.2019 22:16, Evgeny Sinelnikov пишет:
>>>>>>>>> <...>
>>>>>>>>>>> <...>
>>>>>>>>>>> Настройка system-policy расширяемая и включает в себя, по умолчанию,
>>>>>>>>>>> две политики - local и global.
>>>>>>>>>>>
>>>>>>>>>>> ~ # control system-policy help
>>>>>>>>>>> global: global session policy with mkhomedir
>>>>>>>>>>> local: local session policy
>>>>>>>>>>> ~ # control system-policy summary
>>>>>>>>>>> system session policy type
>>>>>>>>>>> ~ # control system-policy help
>>>>>>>>>>> global: global session policy with mkhomedir
>>>>>>>>>>> local: local session policy
>>>>>>>>>>> ~ # control system-policy
>>>>>>>>>>> local
>>>>>>>>>>>
>>>>>>>>>>> По сути, первая от второй отличается только одним - наличием модуля
>>>>>>>>>>> pam_mkhomedir.so
>>>>>>>>>>>
>>>>>>>>>>> ~ # cat /etc/pam.d/system-policy-local
>>>>>>>>>>> #%PAM-1.0
>>>>>>>>>>> session         required        pam_mktemp.so
>>>>>>>>>>> session         required        pam_limits.so
>>>>>>>>>>> ~ # cat /etc/pam.d/system-policy-global
>>>>>>>>>>> #%PAM-1.0
>>>>>>>>>>> session         required        pam_mktemp.so
>>>>>>>>>>> session         required        pam_mkhomedir.so silent
>>>>>>>>>>> session         required        pam_limits.so
>>>>>>>>>>>
>>>>>>>>>>> <...>
>>>>>>>>>>>
>>>>>>>> Хотелось бы поинтересоваться, рассматривали ли вы вопрос pam_mkhomedir
>>>>>>>> vs pam_oddjob_mkhomedir?
>>>>>>> Рассматривали. Пока не определились.
>>>>>>>
>>>>>>>> Использовать dbus для создания домашней директории из-под pam кажется
>>>>>>>> совсем перебором, но то, что это решает проблемы с контекстами selinux
>>>>>>>> (https://access.redhat.com/discussions/903523#comment-766163), весьма
>>>>>>>> разумно.
>>>>>>> Нет, я не думаю, что это сильно перебор. Сейчас dbus везде. Ну, просто
>>>>>>> везде. NetworkManager - это dbus, udisks2 - тоже, polkit - снова...
>>>>>> Разумно... Спасибо за ответ. Это не будет нормально работать при логине,
>>>>>> когда система не запущена, но такое может быть разве что в chroot, так
>>>>>> что почти не актуально.
>>>>> Почему не будет? Там всё опционально включено.
>>>>>
>>>>>>> В штуках сейчас этих попугаев, как раз, тридцать восемь у меня:
>>>>>>> $ LC_ALL=C apt-cache whatdepends libdbus | grep "Depends:
>>>>>>> <libdbus-1.so.3()(64bit)>" | wc -l
>>>>>>> 38
>>>>>>>
>>>>>>> Ну, и да... Именно вопрос selinux для RedHat был ключевым в данном случае.
>>>>>>>
>>>>>>> В нашем случае. Вот прям сейчас. Сделан pam_oddjob_gpupdate, взят за
>>>>>>> основу pam_oddjob_mkhomedir и отпилен от основного проекта:
>>>>>>> https://github.com/altlinux/oddjob-gpupdate
>>>>>>> http://git.altlinux.org/people/sin/packages/oddjob-gpupdate.git
>>>>>> Круто! Но разобраться в этом очень сложно, т.к. не сохранена
>>>>>> оригинальная история git, невозможно понять, какие изменения были сделаны.
>>>>> Ну, не было задачи сохранить историю. Была задача, наоборот, отпилить.
>>>>> Там оригинального кода, когда я его почищу, будет очень немного.
>>>>>
>>>>>>> Это модуль, позволяющий запускать из-под пользователя инструмент по
>>>>>>> обновлению групповых политик с правами администратора. Служба oddjob
>>>>>>> используется в данном случае для двух задач:
>>>>>>> - для запуска процесса обновления групповых политик во время логина;
>>>>>>> - для ручного запуска обновления групповых политик пользователем.
>>>>>>>
>>>>>>> Сам gpupdate разрабатывается отдельно и готовится вместе в
>>>>>>> oddjob-gpupdate уехать в сизиф.
>>>>>>>
>>>>>>> Собственно, ради гибкого управления настройками этих модулей нам и
>>>>>>> понадобился новый, гибкий control-метод system-policy, тесно увязанный
>>>>>>> с уже существующим control-методом system-auth.
>>>>>> А authconfig не рассматривали? Я почти не смотрел control, в нем
>>>>>> какие-то скрипты для редактирования конфигов pam, не придете ли вы с ним
>>>>>> к authconfig - куче слабо предсказуемых if..else?
>>>>> По этому поводу предлагаю ознакомиться с интереснейшим докладом
>>>>> Александра Бокового из Red Hat на прошедшей осенью конференции в
>>>>> Калуге - http://0x1.tv/20190828D
>>>>>
>>>>> Цитата из тезисов: "Как результат, модули nss-pam-ldapd, pam_krb5,
>>>>> pam_pkcs11 были убраны из Red Hat Enterprise Linux 8. Утилита
>>>>> конфигурирования authconfig была заменена на authselect, а управление
>>>>> первоначальной настройкой для доменных сред унифицировано утилитой
>>>>> realm."
>>>>>
>>>>> У нас всё довольно просто и надеюсь вполне надёжно. Никакой динамики
>>>>> пока не предвидится. Хотя authselect я пока не разбирал.
>>>> Я внимательно смотрел запись этого доклада. Вряд ли скрипты - это просто
>>>> пос равнению с готовыми шаблонами в authselect. authconfig заменили на
>>>> authselect, т.к. authselect предоставляет готовые протестированные
>>>> шаблоны конфигов с минимальными вариациями и не занимается правкой
>>>> существующих конфигов как authconfig.
>>> Всё верно, но и у нас никто файлы просто так не генерирует. Их
>>> устанавливают приложения причём в строго ограниченном ключе. Я думаю,
>>> что было бы интереснее отталкиваться от вариантов использования.
>>>
>>> Какие задачи решаются с помощью authselect? Какие из этих задач мы не
>>> можем решать, используя наши текущие наработки в виде расширяемых
>>> control system-auth и system-policy?
>>>
>> Скрипты могут решить больше задач, чем набор готовых вариативных шаблонов.
>>
>> Основная задача authselect - предопределенные предсказуемо работающие
>> конфигурации вместо множества вариантов сочетаний, получаемых правкой
>> конфигов скриптами. В случае authselect, мне кажется, требуется больше
>> централизации, потому что для добавления функции придется править чей-то
>> чужой шаблон, а в случае скриптов можно скриптом поправить конфиги.
>>
>> Оба подхода имеют право на жизнь)
>>
> Погодите, тогда у нас третий вариант. Мы практически не правим конфиги
> скриптами. По-крайней мере в стандартных конфигурациях. Из того, что
> мне известно - это pam_mount. Так он и у них тоже не предусмотрен.
>
> В нашем случае, основные варианты настроек представлены шаблонами и
> включаются через символические ссылки. А устанавливаются эти шаблоны
> из пакетов или создаются руками. Так что проблемы, которые решает
> authselect, вслед за authconfig, у нас практически отсутствуют.

Пересмотрел исходники http://git.altlinux.org/tasks/240988

Освежил память, действительно, там шаблоны, но, когда писал, меня смутил /etc/control.d/facilities/pam_mktemp из пакета pam-config-control, этот скрипт в лоб правит файлы. В authselect вместо таких правок пересоздание конфига из шаблона с нужным with-*.

Получается, совмещаются и готовые кофниги, подключаемые симлинками, и правки скриптами.

> Возможно, при этом, отсутствуют и полезные задачи, которые у нас не
> решаются. И вот мой-то вопрос, как раз, об этом. А какие задачи решает
> authselect?

Предсказуемость получаемой конфигурации стека PAM+nsswitch.conf, то есть того, что правится для ввода в домен. При централизации настроек PAM через такие средства нельзя положить в некий пакет некий скрипт, который будет сам править конфиги. Это плохо меньшей гибкостью, хорошо большей предсказуемостью и типизацией обработки обращений в службу поддержки.

Посмотрел alterator-auth, он правит nsswitch.conf в лоб, authselect вынужден делать примерно то же самое, например, с with-libnss-role (см. ниже) он дописывает слово role в строку group, это не чистая генерация из шаблона. %post разных пакетов, например, libnss-role, делают то же самое.

Я пока детально не продумывал, как на уровне всего дистрибутива внедрить authselect, сделав его единственным способом править конфиги PAM, но это не должно быть очень сложно.

> Ну, я вот, что имею в виду. Я эту штуку скачал, собрал и "потрогал" 10-15 минут:
> https://github.com/pbrezina/authselect
>
> Отмечу, что я с ходу заметил:
> - интересные шаблоны конфигов со встроенной двухфакторкой - будем
> брать на вооружение;
> - поддержка сканера отпечатков пальцев, тоже возьмем постепенно;
> - используют pam_oddjob_mkhomedir.so по умолчанию;
> - включают, через dconf, автоматически разблокировку экрана для
> режимов smartcard-authentication и fingerprint-authentication;
> - комплексно и согласованно настраивают nsswitch.conf (а вот это уже интересно);
> - предоставляют authselect, как инструмент, который переключает между
> профилями, позволяет их создавать, а также сохранять и
> восстанавливать.
вот это тоже важно - сохраняет предыдущие состояние перед внесением правок, позволяет просмотреть правки в тестовом режиме, не применяя их
> with-ecryptfs::
>     Enable automatic per-user ecryptfs.
> with-fingerprint::
>     Enable authentication with fingerprint reader through *pam_fprintd*.
> with-pam-u2f::
>     Enable authentication via u2f dongle through *pam_u2f*.
> with-pam-u2f-2fa::
>     Enable 2nd factor authentication via u2f dongle through *pam_u2f*.

А еще:

- with-winbind-cache, with-krb5-cache: https://github.com/pbrezina/authselect/pull/160

-with-libnss-role: https://github.com/pbrezina/authselect/pull/161

> [sin@base bin]$ LD_LIBRARY_PATH=../lib ./authselect
> Usage:
> ./authselect COMMAND COMMAND-ARGS
>
> Available commands:
> - select                 Select profile
> - apply-changes          Regenerate configuration for currently selected command
> - list                   List available profiles
> - list-features          List available profile features
> - show                   Show profile information
> - requirements           Print profile requirements
> - current                Get identifier of currently selected profile
> - check                  Check if the current configuration is valid
> - test                   Print changes that would be otherwise written
> - enable-feature         Enable feature in currently selected profile
> - disable-feature        Disable feature in currently selected profile
> - create-profile         Create new authselect profile
>
> Backup commands:
> - backup-list            List available backups
> - backup-remove          Remove backup
> - backup-restore         Restore from backup
>
> Common options:
>   --debug                Print error messages
>   --trace                Print trace messages
>   --warn                 Print warning messages
>
> Help options:
>   -?, --help             Show this for a command
>   --usage                Show brief usage message for a command