На машине введенной в домен FreeIPA невозможно зайти доменным пользователем при включенном SELinux, потому что сервис sssd пытается получить доступ к файлам в директории /etc/selinux/alt/contexts/files, а политика ему это не позволяет: type=ROLE_ASSIGN msg=audit(1504276892.251:84): pid=1638 uid=0 auid=4294967295 ses=4294967295 subj=generic_u:generic_r:generic_t:s0 msg='op=login-sename,role,range acct="test01" old-seuser=? old-role=? old-range=? new-seuser=generic_u new-role=object_r,generic_r new-range=s0-s3:c0.c15 exe="/usr/libexec/sssd/selinux_child" hostname=? addr=? terminal=? res=success' type=AVC msg=audit(1504276892.304:85): avc: denied { write } for pid=1638 comm="selinux_child" name="files" dev="vda2" ino=440139 scontext=generic_u:generic_r:generic_t:s0 tcontext=generic_u:object_r:selinux_protected_t:s0 tclass=dir permissive=0 find /etc/ -inum 440139 /etc/selinux/alt/contexts/files При отключении SELinux заходит нормально и правила сопоставления SELinux-пользователей FreeIPA работают.
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.
