ALT Linux Team development discussions
 help / color / mirror / Atom feed
From: "Dmitry V. Levin" <ldv@altlinux.org>
To: ALT Linux Team development discussions <devel@lists.altlinux.org>
Subject: Re: [devel] Смена глобального пароля
Date: Sat, 4 Mar 2017 03:50:22 +0300
Message-ID: <20170304005022.GC24806@altlinux.org> (raw)
In-Reply-To: <CAK42-Gq3esY0w8WWk2PDjn1KegrG11DuO6zuQRXjn420voDctQ@mail.gmail.com>

[-- 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 --]

      reply	other threads:[~2017-03-04  0:50 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-03  9:27 Evgeny Sinelnikov
2017-03-04  0:50 ` Dmitry V. Levin [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170304005022.GC24806@altlinux.org \
    --to=ldv@altlinux.org \
    --cc=devel@lists.altlinux.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

ALT Linux Team development discussions

This inbox may be cloned and mirrored by anyone:

	git clone --mirror http://lore.altlinux.org/devel/0 devel/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 devel devel/ http://lore.altlinux.org/devel \
		devel@altlinux.org devel@altlinux.ru devel@lists.altlinux.org devel@lists.altlinux.ru devel@linux.iplabs.ru mandrake-russian@linuxteam.iplabs.ru sisyphus@linuxteam.iplabs.ru
	public-inbox-index devel

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://lore.altlinux.org/org.altlinux.lists.devel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git