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

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

[Evgeny Sinelnikov]

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

Хочу напомнить об актуальной до сих пор теме не локальных вариантов
настроек PAM. С момента последнего обсуждения появились дополнительные
вопросы, задачи и проблемы. А, между тем, с тех пор ничего не
изменилось:
https://lists.altlinux.org/pipermail/devel/2017-April/202654.html

Отмечу, что условие uid >= 500 для любых глобальных пользователей. И
настройку этой политики с помощью control я пока оставил - это
отдельная не столь актуальная проблема (осталась текущая схема).

Текущие изменения, которые я хочу предложить протестировать и
внедрить, включают в себя следующие проблемы и решения:
- "путаница при наличии совпадающих логинов". По умолчанию вводится
строгий контроль на уровне стека PAM-модулей с помощью модуля
pam_localuser для методов krb5, krb5_ccreds и winbind (для sss это уже
внедрено);
- Для сохранения возможностей логики с использованием "путаницы", как
фичи (а такие варианты использования существуют) вводится метод
krb5_local;
- Для управления политиками настройки сессии вводится новый control -
system-policy.

Тестовая сборка готова и сейчас находится на стадии отладки (основные
тесты успешно завершены, требуются добровольцы для участия в
расширенной проверке):
#240988 EPERM #7 [test-only] sisyphus pam-config.git=1.8.0-alt1


PS: На текущем этапе всё зависит от мейнтенера pam-config:
$ ssh girar acl sisyphus pam-config show
pam-config      ldv

PPS: Я не стал трогать три метода pkcs11 (выглядит прилично для своих
задач), ldap и multi (pam-модули на базе ldap не понимаю как
отлаживать - предпочитаю не трогать, как наследие).

________________________________________

О последнем подробнее:

sin@xpi pam-config $ ls -1 /etc/pam.d/system-*
/etc/pam.d/system-auth -> system-auth-krb5_local
/etc/pam.d/system-auth-krb5
/etc/pam.d/system-auth-krb5_ccreds
/etc/pam.d/system-auth-krb5_local
/etc/pam.d/system-auth-ldap
/etc/pam.d/system-auth-local
/etc/pam.d/system-auth-multi
/etc/pam.d/system-auth-pkcs11
/etc/pam.d/system-auth-sss
/etc/pam.d/system-auth-use_first_pass -> system-auth-use_first_pass-krb5_local
/etc/pam.d/system-auth-use_first_pass-krb5
/etc/pam.d/system-auth-use_first_pass-krb5_ccreds
/etc/pam.d/system-auth-use_first_pass-krb5_local
/etc/pam.d/system-auth-use_first_pass-ldap
/etc/pam.d/system-auth-use_first_pass-local
/etc/pam.d/system-auth-use_first_pass-multi
/etc/pam.d/system-auth-use_first_pass-pkcs11
/etc/pam.d/system-auth-use_first_pass-sss
/etc/pam.d/system-auth-use_first_pass-winbind
/etc/pam.d/system-auth-winbind
/etc/pam.d/system-policy -> system-policy-global
/etc/pam.d/system-policy-global
/etc/pam.d/system-policy-local

Настройка 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

Ещё одна особенность - при переключении system-auth с local на любую
другую - system-policy автоматически переключается на global и
обратно:
~ # control system-auth local
~ # control system-policy
local
~ # control system-auth sss
~ # control system-policy
global

Это делает поведение по умолчанию аналогичным тому, которое было
раньше. При этом, если system-policy задано, то system-auth возвращает
system-policy в исходное только при переключении на local, но не
наоборот:
~ # control system-auth
sss
~ # control system-policy
global
~ # control system-auth local
~ # control system-policy
local

~ # control system-policy test
~ # control system-policy
test
~ # control system-auth krb5
~ # control system-policy
test
~ # control system-auth sss
~ # control system-policy
test
~ # control system-auth local
~ # control system-policy
local

Для конфигураций, где вместо pam_mkhomedir.so нужно использовать
pam_oddjob_mkhomedir (а это SELinux конфигурации, в первую очередь), а
также для применения так называемых групповых политик, модули
system-policy планируется устанавливать дополнительно (аналогично
тому, как это делается для system-auth):
~ # rpm -qf /etc/pam.d/system-auth-local
pam-config-1.8.0-alt1.noarch
~ # rpm -qf /etc/pam.d/system-auth-sss
sssd-client-2.2.2-alt2.x86_64


-- 
Sin (Sinelnikov Evgeny)

[devel] Offtopic: Re: "Нелокальный"

[Evgeny Sinelnikov]

чт, 21 нояб. 2019 г. в 02:45, Evgeny Sinelnikov <sin@altlinux.org>:
>
> Хочу напомнить об актуальной до сих пор теме не локальных вариантов
> настроек PAM.
...

PS: Да, я уже понял, что забыл исправить - "нелокальный" пишется всместе.
PPS: Стыдно, а но что делать...

-- 
Sin (Sinelnikov Evgeny)

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

[Evgeny Sinelnikov]

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

В новую сборку pam-config добавлены файл-триггеры, не позволяющие
после удаления пакетов, расширяющих систему аутентификации и системные
политики, оставить систему в неопределённом состоянии:
#241839 EPERM #2 [test-only] sisyphus pam-config.git=1.8.0-alt2

предыдущая сборка попрежнему ждёт одобрения:
#240988 EPERM #8 sisyphus pam-config.git=1.8.0-alt1

вс, 24 нояб. 2019 г. в 04:52, Evgeny Sinelnikov <sin@altlinux.org>:
>
> Доброй ночи.
>
> Сборка проверена в различных конфигурациях и отправлена на одобрение:
> #240988 EPERM #8 sisyphus pam-config.git=1.8.0-alt1
>
> чт, 21 нояб. 2019 г. в 02:45, Evgeny Sinelnikov <sin@altlinux.org>:
>>
>> Здравствуйте,
>>
>> Хочу напомнить об актуальной до сих пор теме нелокальных вариантов
>> настроек PAM. С момента последнего обсуждения появились дополнительные
>> вопросы, задачи и проблемы. А, между тем, с тех пор ничего не
>> изменилось:
>> https://lists.altlinux.org/pipermail/devel/2017-April/202654.html
>>
>> Отмечу, что условие uid >= 500 для любых глобальных пользователей. И
>> настройку этой политики с помощью control я пока оставил - это
>> отдельная не столь актуальная проблема (осталась текущая схема).
>>
>> Текущие изменения, которые я хочу предложить протестировать и
>> внедрить, включают в себя следующие проблемы и решения:
>> - "путаница при наличии совпадающих логинов". По умолчанию вводится
>> строгий контроль на уровне стека PAM-модулей с помощью модуля
>> pam_localuser для методов krb5, krb5_ccreds и winbind (для sss это уже
>> внедрено);
>> - Для сохранения возможностей логики с использованием "путаницы", как
>> фичи (а такие варианты использования существуют) вводится метод
>> krb5_local;
>> - Для управления политиками настройки сессии вводится новый control -
>> system-policy.
>>
>> Тестовая сборка готова и сейчас находится на стадии отладки (основные
>> тесты успешно завершены, требуются добровольцы для участия в
>> расширенной проверке):
>> #240988 EPERM #7 [test-only] sisyphus pam-config.git=1.8.0-alt1
>>
>>
>> PS: На текущем этапе всё зависит от мейнтенера pam-config:
>> $ ssh girar acl sisyphus pam-config show
>> pam-config      ldv
>>
>> PPS: Я не стал трогать три метода pkcs11 (выглядит прилично для своих
>> задач), ldap и multi (pam-модули на базе ldap не понимаю как
>> отлаживать - предпочитаю не трогать, как наследие).
>>
>> ________________________________________
>>
>> О последнем подробнее:
>>
>> sin@xpi pam-config $ ls -1 /etc/pam.d/system-*
>> /etc/pam.d/system-auth -> system-auth-krb5_local
>> /etc/pam.d/system-auth-krb5
>> /etc/pam.d/system-auth-krb5_ccreds
>> /etc/pam.d/system-auth-krb5_local
>> /etc/pam.d/system-auth-ldap
>> /etc/pam.d/system-auth-local
>> /etc/pam.d/system-auth-multi
>> /etc/pam.d/system-auth-pkcs11
>> /etc/pam.d/system-auth-sss
>> /etc/pam.d/system-auth-use_first_pass -> system-auth-use_first_pass-krb5_local
>> /etc/pam.d/system-auth-use_first_pass-krb5
>> /etc/pam.d/system-auth-use_first_pass-krb5_ccreds
>> /etc/pam.d/system-auth-use_first_pass-krb5_local
>> /etc/pam.d/system-auth-use_first_pass-ldap
>> /etc/pam.d/system-auth-use_first_pass-local
>> /etc/pam.d/system-auth-use_first_pass-multi
>> /etc/pam.d/system-auth-use_first_pass-pkcs11
>> /etc/pam.d/system-auth-use_first_pass-sss
>> /etc/pam.d/system-auth-use_first_pass-winbind
>> /etc/pam.d/system-auth-winbind
>> /etc/pam.d/system-policy -> system-policy-global
>> /etc/pam.d/system-policy-global
>> /etc/pam.d/system-policy-local
>>
>> Настройка 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
>>
>> Ещё одна особенность - при переключении system-auth с local на любую
>> другую - system-policy автоматически переключается на global и
>> обратно:
>> ~ # control system-auth local
>> ~ # control system-policy
>> local
>> ~ # control system-auth sss
>> ~ # control system-policy
>> global
>>
>> Это делает поведение по умолчанию аналогичным тому, которое было
>> раньше. При этом, если system-policy задано, то system-auth возвращает
>> system-policy в исходное только при переключении на local, но не
>> наоборот:
>> ~ # control system-auth
>> sss
>> ~ # control system-policy
>> global
>> ~ # control system-auth local
>> ~ # control system-policy
>> local
>>
>> ~ # control system-policy test
>> ~ # control system-policy
>> test
>> ~ # control system-auth krb5
>> ~ # control system-policy
>> test
>> ~ # control system-auth sss
>> ~ # control system-policy
>> test
>> ~ # control system-auth local
>> ~ # control system-policy
>> local
>>
>> Для конфигураций, где вместо pam_mkhomedir.so нужно использовать
>> pam_oddjob_mkhomedir (а это SELinux конфигурации, в первую очередь), а
>> также для применения так называемых групповых политик, модули
>> system-policy планируется устанавливать дополнительно (аналогично
>> тому, как это делается для system-auth):
>> ~ # rpm -qf /etc/pam.d/system-auth-local
>> pam-config-1.8.0-alt1.noarch
>> ~ # rpm -qf /etc/pam.d/system-auth-sss
>> sssd-client-2.2.2-alt2.x86_64
>>
>>
>> --
>> Sin (Sinelnikov Evgeny)
>
>
>
> --
> Sin (Sinelnikov Evgeny)



-- 
Sin (Sinelnikov Evgeny)

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

[Mikhail Novosyolov]

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), весьма 
разумно.

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

[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 - снова...

В штуках сейчас этих попугаев, как раз, тридцать восемь у меня:
$ 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

Это модуль, позволяющий запускать из-под пользователя инструмент по
обновлению групповых политик с правами администратора. Служба oddjob
используется в данном случае для двух задач:
- для запуска процесса обновления групповых политик во время логина;
- для ручного запуска обновления групповых политик пользователем.

Сам gpupdate разрабатывается отдельно и готовится вместе в
oddjob-gpupdate уехать в сизиф.

Собственно, ради гибкого управления настройками этих модулей нам и
понадобился новый, гибкий control-метод system-policy, тесно увязанный
с уже существующим control-методом system-auth.



-- 
Sin (Sinelnikov Evgeny)

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

[Alexey V. Vissarionov]

 >> Использовать dbus для создания домашней директории из-под pam
 >> кажется совсем перебором, но то, что это решает проблемы с
 >> контекстами selinux
 >> (https://access.redhat.com/discussions/903523#comment-766163),
 >> весьма разумно.
 > Нет, я не думаю, что это сильно перебор. Сейчас dbus везде. Ну,
 > просто везде.

Вот квантором \forall размахивать точно не надо: dbus даже для
десктопа опционален (например, я живу без него), а на каком-нибудь
промышленном сервере ему уж точно не место.

 > NetworkManager - это dbus, udisks2 - тоже, polkit - снова...

Все перечисленное - это десктоп. Если сабж тоже планируется
использовать в десктопных установках (точнее, в офисной среде,
но только там) - все в порядке, если нет - лучше не надо.

 > В штуках сейчас этих попугаев, как раз, тридцать восемь у меня:
 > $ LC_ALL=C apt-cache whatdepends libdbus |
 > grep "Depends: <libdbus-1.so.3()(64bit)>" | wc -l
 > 38

Не поленился, посмотрел весь список. Увидел, что было бы хорошо
убрать зависимость от dbus нескольким пакетам - тогда для нас
откроются как минимум два новых вкусных направления.


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

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

[Mikhail Novosyolov]

Добрый вечер!

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?

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

[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 я пока не разбирал.



-- 
Sin (Sinelnikov Evgeny)

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

[Mikhail Novosyolov]

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.

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

[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?


-- 
Sin (Sinelnikov Evgeny)

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

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

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

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

Возможно, при этом, отсутствуют и полезные задачи, которые у нас не
решаются. И вот мой-то вопрос, как раз, об этом. А какие задачи решает
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)

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

[Mikhail Novosyolov]

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