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

[Evgeny Sinelnikov <sin@altlinux.org>]

Доброй ночи.

вт, 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, у нас практически отсутствуют.

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

Ну, я вот, что имею в виду. Я эту штуку скачал, собрал и "потрогал" 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*.

[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



-- 
Sin (Sinelnikov Evgeny)