2rider: Антон, есть проблемы с исправлением?

Я этим не занимаюсь.

В багу приглашается sin@ с вопросом: а что,собственно, надо sssd от selinux в данном случае. Ему это действительно надо (тогда надо менять полиси) или его надо самого патчить, чтобы он "это" не запрашивал?

Это надо посмотреть. И ещё нужно учесть, что sssd умеет сам selinux (и тут надо уточнить, что он умеет). В поддержкой selinux sssd что-то, действительно, хочет от selinux.

Жень, исходи пожалуйста из того, что политику менять сейчас гемморойно.
Но, наверное можно, особенно если кто-то сможет подробно описать что именно в ней менять (а ещё лучше сделает патчи).

Вот этот модуль пытается работать. В других ОС он имеет специальный контекст, который разрешает ему работать с selinux users.
http://git.altlinux.org/gears/s/sssd.git?p=sssd.git;a=blob;f=src/providers/ipa/selinux_child.c;h=f8dd3954a7244df2dcbb910aabf8888f41306c09;hb=b47fd11a259c50e63cd674c7cba0da3f2549cae0

В федоре:
# ls -Z /usr/libexec/sssd/selinux_child
system_u:object_r:sssd_selinux_manager_exec_t:s0 /usr/libexec/sssd/selinux_child

Мне кажется проще всего разрешить sssd делать то, что ему нужно. Т.е. добавить тип аналогичный sssd_selinux_manager_exec_t в selinux-policy-alt и установить его для selinux_child. Насколько это сложно сделать не знаю, я никогда не смотрел внутрь selinux-policy-alt.

В ALT policy НЕТ targeted политики, таким образом маппинг пользователей на selinux пользователей не имеет смысла. Freeipa работает на одном уровне MLS и поэтому 
1) всех пользователей надо маппить при создании на пользователя generic_u 
2) ставить freeipa_server с выключенным selinux и подключать клиента - тоже
3) после установки в /etc/sssd/sssd.conf в cекции domain/<имя домена>
добавить selinux_provider=none
Есть работающий стенд.

Денис, спасибо.

Какие-то костыли, давайте эту ошибку переоткроем и решим со временем как сделать правильно, что бы всё работало из коробки.

(В ответ на комментарий №9)
> Денис, спасибо.
> 
> Какие-то костыли, давайте эту ошибку переоткроем и решим со временем как
> сделать правильно, что бы всё работало из коробки.

Я бы советовал открыть другую багу с корректной формулировкой.

в общем дальнейшее обсуждение ушло в кулуары, результатом должна стать поддержка мандатной модели selinux в sssd/freeipa. Ошибку пока прошу не закрывать.

Результат проверки актуальности

Состояние: проблема по сути жива — в текущей политике (0.1.0-alt18, p11/c11f1) по-прежнему нет типа для sssd/selinux_child и targeted-варианта, штатный обход всё тот же selinux_provider=none. Но пакет удалён из Sisyphus — компонент в этом продукте больше не существует.

Рекомендация: перенести баг на Branch p11 и ретестировать там; в Sisyphus оставлять бессмысленно.

Ретест в p11 (тестовые ВМ x86_64, ALT Server 11.1):
- сервер FreeIPA: freeipa-server-4.12.5-alt5, домен t33840.test, SELinux на сервере не включался;
- клиент: freeipa-client-4.12.5-alt5, sssd-2.9.8-alt3 (sssd-ipa), selinux-policy-alt-0.1.0-alt18, policycoreutils-3.8-alt1; ядро с selinux=1 security=selinux, `sestatus`: policy alt, MLS enabled, Current mode: enforcing.
selinux_provider в sssd.conf не задан (по умолчанию ipa), обход selinux_provider=none не применялся. Default SELinux user в IPA: generic_u:s0-s3:c0.c15.

Шаги: ввод клиента в домен (ipa-client-install), затем в режиме enforcing вход доменных пользователей test01 и test02 по ssh с паролем.

Результат:
- вход успешен, контекст сеанса generic_u:generic_r:generic_t:s0-s3:c0.c15;
- selinux_child записывает сопоставления: `semanage login -l` показывает test01 и test02 → generic_u s0-s3:c0.c15, /etc/selinux/alt/seusers обновлён в момент входа;
- AVC-отказов для selinux_child нет.

Причина: в текущей политике /usr/sbin/sssd помечен officer_exec_t, процессы sssd (и запускаемый ими selinux_child) работают в домене officer_t, которому запись в хранилище SELinux разрешена (`ps -eZ`: generic_u:generic_r:officer_t:s0 sssd, sssd_be, sssd_pam…).

Итог: в p11 с selinux-policy-alt-0.1.0-alt18 не воспроизводится — вход доменного пользователя при включённом SELinux работает без selinux_provider=none.

Замечание по настройке: в enforcing root (generic_u:generic_r:generic_t:s0) не может писать в /etc, rpm-базу и выполнять setenforce (integrity_protected_t), поэтому ipa-client-install в enforcing завершается ошибкой «No write permissions on keytab file '/etc/krb5.keytab'»; ввод в домен выполнялся после загрузки с enforcing=0, сама проверка входа — в enforcing.