|
ru.unix
- RU.UNIX ----------------------------------------------------------------------
From : Nick A. Leuta 2:5020/400 24 Jun 2000 20:14:08
To : All
Subject : Hа: Hа: Hа: Hа: Hа: Hа: Hа: Hа: Hа: Hа: uucpd and PAM
--------------------------------------------------------------------------------
"Vladimir Kravchenko" <jimson@voron.elektra.ru> сообщил/сообщила в новостях
следующее:
> >>>>> Nick A Leuta (NAL) :
> NAL> Расшаривание файлов passwd la-la-la - это исконная идеология NIS,
> NAL> насколько я помню...
> и nss, только подход намного более гибкий
NSS не шарит _файлы_, их вообще может не быть. Он шарит _информацию_,
которая
в традиционном варианте хранится в файлах.
> >> криптованное сосединение если это поддерживается схемой аутентикации,
а
> NAL> пам построен на LDAP можно гнать через SSL, Radius или Kerberos для
> NAL> аутентификации и предназначены...
> я ничего не понял, где тут запятые должны быть ? :)
Хмм, глюки ньюсридера: фраза должна была начинаться так: "LDAP можно гнать
через SSL, Radius или...", но почему-то в начало попал конец цитаты...
Hеужели свои слова не узнал :-)
> >> том принципе что ему передают пароль, и ничего кроме пароля.
> NAL> PAM'у передают пинок "начинай аутентифицировать", а уж про пароль он
> NAL> спросит сам, если захочет, конечно... А может и не захотеть, и
> NAL> попросить карточку-мандат в сканнер вставить...
> во-во, он считает карточку, потом возьмет эталон и сверит что получилось,
в
> результате "вернет 0 или 1"
0 и 1 - это pam. NSS в приложениях напрямую не используется, во-первых, а
во-вторых, он возвращает конкретные значения, которые потом другими, более
традиционными функциями типа getpw*() etc. скармливаются вызвавшему их
приложению. В принципе, если бы пароль (в обобщенном смысле), можно было
получить, чтобы потом уже в системе сравнить (как это делается с помощью
getpwnam(), например, при традиционной локальной аутентификации), то
можно одним nss'ом обойтись. Hо поскольку такое проходит не всегда (NDS тебе
не отдаст пароля, например), то приходится выкручиваться с помощью pam'a:
отдаем ему пароль, тот его _как-то_ (в общем случае заранее не известно как,
например, начинает "переговоры" с удаленной аутентифицирующей системой по
какому-то аутентификационному протоколу) проверяет, и дает тот самый 0/1.
> в чем существенна разница между сверкой по паролю ? если не считать что
> "втавить карточку" это попросить ввести пароль, а сверить с эталоном это
> сделать из введенного пароля хеш и сравнить с master.passwd
Хмм, что-то не дойдет до меня смысл: при любой аутентификации что-то с
чем-то сравнивается, и на основании этого сравнения принимается решение...
Шестым чувством еще ни одна система не научилась угадывать, на самом ли
деле тот, кто аутентифицируется, тот, за кого себя выдает...
Kerberos, используюет в своей работе симметричную методологию, предназначен
для аутентификации доступа к ресурсам в сети и использует центральную базу
данных, в которой хранятся копии секретных ключей всех пользователей. В
симметричной методологии и для шифрования, и для расшифровки отправителем и
получателем применяется один и тот же ключ, об использовании которого они
договорились до начала взаимодействия. Если ключ не был скомпрометирован, то
при расшифровке автоматически выполняется аутентификация отправителя, так
как только отправитель имеет ключ, с помощью которого можно зашифровать
информацию, и только получатель имеет ключ, с помощью которого можно
расшифровать информацию. Так как отправитель и получатель - единственные
люди, которые знают этот симметричный ключ, при компрометации ключа будет
скомпрометировано только взаимодействие этих двух пользователей. Проблемой,
которая будет актуальна и для других криптосистем, является вопрос о том,
как безопасно распространять симметричные (секретные) ключи.
Так что без "обобщенного пароля" все равно не обходится. В конце концов
никто не говорит, что единственным возможным способом его верификации
является сверка его с оригиналом, как это происходит при традиционной
аутентификации в UNIX'ах... И это опять же не противоречит идее pam'a - кому
какая разница, как он пришел к выводу (по SMB, kerberos'у, LDAP'у или NCP
пообщался с аутентификатором), что надо вернуть - 0 или 1 (по
отношению к вызову pam'а, протокол, по которому производится собственно
аутентификация, - более низкий уровень).
Кстати, раз уж заело - pam-модуль для kerberos'a _с_у_щ_е_с_т_в_у_е_т_
(http://www.kernel.org/pub/linux/libs/pam/modules.html), как, впрочем, и для
упоминавшегося ранее SQL (см. там же).
> NAL> Кроме того, SASL согласно мануалу, method for adding authentication
> NAL> support to connection-based protocols, и как я понял из rfc, он
> NAL> отвечает за безопасность доставки до сервера пароля или чего еще
надо
> NAL> стоящей на сервере системе аутентификации, s/key или kerberos
> NAL> там... Так что они с pam'ом вроде как не пересекаются...
> все ты не правильно понял
> что ты подразумеваешь под "отвечать за безопасность доставки до сервера
> пароля" ? SASL может и без пароля, в часности через SASL можно сервер
> "обучить" чесному kerberos (v4 or gssapi_v2). SASL это тоже API.
SASL согласно RFC - способ аутентификации при установлении _соединения_,
т.е. не совсем понятно, как его прикрутить к консоли, например. Это
во-первых. А во-вторых, SASL (и kerberos), не заменит собой passwd с
компанией, т.е. на роль альтернативы NSS они ну не как не тянут.
Кроме того, не вижу теоритеческих преград для использования pam'a при
аутентификации сетевого клиента через SASL...
- --- rfc example begin ---
S: * OK IMAP4 Server
C: A001 AUTHENTICATE KERBEROS_V4
S: + AmFYig==
C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT
+nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFd
WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh
S: + or//EoAADZI=
C: DiAF5A4gA+oOIALuBkAAmw==
S: A001 OK Kerberos V4 authentication successful
- --- rfc example end ---
S- сервер, C - клиент. То, что в четвертой строке пишется на 3-х строках, в
оригинале должно быть в одной
Очень даже понятно, чем именно аутентификация через SASL+kerberos отличается
от обычной... Вместо kerberos'a там может быть s/key или еще что-нибудь
(действительно подключаемое по модульному принципу), но суть останется
прежней - способ аутентификации при установлении сетевого соединения.
===================
* Linux... Хотели-то как лучше, а получился опять Windows...
SkyNick
--- ifmail v.2.15dev5
* Origin: Lipetsk State Technical University (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
