[devel] PAM-политики (общий взгляд)

Evgeny Sinelnikov sin на altlinux.org
Чт Июн 15 13:35:41 MSK 2017


Здравствуйте,

возвращаясь к уже предложенному
(https://lists.altlinux.org/pipermail/devel/2017-May/202692.html),
хочу поделиться своим видением, предложениями и конкретными тестовыми
сборками пакетов, связанных с настройками подсистемы аутентификации
(aka PAM). В этом письме я хочу изложить общий взгляд перед тем, как
выдвигать какие-то предложения и тестовые сборки.

Что мы имеем на сегодняшний день?
- у нас имеется общий пакет pam-config с базовыми шаблонами настроек
для local, krb5, krb5_ccreds, ldap, multi, pkcs11, winbind
(/etc/pam.d/system-auth-*);
- к ним в пару имеются согласованные use_first_pass шаблоны
(/etc/pam.d/system-auth-use_first_pass-*) для встраивания в стек не
интерактивных приложений;
- аналогичная пара шаблонов для модуля sss (и службы sssd)
устанавливается с пакетом sssd-client;
- также в пакете pam-config имеется обобщённая пара шаблонов
common-login и common-login-use_first_pass, расширяющая текущую,
выбранную пару system-auth и system-auth-use_first_pass, которая, в
свою очередь, выбирается символическими ссылками через утилиту
control.

Вся эта схема уже давно работает и используется в конкретных
приложениях, каждое из которых имеет свой специфичный набор настроек,
основанный на текущей выбранной паре system-auth PAM-шаблонов. Обычно
через обобщённую пару common-login.

При этом каждый выбираемый вариант пары system-auth - это, по сути, и
есть отдельная PAM-политика:
[root at tor ~]# control system-auth list
krb5 krb5_ccreds ldap local multi pkcs11 sss winbind

[root at tor ~]# control system-auth help
krb5: authentication via Kerberos 5
krb5_ccreds: authentication via Kerberos 5 with local caching
ldap: authentication via LDAP
local: local authentication
multi: use multi authentication method
pkcs11: use pkcs11 authentication method
sss: use sss authentication method
winbind: authentication via Winbind

Все PAM-политики, кроме local, расширяют стандартный источник
аутентификации (хеш в пароля) дополнительным:
- ldap - хеш в доступный по протоколу LDAP на выделенном LDAP-сервере;
- krb5 - аутентификация по протоколу Kerberos на выделенном сервере
распределения ключей (KDC);
- multi - универсальный гибридный набор настроек, использующий krb5
или ldap, если эти модули установлены;
- pkcs11 - аутентификация специальными средствами криптографической
защиты, как правило аппаратными;
- winbind - аутентификация через службу winbind в домене NT (по
протоколу NTLM) или в Active Directory (по протоколу Kerberos)
- sss - аутентификация через службу sssd (System Security Services) в
заданной инфраструктуре Active Directory, Kerberos, FreeIPA, LDAP,
...;

Каждую из этих PAM-политик настраивать и отлаживать требуется
отдельно. В целом, для клиента, конкретная PAM-политика выполняет одни
и те же функции:
- применяет дополнительные политики (на сложность и срок действия
пароля, время входа, и т.п.) - account;
- выполняет аутентификацию в дополнительном источнике аутентификации - auth;
- осуществляет подготовку сеанса после аутентификации и входа в
систему, а также выхода из неё - session;
- при возможности (для смарткарты может быть не актуально), позволяет
менять пароль.
___________________________


Собственно так оно уже есть. Но важной остаётся следующая деталь - как
это работает в согласовании с механизмами авторизации (то есть со
стеком NSS-модулей)?

А, если совсем упростить, то вопрос можно поставить иначе: "Как
PAM-модули отличают имена "своих" пользователей, среди найденных через
Glibc NSS?" PAM-модули winbind и sss такую проверку могут осуществить,
а вот ldap и krb5 уже вряд ли (хотя про ldap нужно ещё уточнить).

Вот, например, возьмём воспроизводимый пример на основе Samba-стенда с
модулем sss:
https://lists.altlinux.org/pipermail/community/2017-June/686716.html

[vagrant at client ~]$ id vagrant
uid=500(vagrant) gid=500(vagrant)
группы=500(vagrant),10(wheel),14(uucp),19(proc),22(cdrom),71(floppy),80(cdwriter),81(audio),83(radio),478(video),475(camera),474(xgrp),473(scanner)
[vagrant at client ~]$ getent passwd vagrant
vagrant:x:500:500::/home/vagrant:/bin/bash

[vagrant at client ~]$ id Administrator
uid=1976000500(administrator) gid=1976000513(domain users)
группы=1976000513(domain users),1976000512(domain
admins),1976000572(denied rodc password replication
group),1976000519(enterprise admins),1976000520(group policy creator
owners),1976000518(schema
admins),1976000514(users),100(users),466(localadmins),10(wheel)
[vagrant at client ~]$ getent passwd Administrator
administrator:*:1976000500:1976000513:Administrator:/home/DOMAIN.ALT/administrator:/bin/bash

В каком порядке сейчас работают PAM-модули?
[vagrant at client ~]$ sudo control system-auth
sss
[vagrant at client ~]$ cat /etc/pam.d/system-auth
#%PAM-1.0
auth            required        pam_env.so
auth            [success=2 default=ignore]      pam_tcb.so shadow fork
prefix=$2y$ count=8 nullok
auth            requisite       pam_succeed_if.so uid >= 500 quiet
auth            required        pam_sss.so use_first_pass
auth            required        pam_permit.so

account         [success=2 default=ignore]      pam_tcb.so shadow fork
account         requisite       pam_succeed_if.so uid >= 500 quiet
account         [default=bad success=ok user_unknown=ignore]    pam_sss.so
account         required        pam_permit.so

password        required        pam_passwdqc.so config=/etc/passwdqc.conf
password        [success=2 default=ignore]      pam_tcb.so use_authtok
shadow fork prefix=$2y$ count=8 nullok write_to=tcb
password        requisite       pam_succeed_if.so uid >= 500 quiet
password        required        pam_sss.so use_authtok

session         [success=2 default=ignore]      pam_tcb.so
session         requisite       pam_succeed_if.so uid >= 500 quiet
session         required        pam_sss.so
session         required        pam_mktemp.so
session         required        pam_mkhomedir.so silent
session         required        pam_limits.so

[vagrant at client ~]$ su - Administrator
Password:
[administrator at client ~]$ id
uid=1976000500(administrator) gid=1976000513(domain users)
группы=1976000513(domain
users),10(wheel),100(users),466(localadmins),1976000512(domain
admins),1976000514(users),1976000518(schema
admins),1976000519(enterprise admins),1976000520(group policy creator
owners),1976000572(denied rodc password replication group)
[administrator at client ~]$ klist
Ticket cache: KEYRING:persistent:1976000500:krb_ccache_0zUidJY
Default principal: Administrator at DOMAIN.ALT

Valid starting       Expires              Service principal
15.06.2017 00:30:25  15.06.2017 10:30:25  krbtgt/DOMAIN.ALT at DOMAIN.ALT
        renew until 22.06.2017 00:30:25

[administrator at client ~]$ su - vagrant
Password:
[vagrant at client ~]$ id
uid=500(vagrant) gid=500(vagrant)
группы=500(vagrant),10(wheel),14(uucp),19(proc),22(cdrom),71(floppy),80(cdwriter),81(audio),83(radio),473(scanner),474(xgrp),475(camera),478(video)
[vagrant at client ~]$ klist
klist: Credentials cache keyring 'persistent:500:500' not found

Сейчас аутентификация работает так:
1) сначала проверяется локальный пароль для заданного имени
пользователя, вне зависимости от того, каким модулем NSS он был
определён:
[vagrant at client ~]$ grep ^passwd /etc/nsswitch.conf
passwd: files sss
2) далее, если локальный пароль подошёл, то аутентификация
завершается, иначе для пользователей с uid >= 500 (то есть и для
локальных тоже), делается попытка провести глобальную аутентификацию в
домене.

То есть, если бы локальный пароль для пользователя administrator
существовал, то его можно было бы использовать. Но с модулем pam_sss
просто так этого не сделаешь:
[vagrant at client ~]$ sudo su - -c 'passwd Administrator'
passwd: updating all authentication tokens for user administrator.
Password reset by root is not supported.
passwd: Permission denied.

Чтобы задать локальный пароль, нужно чтобы пользователь с таким именем
уже существовал до настройки nss_sss модуля, иначе просто так его уже
не создать:
[vagrant at client pam.d]$ sudo useradd administrator
useradd: пользователь «administrator» уже существует

Такую ситуацию можно подготовить вручную:
[vagrant at client pam.d]$ sudo vim /etc/nsswitch.conf
[vagrant at client pam.d]$ grep '^passwd\|^shadow' /etc/nsswitch.conf
passwd: files
shadow: tcb files
[vagrant at client pam.d]$ sudo useradd administrator
[vagrant at client pam.d]$ sudo vim /etc/nsswitch.conf
[vagrant at client pam.d]$ grep '^passwd\|^shadow' /etc/nsswitch.conf
passwd: files sss
shadow: tcb files sss
[vagrant at client pam.d]$ sudo su - -c "passwd administrator"
passwd: updating all authentication tokens for user administrator.

You can now choose the new password or passphrase.

A valid password should be a mix of upper and lower case letters,
digits, and other characters.  You can use an 8 character long
password with characters from at least 3 of these 4 classes, or
a 7 character long password containing characters from all the
classes.  An upper case letter that begins the password and a
digit that ends it do not count towards the number of character
classes used.

A passphrase should be of at least 3 words, 11 to 40 characters
long, and contain enough different characters.

Alternatively, if no one else can see your terminal now, you can
pick this as your password: "Woman=You=plea".

Enter new password:
Weak password: too short.
Re-type new password:
passwd: all authentication tokens updated successfully.

[vagrant at client pam.d]$ sudo ls /etc/tcb/administrator -ld
drwx--s--- 2 administrator auth 4096 июн 15 10:39 /etc/tcb/administrator

Тогда можно обнаружить вот такое волшебство:

[vagrant at client ~]$ id administrator
uid=501(administrator) gid=501(administrator)
группы=501(administrator),1976000512(domain admins),1976000513(domain
users),1976000514(users),1976000572(denied rodc password replication
group),1976000518(schema admins),1976000519(enterprise
admins),1976000520(group policy creator
owners),466(localadmins),10(wheel),100(users)

[vagrant at client ~]$ id Administrator
uid=1976000500(administrator) gid=1976000513(domain users)
группы=1976000513(domain users),1976000512(domain
admins),1976000520(group policy creator
owners),1976000514(users),1976000572(denied rodc password replication
group),1976000518(schema admins),1976000519(enterprise
admins),100(users),466(localadmins),10(wheel)
___________________________


Детали коллизий можно приводить достаточно долго. В целом, текущие
настройки достаточно устойчивы к сбоям, хотя и не всегда корректны в
сложных конфигурациях. Некорректность эта связана, прежде всего, с
тем, как пересекаются настройки относящиеся к локальным механизмам
аутентификации с настройками дополнительных (прежде всего, глобальных)
механизмов аутентификации и авторизации.

В настоящее время по этому поводу имеется актуальная проблема смены
пароля для глобальных пользователей в доменах Samba и FreeIPA, которая
приводит к тому, что:
- локальные и глобальные PAM-модули вызываются поочерёдно, то есть
могут запрашивать текущий пароль дважды;
- политика ограничений на сложность локального пароля смешивается с
политикой ограничений на сложность глобального пароля;
- в связи с особенностями реализации графической утилиты смены пароля
userpasswd, с текущими нелокальными PAM-политиками утилита не
работает:
https://bugzilla.altlinux.org/show_bug.cgi?id=33097


-- 
Sin (Sinelnikov Evgeny)


Подробная информация о списке рассылки Devel