Разграничение прав доступа к Linux-системе и её сервисам через доменные группы безопасности с помощью SSSD и PAM

Когда мы рассматривали настройку SSSD на Debian 8 (Jessie), немного упоминали о возможности ограничения доступа к Linux-системе через группы безопасности в домене Active Directory. Однако рассматриваемый в том случае пример предполагает безусловное глобальное ограничение доступа на уровне всей Linux-системы. То есть, указанная в секции описания домена конфигурационного файла sssd.conf опция simple_allow_groups ограничивает доступ не только для входа в систему, но и для всех других служб внутри этой системы, которые будут использовать возможности SSSD. Таким образом, рассмотренный ранее пример настройки авторизации с помощью SSSD в Apache точно также, как и другие сервисы, использующие SSSD, будет ограничен глобальной опцией simple_allow_groups. Но как же быть, если доступ к Linux-системе и её отдельным сервисам требует гранулированной настройки? Например, требуется, чтобы право локального и/или удалённого входа в систему имели члены одной доменной группы безопасности, а право доступа к какому-то сайту веб-сервера Apache (или даже отдельному веб-каталогу) имели члены другой группы безопасности домена Active Directory. Попробуем решить эту задачу с помощью настройки механизма подключаемых модулей аутентификации - Pluggable Authentication Modules (PAM), а конкретнее с помощью использования возможностей библиотеки pam_listfile.so.

Отключаем ограничения SSSD

Для начала нам потребуется отключить ограничения по доменным группам безопасности, явно заданные в конфигурации SSSD, если такие ограничения были задействованы ранее. Например, если в конфигурационном файле /etc/sssd/sssd.conf в секции, описывающей домен Active Directory по ранее рассмотренному примеру было задано ограничение для конкретной доменной группы безопасности…

...
[domain/ad.holding.com]
...
access_provider = simple
simple_allow_groups = KOM-SRV-Linux-Admins@ad.holding.com

То теперь мы можем отключить такое ограничение, заменив соответствующие параметры на такой вариант:

...
[domain/ad.holding.com]
...
access_provider = ad

После внесённых изменений выполним перезапуск службы sssd с очисткой кеша:

# service sssd stop
# ( rm -f /var/lib/sss/db/* ) && ( rm -f /var/lib/sss/mc/* )
# service sssd start

Таким образом мы отключим глобальное ограничение, нацеленное на определённую доменную группу безопасности и все службы, которые используют аутентификацию/авторизацию из SSSD, можно будет отдельно настроить на ограничение отдельных групп безопасности.

Общий принцип настройки политик PAM для разных служб

Если мы заглянем в каталог /etc/pam.d/, то увидим множество файлов, определяющих политики PAM для той или иной службы сервера, умеющей использовать аутентификацию и авторизацию с помощью PAM. Структура файлов в этом каталоге мне больше нравится в Debian, чем в CentOS, так как более интуитивно понятна и упорядочена. Например, общие для всех параметры в Debian включены в файлы с понятными именами common- (common-auth, common-account, common-password и т.п.). Эти файлы в свою очередь подключены в файлах, касающихся отдельных служб, например login или sshd (в них присутствуют строки типа @include common-auth). Таким образом, воздействовать на настройки PAM для разных служб можно как на глобальном уровне, изменяя файлы /etc/pam.d/common-, так и на уровне отдельных служб, изменяя конкретные файлы типа /etc/pam.d/login или /etc/pam.d/sshd.

Так как нам требуется уникальная настройка ограничения прав доступа для разных служб, то общие файлы типа common-* мы трогать не будем, а будем изменять конфигурационные файлы PAM для отдельных служб. Для ограничения доступа мы будем использовать возможности библиотеки pam_listfile.so, которую будем вызывать в файлах политик PAM интересующих нас служб в каталоге /etc/pam.d/.

Библиотека pam_listfile.so – это удобный инструмент, который, в частности, позволяет выполнять проверку вхождения пользователя в группу, которая указана во внешнем файле. В таком внешнем файле могут быть указаны как локальные по отношению к серверу группы, так и группы безопасности из домена Active Directory, список которых, в свою очередь, нам помогает получать sssd. Файл групп может содержать как одну группу, так и несколько (по одной группе в каждой отдельной строке). При этом в одном файле можно комбинировать как локальные, так и доменные группы.

Далее мы рассмотрим пример того, как подобным образом настроить PAM-политику для локального входа на сервер (/etc/pam.d/login), подключения к серверу SSHD (/etc/pam.d/sshd) и доступа к сайту веб-сервера Apache (создадим собственный файл политик PAM).

Настраиваем PAM для ограничения доступа на локальный вход в систему

Создадим файл для хранения списка групп, которым мы хотим предоставить право локального входа в систему. Обязательно ограничим доступ к этому файлу:

# touch /etc/access-groups-to-system
# chown root:root /etc/access-groups-to-system
# chmod 600 /etc/access-groups-to-system

Наполним файл группами, по одной в каждой строчке. Обязательно укажем системные локальные группы типа root и adm, чтобы ненароком не отобрать доступ к серверу у локальных административных учётных записей Linux, затем перечислим нужные доменные группы безопасности:

root
adm
kom-srv-linux-admins@ad.holding.com

Теперь файл групп подключим к политике PAM в конфигурационном файле /etc/pam.d/login таким образом, чтобы его использование было инициировано вызовом библиотеки pam_listfile.so.

...
# Restricted access to service from local and domain groups
account required pam_listfile.so onerr=fail item=group sense=allow file=/etc/access-groups-to-system

# Standard Un*x account and session
@include common-account
@include common-session
@include common-password
...

В данном примере библиотека pam_listfile.so вызывается модулем account, который используется на этапе авторизации. Набор параметров (onerr=fail item=group sense=allow) определяет то, что авторизация считается не успешной, если проверяемый пользователь не входит ни в одну из перечисленных в указанном файле групп (file=/etc/access-groups-to-system). При этом желательно учитывать порядок вызова модулей в файле политик PAM, то есть вызов нашей проверки членства в группе можно сделать до того, как идёт стандартная обработка модулей account (подключаемых в данном конкретном примере из common-account).

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

Итак, попробуем залогиниться на консоль сервера, используя учётную запись пользователя, входящего в разрешённую нами доменную группу. При этом наблюдаем за логом auth.log. В случае успешной аутентификации и авторизации увидим примерно следующее:

# tail -f /var/log/auth.log

login[420]: pam_sss(login:auth): authentication success; logname=LOGIN uid=0 euid=0 tty=/dev/tty2 ruser= rhost= user=adm-petya
login[420]: pam_unix(login:session): session opened for user adm-petya by LOGIN(uid=0)
systemd-logind[719]: New session 1910 of user adm-petya@ad.holding.com.

Теперь попробуем залогиниться, используя любую другую доменную учётную запись пользователя, заведомо не входящую ни в одну из разрешённых групп:

login[4404]: pam_sss(login:auth): authentication success; logname=LOGIN uid=0 euid=0 tty=/dev/tty3 ruser= rhost= user=vasya
login[4404]: pam_listfile(login:account): Refused user vasya for service login
login[4404]: Authentication failure

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

Аналогичным образом рекомендуется проверить не только доступ доменных учётных записей, но и доступ локальных административных записей Linux, чтобы у нас всегда оставалась возможность подключения к серверу, даже если с sssd возникнут какие-то проблемы и доменная аутентификация вдруг перестанет работать.

Настраиваем PAM для ограничения доступа к серверу SSHD

Аналогичным образом можем настроить доступ к службе сервера sshd. Для этого нам потребуется внести изменения в файл политик PAM для этой службы - /etc/pam.d/sshd.

...
# Restricted access to service from local and domain groups
account required pam_listfile.so onerr=fail item=group sense=allow file=/etc/access-groups-to-system

# Standard Un*x authorization.
@include common-account
...

Здесь мы уже можем использовать другой файл для хранения групп доступа. Однако учитывая то, что к sshd обычно имеют доступ те же пользователи, что имеют право локального входа на сервер мы будем указывать тот же файл, что использовали для политик PAM в конфигурационном файле /etc/pam.d/login.

В конфигурационном файле настроек службы sshd (/etc/ssh/sshd_config) в конфигурации по умолчанию уже имеется опция разрешающая использовать аутентификацию с помощью PAM:

...
UsePAM yes
...

Поэтому никаких дополнительных настроек в системе делать не потребуется.

И также как, в случае с ранее рассмотренной настройкой локального входа, проверяем для службы sshd возможность аутентификации доменным пользователем из разрешённой группы доступа, прочим доменным пользователем, а также локальным пользователем Linux. 

Настраиваем PAM для ограничения доступа к сайту веб-сервера Apache

Теперь рассмотрим более сложный пример с ограничением доступа к некому сайту веб-сервера Apache, который работает на нашем Linux-сервере. Предположим, что к сайту должны иметь доступ доменные пользователи, входящие в группу безопасности KOM-SRV-WebApp1-Operators.

Сначала создадим файл, содержащий группы доступа к нашему веб-сайту (например /etc/access-groups-to-apache2-webapp1) и ограничим права доступа к нему:

# echo "KOM-SRV-WebApp1-Operators@ad.holding.com" > /etc/access-groups-to-apache2-webapp1
# chown root:www-data /etc/access-groups-to-apache2-webapp1
# chmod 640 /etc/access-groups-to-apache2-webapp1

Затем создадим и настроим файл выделенной политики PAM для нашего веб-приложения (например /etc/pam.d/apache2-webapp1), сделав в нём ссылку на файл групп следующим образом:

# cat > /etc/pam.d/apache2-webapp1 <<EOF
auth    required   pam_sss.so
account required   pam_listfile.so onerr=fail item=group sense=allow file=/etc/access-groups-to-apache2-webapp1
account required   pam_sss.so
EOF
# chown root:root /etc/pam.d/apache2-webapp1
# chmod 644 /etc/pam.d/apache2-webapp1

Теперь созданную политику PAM можем подключать в конфигурации сайта веб-сервера Apache. Например, при использовании Kerberos-аутентификации вместо зачастую используемого условия Require valid-user, мы можем использовать условие типа Require pam-account <имя политики PAM из каталога /etc/pam.d>:

...
<Directory "/var/www/webapp1">
     AuthType Kerberos
     AuthName "Kerberos Login"
     Krb5Keytab /etc/apache2/s-WebApp1-Apache-Krb.keytab
     KrbAuthRealms AD.HOLDING.COM
     KrbMethodK5Passwd off
     Require pam-account apache2-webapp1
     ...
</Directory>
...

После изменения конфигурации сайта Apache для вступления изменений в силу можно перезагрузить службу веб-сервера:

# service apache2 restart

Теперь можно проверить результат.

***

В заключении хочу сказать, что учитывая то, что PAM довольно гибкий и мощный механизм, рассмотренный здесь пример разграничения прав доступа с помощью библиотеки pam_listfile.so является лишь одним из возможных вариантов решения поставленной задачи.