Stanislav Ievlev, inger@linux.ru.net

 

Первая публикация произошла на linux.ru.net

 

0. О статье

Статья эта развивалась долго и нудно. Первая версия появилась на linux.ru.net и составляла только первую часть этого труда. Но время шло, знаний прибавлялось и захотелось прололжения. Систематизировать свои знания так интересно. Присоединяйтесь.

 

1. PAM c точки зрения пользователя

Как было раньше. Желая войти в систему вы были вынуждены пообшаться с программой-охранником гордо именуемой login. Она спрашивала ваше имя, затем пароль шифровала известным алгоритмом и сличала получивуюся абракадабру с записью в файле /etc/passwd. Если все совпадало, то вам разрешалось войти иначе предлагалось начать все с начала.

Через некоторое время наученные горьким опытом системы перестали хранить зашифрованные пароли в файле /etc/passwd открытом на всеобщее обозрение и переместили эту интимную информацию в файл /etc/shadow, читать который дозводено было только обладателям правами суперпользователя. Программа login была переписана заново: теперь она умела и читать из нового файла и шифровать по более серьезному алгоритму.

 

Неизвестно сколько еще раз пришлось бы переписывать эту программу, да и не только ее (с паролированием в системе связаны еще и passwd, и su), если бы не пришла кому-то в голову мысль отделить программы от механизма аутентификации. Эта система получила название PAM (Pluggable Authentication Modules), что по-русски означает Подгружаемые Модули Аутентификации (ПМА).

Теперь если программа (в частности login) жалает произвести аутентификацию пользователя она больше не занимается этим, а обращается к PAM’у с соответствующей просьбой. Последний выполняет все проверки и докладывает вызвавшему его о результатах-пускать или не пускать. Все заботы о выборе алгоритма и особенностях аутентификации теперь лежат на PAM’е программа и не догадывается через какие круги ада проходит пользователь чтобы его приняли.

 

Формально PAM выполнен в виде разделяемых библиотек-модулей комфортно расположившихся в каталоге /lib/security/. Каждый модуль по особому пропускает через себя пользователя, реализуя свой особенный механизм аутентификации. То есть, запуская тот или иной набор модулей, мы как из кирпичиков складываем сценарий аутентификации согласно нашим привычкам и желаниям.

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

Заглянем во внутрь этого файла. содержимое может выглядить, например, так:

 

#%PAM-1.0
auth requisite /lib/security/pam_unix.so nullok #set_secrpc
auth required /lib/security/pam_securetty.so
auth required /lib/security/pam_env.so
auth required /lib/security/pam_mail.so
account required /lib/security/pam_unix.so
password required /lib/security/pam_unix.so strict=false
session required /lib/security/pam_unix.so none # debug or trace
session required /lib/security/pam_limits.so

 

Каждая строчка означает, что для удачной аутентификации пользователь должен пройти через указанный модуль. Вообще формат записи:

 

Тип-Модуля Флаг-Контроля Путь-К-Модулю Параметры-Модуля

Тип-Модуля должен быть одним из следующих:

 

* auth:Такой модуль проверяет наличие пользователя в системе, спрашивает его имя, разрешает или нет доступ в ту или иную группу (независимо от записей в файле /etc/groups) и вообще способен давать привилегии (конечно специально предназначенные для этого).

* account: Этот модуль не занимается аутентификацией, а позволяет контролировать распределение ресурсов системы для тех или иных пользовательских бюджетов.

* session:А этот связан с вещами которые могут происходить перед тем как пользователь получит доступ к той или иной службе. Например ведение записей в системных журналах.

* password:Модуль, как следует из названия, занимающийся непосредственно проверкой паролей на подлинность, на слабость и т.д.

 

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

 

* required: Удача этого модуля требуется для всей аутентификации в целом. Неудача модуля с подобным флагом не проявится для пользователя пока не выполнятся все оставшиеся модули.

* requisite:Тоже самое, но только в случае провала управление тут же будет возвращено приложению.

* sufficient:Удачное прохождение подобного модуля считается достаточным для признания всей аутентификации удачной если не провалилась проверка на предшествующих модулях с флагом required. Неудача же этого модуля не считается фатальной для всей последующей аутентификации.

* optional:Этот модуль не критичен для аутентификации и используется как дополнительный. То есть,например , может ограничиться выводом на экран предупреждением о слабости вашего пароля.

 

Путь-К-Модулю должен указывать полный адрес выбранного модуля на диске, а Параметры-Модуля зависят от выбора оного.

Помимо файлов-сценариев для некоторых модулей могут использоваться дополнительные файлы конфигурации. Все они расположены в каталоге /etc/security и каждый файл предназначен для конкретной группы настроек.

 

time.conf – Здесь вы сможете ограничить время доступа пользователей с различных терминалов к различным сервисам. Например, запретить входить в систему с первой виртуальной консоли администратору во время выходных. Эти настройки обслуживает модуль pam_time и, соответственно, если вы желаете, чтобы ваши ограничения возымели дествие модуль должен быть прописан в соответствующем сценарии.

 

pam_env.conf-А здесь вам под силу ограничить возможности в изменении отдельных переменных среды пользователями. Работает под руководством модуля pam_env.

 

limits.conf- Если вы злобный администратор или у вас недобросовестные пользователи, то этот файл для вас. Здесь вы можете индивидуально или для группы ограничить:размер core-файла, максимальный допустимый размер файла, максимальное количество открытых файлов, запущенных процессов, сколько раз можно одновременно зайти в систему и т.д. Руководящий модуль pam_limits.

 

access.conf-Так как PAM имеет средства аутентификации по сети, то подобные настройки являются полезными ибо контролируется не только кто может или не зайти, но и откуда. Контролируется pam_access.

 

group.conf- Можно указать какой группе будет принадлежать служба запущенная определенным пользователем, в определенное время с определенного терминала. Хозяева pam_time и pam_group.

 

console.perms-Несколько выбивается своим названием, но не функциями. Здесь определяются права, получаемые привилегированными пользователями к консоли во время входа в систему и возвращаемые при выходе. Модуль pam_console.

 

Итак, логика действий проста и понятна, осталось только разобраться какие могут быть модули.

* pam_cracklib:Тип password. Проверяет ваш пароль на стойкость, не является ли он, например, палиндромом (примечание- это не обязательно при использовании модуля pam_unix). Полезен для программ задающих пароли. Полезные параметры: retry=N -дается N попыток на исправление ошибки,diffok=N-должно быть измененено минимум N символов при смене пароля,minlen=N -минимальный размер пароля,dcredit=N ucredit=N lcredit=N ocredit=N – в пароле должно присутствовать минимум N цифр, строчных, прописных букв и других символов.

* pam_deny:Тип любой. Всегда перекрывает доступ.

* pam_env:Тип auth. Контролирует сохранность переменных среды. Полезный параметр conffile=S -задает альтернативное название файла конфигурации.

* pam_ftp:Тип auth. Предназначен для организации анонимного доступа. То есть получив имя пользователя ‘anonymous’, ждет в качестве пароля что-то похожее на его почтовый адрес. Полезные параметры: ignore- не обращать внимание похож ли пароль на почтовый адрес, users=XXX,YYY -позволяет анонимный вход для пользователей из этого списка.

* pam_group:Тип auth. предназначение ясно из описания конфигурационного файла group.conf.

* pam_lastlog:Тип auth. Сообщает о времени и месте входа в систему. Обновляет /var/log/wtmp файл.Полезные параметры: nodate,noterm,nohost,silent – не выводить в сообщении даты, терминала, машины или вообще ничего, never-если пользователь никогда ранее не появлялся, то его приветствуют.

* pam_limits:Тип session. Предназначение указано выше при описании файла limits.conf. Полезный параметр:conf=S -альтернативное имя конфиругационного файла.

* pam_listfile:Тип auth. Предназначен для организации доступа на основе конфигурационных файлов-списков например /etc/ftpaccess. Для примера смотрите соответствующие файлы сценариев. Возможные параметры: onerr=succeed|fail; sence=allow|deny; file=filename; item=user|tty|rhost|ruser|group|shell apply=user|@group . Первый параметр задает возвращаемое значение в случае неудачного поиска. Второй – в случае удачного поиска. Третий имя файла со списком. Четвертый- тип элемента в списке. Последний вносит дополнительный ограничения если тип объявлен tty, rhost или shell.

* pam_mail:Тип auth. Сообщается о наличии почты если таковая имеется. Полезные параметры:dir=S -путь к каталогу почтовых очередей, noenv-не устанавливать переменную среды MAIL,close -сообщать если есть почта у пользователей с аннулироваными бюджетами,nopen-не печатать какой либо почтовой информации если пользовательский бюджет только-что заведен.

* pam_nologin:Тип auth. Стандартная реакция на наличие файла /etc/nologin. Когда он присутствует, в систему может зайти только root, а остальным будет выдано на экран содержимое этого файла.

* pam_permit:Тип любой. Использование данного модуля ОПАСНО и применимо только в критических ситуациях. Всегда дает допуск.

* pam_pwdb:Тип любой. Замещает модули серии pam_unix…. . Использует интерфейс библиотеки libpwdb (пользовательские базы данных), что повышает независимость системы аутентификации от способа хранения пользовательских данных(NIS или passwd или shadow). Полезные параметры: nullok -можно использовать пустые пароли,md5,shadow,bigcrypt -различные способы шифрования пароля.

* pam_radius:Тип session. Позволяет осуществлять аутентификацию через RADIUS сервер.

* pam_rhosts_auth:Тип auth. Механизм работы этого модуля основывается на анализе содержимого файлов hosts.equiv и .rhosts используемых для аутентификации таких служб как rlogin и rsh. Полезные параметры:no_hosts_equiv -игнорировать содержимое файла hosts.equiv, no_rhosts-игнорировать содержимое файлов .rhosts ,suppress- охраняет системные журналы от потока малозначимых сообщений, в частности когда используется контрольный флаг sufficient.

* pam_root_ok:Тип auth. Используется в случае, когда администратору необходимо получать доступ к сервису без введения пароля. Этот модуль допускает пользователя к сервису только если его uid равен 0.

* pam_securetty: Влючает в проверку файл /etc/securitty. Суперпользователь сможет зайти полько на указанных там терминалах.

* pam_time:Тип account. Принцип работы думается ясен из описания устройства конфигурационного файла time.conf.

* pam_warn:Тип auth и password. Просто напросто ведет записи в системных журналах например при смене пароля.

* pam_weel:Тип auth. Для любителей BSD, где получить права суперпользователя может только пользователь группы wheel (группа root в Linux). Полезные параметры:group=XXX-использовать указанную группу вместо стандартной нулевой,deny- инвертирование действия алгоритма, запрещается получать права суперпользователя пользователям указанной группы, используется вместе с предыдущим параметром, trust -избавляет пользователей группы wheel от необходимости вводить пароль при смене uid на 0.

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

3. Выводы.

Не правда ли PAM это здорово… :))