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

[Evgeny Sinelnikov <sin@altlinux.org>]

пт, 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?


-- 
Sin (Sinelnikov Evgeny)