4.1.1.3Модули pam

Один из недостатков файла теневых паролей заключается в том, что все прило­жения, так или иначе работающие с паролями, должны быть (заново) скомпили­рованы с поддержкой теневых паролей, иначе они будут неработоспособны. Од­нако компания Sun предложила решение этой проблемы, впервые появившееся в операционной системе Solaris 2.3, которое затем было адаптировано и для Linux. Система называется РАМ (Pluggable Authentication Modules) и состоит из моду­лей и библиотек. Приложению, компонованному с использованием этих библио­тек, не нужно подстраиваться под систему авторизации, используемую в системе в данный момент, так как РАМ берет все эти вопросы на себя. Такой подход дела­ет систему намного более гибкой.

Основная идея РАМ состоит в том, что всегда можно написать новый модуль безопасности, который бы обращался к файлу или устройству за информацией и возвращал результат выполнения процедуры авторизации: УСПЕХ (SUCCESS), НЕУДАЧА (FAILURE) или ИГНОРИРОВАТЬ (IGNORE). А РАМ, в свою оче­редь, возвратит УСПЕХ (SUCCESS) или НЕУДАЧА (FAILURE) вызвавшей ее :лужбе. Таким образом, неважно, какие пароли, теневые или обычные, использу­ются в системе, раз в ней есть РАМ: все поддерживающие РАМ программы будут прекрасно работать и с теми и другими. Более того, можно сравнительно легко добавлять и другие механизмы авторизации. Модули можно комбиниро­вать – например, так, чтобы для успешной авторизации требовалось прохождение нескольких процедур авторизации или же чтобы было достаточно прохождения любой из них. Тем самым можно создавать достаточно сложные системы автори­зации: пароль, дополняемый сканированием сетчатки глаза, или же смарт-карта и распознавание голоса и т. д.

Файл конфигурации состоит из четырех столбцов.

#%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

Последний столбец является необязательным и предназначен для передачи в модуль допол­нительных параметров. Строки, начинающиеся с символа решетки (#), игнорируются. Использование нескольких строк с одинаковым первым полем называется накоплением (stacking). Содержимое всех столбцов рассматривается без учета регистра.

Первый столбец является столбцом типа. Тип определяется одной из четырех символьных меток: auth, account, session и password.

• Тип auth (authentication — аутентификация) используется для выяснения, яв­ляется ли пользователь тем, за кого он себя выдает. Как правило, это достига­ется сравнением введенного и хранимого паролей, но возможны и другие вари­анты. Например, при помощи смарт-карты или каким-либо иным способом, для которого имеется соответствующий модуль.

• Тип account (учетная запись) проверяет, дозволено ли использовать службу данному пользователю, на каких условиях, не устарел ли пароль и т. д.

• Тип password (пароль) используется для обновления маркеров авторизации. Например, если согласно полю устаревания пароля из файла /etc/shadow не­обходима принудительная смена пароля, модуль passwd запустит chauthok (из­менение маркера авторизации) и, если смена пароля пройдет успешно, вернет значение УСПЕХ (SUCCESS).

• Тип session (сеанс) выполняет определенные действия при входе пользовате­ля в систему и при выходе пользователя из системы. Таковыми могут быть например, монтирование и демонтирование каталогов, подготовка пользова­тельского окружения и т. д.

Второй столбец является полем управляющего флага, определяющим, что делать после возврата из модуля, то есть реакцию РАМ на значения УСПЕХ (SUCCESS) ИГНОРИРОВАТЬ (IGNORE) и НЕУДАЧА (FAILURE). Разрешенные значения: requisite, required, sufficient и optional. От значения в этом поле зависит, будут ли обработаны остальные строки файла. Например, если модуль, помеченный как sufficient (достаточный), вернет значение УСПЕХ (SUCCESS), то работа РАМ на нем успешно закончится и пользователь будет допущен в систему. Аналогичным образом возврат НЕУДАЧА (FAILURE) модулем, помеченным как requisite (обязательный), означает прекращение авторизации и возврат значения НЕУДАЧА (FAILURE). И в том и в другом случае остальные строки обрабатываться не будут.

• Флаг requisite (обязательный) задает наиболее жесткое поведение. Обработка любой строки с флагом requisite, модуль которой вернул значение НЕУДАЧА (FAILURE), будет прекращена и вызвавшей ее службе будет возвращен статус НЕУДАЧА (FAILURE). Никакие другие строки рассматриваться не будут. Этот флаг используется достаточно редко. Дело в том, что если помеченный им модуль выполняется самым первым, то следующие за ни модули могут и не выполниться, в том числе и отвечающие за протоколирование, поэтому вместо него обычно применяется флаг required (необходимый).

• Флаг required (необходимый) не прерывает выполнение модулей. Каков бы ни был результат выполнения помеченного им модуля: УСПЕХ (SUCCESS), ИГНО­РИРОВАТЬ (IGNORE) или НЕУДАЧА (FAILURE), РАМ всегда переходит к обработке следующего модуля. Это наиболее часто используемый флаг, так как результат выполнения модуля не возвращается до тех пор, пока не отработают все остальные модули, а значит, модули, отвечающие за протоколирование, обя­зательно выполнятся.

• Флаг sufficient (достаточный) приводит к немедленному завершению обработ­ки строки и возврату значения УСПЕХ (SUCCESS) при условии, что помечен­ный им модуль вернул значение УСПЕХ (SUCCESS) и ранее не встречалось модуля с флагом required, вернувшего статус НЕУДАЧА (FAILURE). Если такой модуль встречался, то флаг sufficient игнорируется. Если помеченный этим флагом модуль возвратил значение ИГНОРИРОВАТЬ (IGNORE) или НЕУДАЧА (FAILURE), то флаг sufficient рассматривается аналогично флагу optional.

• Результат выполнения модуля с флагом optional (необязательный) принима­ется во внимание лишь тогда, когда он является единственным модулем в сте­ке, вернувшим значение УСПЕХ (SUCCESS). В противном случае результат его выполнения игнорируется. Таким образом, неуспешное выполнение по­меченного им модуля не влечет за собой неуспех всего процесса авторизации.

Чтобы пользователь смог получить доступ к системе, модули, помеченные фла­гами requisite и required, не должны возвращать значения НЕУДАЧА (FAILURE). Результат выполнения модуля с флагом optional принимается в рас­смотрение, лишь если он является единственным модулем в стеке, вернувшим УСПЕХ (SUCCESS).

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

Четвертый столбец предназначен для передачи в модуль дополнительных па­раметров. Не у всех модулей есть параметры, а если есть, то они могут и не ис­пользоваться. Передача параметра модулю позволяет изменить его поведение тем или иным образом.