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

[Mikhail Novosyolov]

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, мне кажется, требуется больше 
централизации, потому что для добавления функции придется править чей-то 
чужой шаблон, а в случае скриптов можно скриптом поправить конфиги.

Оба подхода имеют право на жизнь)