Эволюция учета и аутентификации пользователей в Red Hat Enterprise Linux 8 и Fedora (Александр Боковой, OSSDEVCONF-2019) — различия между версиями

Версия 12:21, 9 января 2020

Докладчик: Александр Боковой

В 2019 году мы празднуем 40 лет с момента появления в UNIX V7 вызовов семейства getpwnam(), getgrnam, getpwuid и getgrgid, предназначенных для получения информации о зарегистрированных в системе пользователях и группах. За четыре десятка лет многое изменилось, но мы по-прежнему используем эти интерфейсы во всех POSIX-совместимых системах.
В 2019 году компания Red Hat выпустила Red Hat Enterprise Linux 8. В докладе рассматриваются изменения в системах учета и аутентификации пользователей в RHEL 8 в контексте изменений ИТ отрасли за последние четверть века.

Видео

on youtube

Презентация

Thesis

Несмотря на существенные изменения на уровне протоколов, используемых для взаимодействия с различными системами учета пользователей, 40 лет мы используем API, семантика которого не претерпела существенных изменений. Вызовы семейства getpwnam(), getgrnam(), getpwuid() и getgrgid() можно считать одними из самых долгоживущих API в POSIX.

Чуть более четверти века назад (1993) появился интерфейс name service switch (NSS, nsswitch.conf), позволивший подключать различные модули, реализующие «наполнение» API
getpwnam(), getgrnam(), getpwuid() и getgrgid().

Наконец, созданный в 1995 и стандартизированный в 1997 как Single Sign-On Specification, интерфейс (PAM) довершает набор интерфейсов, абстрагирующих аутентификацию и авторизацию на уровне операционной системы. Фактически, эти интерфейсы без изменений используются всеми POSIX-совместимыми ОС и сегодня.

Более того, фактически все сетевые протоколы, используемые в системах учета и аутентификации пользователей, были созданы и активно развивались в XX веке. Они до сих пор актуальны, но это накладывает отпечаток на реализации протоколов: проекты со свободными лицензиями, их реализующие, испытывают определенный недостаток «новой крови» — по многим причинам. За десятилетия написано множество компонент для PAM и модулей NSS, но некоторые из них уже фактически не поддерживаются: они либо заброшены своими авторами, либо потеряли актуальность из-за смены моделей использования тех или иных протоколов (NIS, Hesiod и другие), либо их внутренняя реализация не отвечает современным взглядам на проектирование системных компонент для встраивания в другие приложения (разделение привилегий, изоляция и т.д.).

С точки зрения разработчиков дистрибутивов операционных систем такие компоненты представляют проблему: отсутствие активного проекта означает сложную ситуацию с поддержкой в случае проблем безопасности. Вдобавок, не только адаптация к условиям эксплуатации в дистрибутиве, но и общее развитие проекта падает на плечи разработчиков дистрибутива. Даже если компонента используется во всех дистрибутивах GNU/Linux, зачастую совместной работы не получается — знания о реализации протокола этой компоненты не обязательно присутствуют у всех мейнтейнеров.

В 2007 году Red Hat инициировал проект System Security Services Daemon (SSSD), обеспечивающий единообразный доступ к сервисам учета, аутентификации и авторизации как локально, так и удаленно. За последнюю декаду было сделано многое для интеграции с существующими системами управления и учета пользователей (Active Directory, FreeIPA и другими). В SSSD был реализован функционал основных модулей работы с LDAP источниками, с Kerberos, добавлена поддержка авторизации с использованием смарт-карт и разнообразных токенов. В рамках интеграции с FreeIPA была разработана поддержка многофакторной аутентификации. Для FreeIPA и Active Directory добавлены средства авторизации, учитывающие специфические правила описания доступа (host-based access control в FreeIPA и Group Policies в AD). Всё это привело к дублированию функционала в рамках дистрибутива для целого ряда модулей. К тому же, во многих случаях эти модули не предполагали централизованное управление своими ресурсами и затрудняли поддержание единообразного представления систем доступа при эксплуатации внедрений с большим количеством одинаковых серверов.

В рамках Red Hat Enterprise Linux 8 была предпринята попытка «чистки» дистрибутива от устаревших компонент. Помимо самих компонент, модернизации подверглась и утилита настройки, использовавшаяся для поддержания конфигураций. За годы эксплуатации стало понятно, что на самом деле пользователи в основном реализуют ограниченый набор сценариев конфигурации и можно существенно упростить настройку и поддержку, если эти сценарии зафиксировать в готовых конфигурациях вместо модификации состояния конфигурационных файлов в любой момент времени. Последнее также позволяет упростить настройку систем в контейнерном исполнении, поскольку уменьшает размер дополнительных модификаций при создании контейнерного образа.

Как результат, модули nss-pam-ldapd, pam_krb5, pam_pkcs11 были убраны из Red Hat Enterprise Linux 8. Утилита конфигурирования authconfig была заменена на authselect, а управление первоначальной настройкой для доменных сред унифицировано утилитой realm. Таким образом, Red Hat Enterprise Linux 8 поддерживает два основных варианта доступа к доменным средам: с использованием SSSD и с использованием winbindd из набора средств Samba. Для локального управления по умолчанию также используется демон SSSD, научившийся хранить информацию о локальных пользователях и группах.

Вместе с тем, сценарии использования операционных систем и предоставляемых ими сервисов расширились. Для многих задач доступ к данным о пользователях означает и доступ к свойствам, которые никогда не предоставлялись в рамках POSIX API. Например, многим приложениям требуется информация о почтовом адресе пользователя — они используют его для задач идентификации пользователя в рамках своих баз данных или для других целей. Другим приложениям необходимо уметь отображать сертификат, с помощью которого аутентифицировался пользователь, на самого пользователя. Для предоставления таких расширенных деталей о пользователях в SSSD был добавлен специальный механизм InfoPipe, прозрачно интегрирующий доступ к этой информации из всех поддерживаемых и настроенных источников, включая сложные комбинации вроде доверяемых отношений между FreeIPA и лесами Active Directory.

С целью изоляции ресурсов аутентификации еще в рамках Red Hat Enterprise Linux 7 был добавлен механизм прозрачного проксирования доступа к аутентификационным токенам в GSS-API. Этот механизм активно используется во FreeIPA и других проектах, а также для изоляции доступа к токенам аутентификации в веб-приложениях на основе Apache. В Red Hat Enterprise Linux 8 старые модули Apache (например, mod_auth_kerb) были убраны, их заменяет mod_auth_gssapi.

Аналогичная работа была проведена и с криптографическими библиотеками. Проект миграции всего свободного ПО на библиотеку NSS от Mozilla Foundation не удался, поэтому в Red Hat Enterprise Linux 8 большая часть приложения переведена на использование OpenSSL. NSS используется только в Firefox и системе организации удостоверяющего центра Dogtag, а также внутри программного токена SoftHSMv2. Остальные приложения были переписаны на OpenSSL и GnuTLS. Помимо решения проблем с унификацией, это позволит упростить сертификацию таких систем по государственным стандартам (FIPS 140-2 и подобным).

Одним из значимых изменений в Red Hat Enterprise Linux 8 стало устранение сервера LDAP от проекта OpenLDAP. Компания Red Hat изучила статистику обращений заказчиков в службу поддержки и выяснила, что существующее предложение не обеспечивает достаточный уровень поддержки в то время, как партнеры Red Hat, занимающиеся развитием OpenLDAP, могут предоставить более качественные услуги по его поддержке. В результате, было принято решение сфокусироваться на сервере LDAP из проекта 389-ds, который лежит в основе двух активно поддерживаемых продуктов линейки Red Hat: RHEL IdM и RHDS. Аналогичное решение приняла и компания SUSE, заменившая OpenLDAP сервер в своих дистрибутивах на 389-ds и активно работающая над развитием 389-ds. При этом библиотеки OpenLDAP остались доступны и также активно развиваются.

Примечания и ссылки

Plays:59 Comments:0