Speaker Rabbit

abbra


CIFS: curious information funneled sometimes


Previous Entry Share Next Entry
HBAC в SSSD/FreeIPA
Speaker Rabbit
abbra
Немного о том, чем я сейчас занят. Записи с тегом "заметки-на-полях" -- моя внутренняя кухня, не предназначенная для активного обсуждения и цитирования вне этого ЖЖ. Мой мозг пока с трудом привыкает к большому объему нового (и вспоминанию старого) кода, поэтому заметки скорее для себя, чем разъяснения для других. Если объем превысит выделяемое самим собой время, я просто отключу комментарии, чтобы не отвлекаться, не обессудьте.


SSSD -- это замена pam_ldap/nss_ldap/pam_winbind/nss_winbind и nscd для централизованной раздачи не только учетных записей, но и прав доступа к службам, включая возможность работы в оффлайне. SSSD позволяет упростить настройку клиентских машин и делегировать полномочия централизованно. FreeIPA, с другой стороны -- это серверная часть, веб-интерфейс и клиент командной строка для управления этими настройками и полномочиями. Данные хранятся в LDAP (389 Directory), а установка FreeIPA позволяет довольно легко настроить типовые конфигурации LDAP, Kerberos, Certificate Authority, NTP, DNS и всего остального необходимого. Да, это попытка сделать аналог AD, но для GNU/Linux (круг замкнулся), но без особенно необходимости соблюдать совместимость с AD (для этого будет Samba4). SSSD не обязателен на клиентской стороне для развертывания FreeIPA, но серьезно облегчает дальнейшее сопровождение GNU/Linux-машин.

Развертывание FreeIPA на Fedora 15 сейчас упростилось до невозможности: https://docs.fedoraproject.org/en-US/Fedora/15/html/FreeIPA_Guide/Installing_the_IPA_Server_Packages.html (yum install freeipa-server bind bind-dyndb-ldap и запустить ipa-server-install). На клиентской стороне, соответственно, надо установить freeipa-client (плюс sssd опционально) и запустить ipa-client-install. Правда, с последними обновлениями в Fedora 15 кое-что перестало работать из-за исправлений в libcurl, которые отключают автоматическое прокидывание билетов Kerberos, но над исправлением работают (к сожалению, автоматическое _безусловное_ прокидывание билетов Kerberos не всегда полезно). RHEL уже включает в себя FreeIPA как Technology Preview, а вся работа все равно идет в Rawhide/Fedora. Upstream, над которым я и работаю -- http://freeipa.org

Теперь о HBAC. SSSD поддерживает вычисление правил доступа для различных служб в зависимости от того, кто, откуда и куда обращается к конкретной службе. Сейчас речь идет о службах PAM, в дальнейшем возможно расширение и на другие сущности. Раздел в документации, посвященный host-based access control -- https://docs.fedoraproject.org/en-US/Fedora/15/html-single/FreeIPA_Guide/index.html#authz. Фактически, HBAC определяет наборы правил, связывающих службы или группы служб, запущенных на определенных узлах с пользователями или группами пользователей, обращающихся к ним с других узлов: (services, users, source hosts, target hosts), где каждый элемент правила может быть тройкой (category, names, groups). Категорий на сейчас лишь две -- прямое совпадение (HBAC_CATEGORY_NULL) и маска "подходит всё" (HBAC_CATEGORY_ALL), а имена и группы -- списки. При указании категории HBAC_CATEGORY_ALL ситуация простая -- правило всегда срабатывает без дальнейшей проверки имен и групп. Как имена, так и группы могут присутствовать одновременно, в этом случае при вычислении правила вначале будет рассматриваться соответствие имен, а затем групп.

При вычислении всего правила (у нас четыре элемента правила) последовательно вычисляются подправила для пользователя, службы, целевого и исходного хостов. Если хотя бы одно из подправил не срабатывает, все правило отвергается. Соответственно, правило (HBAC_CATEGORY_NULL, HBAC_CATEGORY_NULL, HBAC_CATEGORY_NULL, HBAC_CATEGORY_NULL) описывает простейшее "разрешено всё и всем".

SSSD в git master содержит заглушку для будущей поддержки правил, действие которых ограничено по времени. Предстоит еще разобраться, как формулировать эти ограничения в условиях централизованного управления системами, находящимися в различных часовых поясах и как сформулировать грамотно пользовательский интерфейс для этой задачи.

В FreeIPA есть несколько команд для работы с правилами HBAC:

Создаем правило "test1", позволяющее всем пользователям обращаться к хосту server откуда угодно:
   ipa hbacrule-add --type=allow --usercat=all --srchostcat=all test1
   ipa hbacrule-add-host --hosts=server.example.com test1

Смотрим свойства правила test1:
   ipa hbacrule-show test1

Создаем правило для конкретной службы. Допустим, пользователь john получает право обращаться к sshd на любой машине откуда угодно:
   ipa hbacrule-add --type=allow --hostcat=all --srchostcat=all john_sshd
   ipa hbacrule-add-user --users=john john_sshd
   ipa hbacrule-add-service --hbacsvcs=sshd john_sshd

В FreeIPA 2.1 будет убрана типизация правил (сейчас поддерживаются allow и deny), все правила будут разрешать запрещенный по умолчанию доступ. С правилами запрета (deny) все плохо -- они на практике только усложняют администрирование. Так что FreeIPA будет реализовывать концепцию доброго администратора (все по умолчанию запрещено, администратор правилами разрешает доступ).

Создаем правило для новой группы служб, позволяющее john обращаться ко всем FTP-серверам откуда угодно:
   ipa hbacsvcgroup-add ftpers
   ipa hbacsvc-add sftp
   ipa hbacsvcgroup-add-member --hbacsvcs=ftp,sftp ftpers
   ipa hbacrule-add --type=allow --hostcat=all --srchostcat=all john_ftp
   ipa hbacrule-add-user --users=john john_ftp
   ipa hbacrule-add-service --hbacsvcgroups=ftpers john_ftp

Отключаем правило test1:
   ipa hbacrule-disable test1

Удаляем правило:
   ipa hbacrule-del allow_server

Чтобы проверить поведение правил, сейчас приходится использовать боевую конфигурацию и пытаться имперсонифицировать пользователя, к которому это правило относится. Это не совсем удобно. Для тестирования требуется отдельный механизм, который бы использовал тот же код для анализа и вычисления правил, который использует SSSD, но подставлял бы в него имитируемые данные. То есть, фактически, мы хотим добавить команду
   ipa hbacrule-test имя_правила параметры

Имя правила должно быть опциональным, в этом случае мы имитируем поведение SSSD, который запрашивает все правила, относящиеся к хосту, на котором он запущен, и ко всем хостам. В параметры должны входить указанные четыре параметра -- служба, пользователь/группа, входной хост, целевой хост. Получив конкретное правило или список правил, команда должна применить все входные параметры ко всем правилам и выдать результат: правило сработало или нет. В режиме отладки должна быть возможность увидеть для списка правил, какое из них не сработало.

Теперь в sssd git master добавили экспорт обработчика правил HBAC в виде отдельной библиотеки и ее привязку к Питону (FreeIPA написан на Питоне). Так что можно использовать этот код и в FreeIPA, чем я и занимаюсь.

  • 1
В FreeIPA 2.1 будет убрана типизация правил (сейчас поддерживаются allow и deny), все правила будут разрешать запрещенный по умолчанию доступ. С правилами запрета (deny) все плохо -- они на практике только усложняют администрирование.

то есть веместо
deny guest
allow all
надо будет писать allow для всех 100500 пользователей? интересная идея.

Зачем? Не включай guest в группу, а всех остальных включи и для этой группы сделай правило. Они у тебя все равно будут в группы засунуты.

Если интересен контекст, почитай https://www.redhat.com/archives/freeipa-devel/2011-June/msg00463.html

  • 1
?

Log in

No account? Create an account