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

;{{SpeakerInfo}}: {{Speaker|Александр Боковой}}
<blockquote>
В 2019 году мы празднуем 40 лет с момента появления в UNIX V7 вызовов
семейства <tt>getpwnam()</tt>, <tt>getgrnam</tt>, <tt>getpwuid</tt> и <tt>getgrgid</tt>,
предназначенных для получения информации о зарегистрированных в системе
пользователях и группах. За четыре десятка лет многое изменилось, но мы
по-прежнему используем эти интерфейсы во всех POSIX-совместимых
системах.

В 2019 году компания Red Hat выпустила Red Hat Enterprise Linux 8. В
докладе рассматриваются изменения в системах учета и аутентификации
пользователей в RHEL 8 в контексте изменений ИТ отрасли за последние
четверть века.
</blockquote>

{{VideoSection}}
{{vimeoembed|366003347|800|450}}

{{youtubelink|hQMl_Y-vEZg}}


{{SlidesSection}}
[[File:Эволюция учета и аутентификации пользователей в Red Hat Enterprise Linux 8 и Fedora (Александр Боковой, OSSDEVCONF-2019).pdf|left|page=-|300px]]

{{----}}

== Thesis ==

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

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

Наконец, созданный в 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 была предпринята попытка «чистки» дистрибутива от устаревших компонент. Помимо самих компонент, модернизации подверглась и утилита настройки, использовавшаяся для поддержания конфигураций. За годы эксплуатации стало понятно, что на самом деле пользователи в основном реализуют ограниченый набор сценариев конфигурации и можно существенно упростить настройку и поддержку, если эти сценарии зафиксировать в готовых конфигурациях вместо модификации состояния конфигурационных файлов в любой момент времени. Последнее также позволяет упростить настройку систем в контейнерном исполнении, поскольку уменьшает размер дополнительных модификаций при создании контейнерного образа.

Как результат, модули <code>nss-pam-ldapd</code>, <code>pam_krb5</code>, <code>pam_pkcs11</code> были убраны из Red Hat Enterprise Linux 8. Утилита конфигурирования <code>authconfig</code> была заменена на <code>authselect</code>, а управление первоначальной настройкой для доменных сред унифицировано утилитой <code>realm</code>. Таким образом, 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 (например, <code>mod_auth_kerb</code>) были убраны, их заменяет <code>mod_auth_gssapi</code>.

Аналогичная работа была проведена и с криптографическими библиотеками. Проект миграции всего свободного ПО на библиотеку 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 остались доступны и также активно развиваются.


{{----}}
[[File:{{#setmainimage:Эволюция учета и аутентификации пользователей в Red Hat Enterprise Linux 8 и Fedora (Александр Боковой, OSSDEVCONF-2019)!.jpg}}|center|640px]]
{{LinksSection}}
<!-- <blockquote>[©]</blockquote> -->


{{fblink|2527083000878039}}                                          
{{vklink|1443}}                                          
<references/>

[[Категория:OSSDEVCONF-2019]]
[[Категория:Samba]]
[[Категория:FreeIPA]]
[[Категория:Аутентификация и авторизация]]
{{stats|disqus_comments=0|refresh_time=2021-08-31T18:42:53.160186|vimeo_plays=30|youtube_comments=0|youtube_plays=122}}