[devel] Смена глобального пароля

[devel] Смена глобального пароля

[Evgeny Sinelnikov]

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

Хочу обсудить проблему смены глобального пароля (то есть сетевого
пароля через LDAP, Kerberos и др. возможные механизмы) по мотивам
#33163 - Смена Kerberos-пароля для pam_krb5:
https://bugzilla.altlinux.org/show_bug.cgi?id=33163

В сущности, проблемы выглядит следующим образом - привожу цитату из
багзилы по поводу настроек PAM, по умолчанию, для смены пароля через
pam_krb5:

> > Вообще, зачем применять такую связку?
> >  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_krb5.so use_authtok
> >
> > Весь её смысл в том, что если Kerberos-пароль изменён успешно, то заменить,
> > заодно, и локальный пароль... Но нужно ли так делать???
>
> Тут написано другое: сперва поменять локальный пароль с помощью pam_tcb, а если
> это не получилось и uid >= 500, то поменять нелокальный пароль с помощью
> pam_krb5.  Странно если это не работает.

Хочу обратить внимание на то, что текущий сценарий смены глобальных
паролей опирается на весьма сомнительную особенность, характерную для
unix-систем и совершенно не очевидную для пользователей корпоративных
решений.

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

И у нас, как и везде, применяется, по умолчанию, гибридная схема смены пароля:
- если локальный пароль подошёл, то меняем его, а если нет... то
меняем глобальный.

Кроме того, что эта схема сейчас, вообще, не работает, возникает более
существенный вопрос (допустим она может заработать): "А зачем мы её
применяем по, умолчанию?"

_________________________________________

Что же, собственно, происходит?
1. Вместо смены глобального пароля, меняется локальный. В этом
основная проблема.
2. Вопреки ожиданиям, текущий пароль может запрашиваться дважды.
Собственно, только неправильно задав один вид пароля, можно перейти к
попытке проверить другой вид пароля.
3. Вывод строк запроса на ввод текущего (а иногда и нового) пароля,
для каждого PAM модуля может быть разным. В связи с чем мы имеем не
рабочий userpasswd:
https://bugzilla.altlinux.org/show_bug.cgi?id=33097

При этом, если поменять порядок модулей, и первым поставить проверку
глобального пароля, вместо локального, то всё вроде начинает
отрабатывать.

__________________________________________

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

Может быть, не стоит пытаться "угадывать" какой пароль мы меняем, а
ввести для каждого типа отдельный вариант настройки вроде
passwd.local, passwd.sssd?
https://bugzilla.altlinux.org/show_bug.cgi?id=33163#c4

Ну, или, по крайней мере, если используется настройка с глобальными
паролями, в первую очередь пытаться изменить глобальный? Или, вообще,
только глобальный, а локальный изменять отдельной утилитой
passwd.local?


-- 
Sin (Sinelnikov Evgeny)

Re: [devel] Смена глобального пароля

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 5465 bytes --]

On Fri, Mar 03, 2017 at 01:27:08PM +0400, Evgeny Sinelnikov wrote:
> Здравствуйте,
> 
> Хочу обсудить проблему смены глобального пароля (то есть сетевого
> пароля через LDAP, Kerberos и др. возможные механизмы) по мотивам
> #33163 - Смена Kerberos-пароля для pam_krb5:
> https://bugzilla.altlinux.org/show_bug.cgi?id=33163
> 
> В сущности, проблемы выглядит следующим образом - привожу цитату из
> багзилы по поводу настроек PAM, по умолчанию, для смены пароля через
> pam_krb5:
> 
> > > Вообще, зачем применять такую связку?
> > >  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_krb5.so use_authtok
> > >
> > > Весь её смысл в том, что если Kerberos-пароль изменён успешно, то заменить,
> > > заодно, и локальный пароль... Но нужно ли так делать???
> >
> > Тут написано другое: сперва поменять локальный пароль с помощью pam_tcb, а если
> > это не получилось и uid >= 500, то поменять нелокальный пароль с помощью
> > pam_krb5.  Странно если это не работает.

На самом деле это некоторое упрощение, ведь password stack работает в два
прохода, PAM_PRELIM_CHECK (который опрашивает модули) и PAM_UPDATE_AUTHTOK
(который меняет пароли).  Кроме того, приложение определяет, менять пароль
всегда (как это делает passwd) или только по истечении срока действия
(PAM_CHANGE_EXPIRED_AUTHTOK, как это делает login).

Когда в password stack попадают два модуля, каждый из которых при
некоторых условиях может поменять соответствующий пароль (как pam_tcb
с pam_krb5 в этом примере), становится весело.

На предварительной стадии первый же модуль в passwd stack, который успешно
проверил введённый пользователем прежний пароль, сохраняет его в
PAM_OLDAUTHTOK, и все остальные модули, как правило, будут проверять
только этот пароль.

На стадии смены пароля новый пароль, введённый пользователем по запросу
одного модуля, используется последующими модулями, у которых указан
параметр use_authtok.

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

Когда в password stack попадают более двух модулей, меняющих пароль,
предсказать их поведение становится ещё немного сложнее.

> Хочу обратить внимание на то, что текущий сценарий смены глобальных
> паролей опирается на весьма сомнительную особенность, характерную для
> unix-систем и совершенно не очевидную для пользователей корпоративных
> решений.
> 
> Дело в том, что механизмы аутентификации и авторизации, вообще говоря,
> совершенно независимы и явно доступны для настройки. Таким образом, у
> глобального пользователя может быть, как локальный, так и глобальный
> пароли.
> 
> И у нас, как и везде, применяется, по умолчанию, гибридная схема смены пароля:
> - если локальный пароль подошёл, то меняем его, а если нет... то
> меняем глобальный.
> 
> Кроме того, что эта схема сейчас, вообще, не работает, возникает более
> существенный вопрос (допустим она может заработать): "А зачем мы её
> применяем по, умолчанию?"

Видимо потому, что универсальной устраивающей всех схемы не существует,
а по умолчанию надо предложить какую-нибудь универсальную конфигурацию.

PAM это очень гибкий инструмент, который подходит для настройки под
конкретную задачу.

> Что же, собственно, происходит?
> 1. Вместо смены глобального пароля, меняется локальный. В этом
> основная проблема.
> 2. Вопреки ожиданиям, текущий пароль может запрашиваться дважды.
> Собственно, только неправильно задав один вид пароля, можно перейти к
> попытке проверить другой вид пароля.
> 3. Вывод строк запроса на ввод текущего (а иногда и нового) пароля,
> для каждого PAM модуля может быть разным. В связи с чем мы имеем не
> рабочий userpasswd:
> https://bugzilla.altlinux.org/show_bug.cgi?id=33097
> 
> При этом, если поменять порядок модулей, и первым поставить проверку
> глобального пароля, вместо локального, то всё вроде начинает
> отрабатывать.
> __________________________________________
> 
> В связи с перечисленным предлагаю обсудить "правильный" набор настроек
> PAM и, вообще, подход к смене глобальных паролей.
> 
> Может быть, не стоит пытаться "угадывать" какой пароль мы меняем, а
> ввести для каждого типа отдельный вариант настройки вроде
> passwd.local, passwd.sssd?
> https://bugzilla.altlinux.org/show_bug.cgi?id=33163#c4
> 
> Ну, или, по крайней мере, если используется настройка с глобальными
> паролями, в первую очередь пытаться изменить глобальный? Или, вообще,
> только глобальный, а локальный изменять отдельной утилитой
> passwd.local?

Мы можем сделать passwd.local, это нам практически ничего не стоит,
да и и passwd.какой_нибудь_другой_вариант тоже можем упаковать.
Когда в passwd stack только один модуль, меняющий пароль, всё становится
гораздо проще.  Надо только знать, какой именно вариант passwd вызывать.
А откуда это можно знать?

Вероятно, лучше было бы обучить каждый модуль, который меняет
пароль, при указании специального параметра определять,
является ли данный PAM_USER локальным для этого модуля.
Тогда можно было бы попробовать сохранить универсальное решение.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 801 bytes --]