pam linux что это

Pam linux что это

Pluggable Authentication Modules (PAM)

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

Большинство пользователей Red Hat Linux никогда не нуждаются в изменении конфигурационных PAM файлов их программ. Когда вы используете RPM для установки программ, требующих аутентификации, они автоматически вносят необходимые для нормальной работы изменения. Однако, если вам понадобится изменить вашу конфигурацию, вы должны понимать стуктуру конфигурационного файла PAM. Больше информации вы можете найти в разделе «модули PAM».

Преимущества PAM

Конфигурационные файлы PAM.

Каталог /etc/pam.d содержит в себе конфигурационные файлы PAM. В ранних версиях PAM использовался файл pam.conf. Этот файл будет использоваться если не было найдено каталога /etc/pam.d, однако его использование нежелательно.

Каждое приложение (или сервис, используемый многими пользователями) имеет собственный файл. Каждый файл имеет пять разных элементов: имя сервиса, тип модуля, флаги управления, путь к модулю и аргументы.

Имена сервисов PAM.

Модули PAM.

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

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

Прежде, чем кто-либо получит доступ к xlogin, PAM проверит отсутствие /etc/nologin, что это не попытка удаленной регистрации под root, и что ни одной переменной окружения не может быть загружено. Затем необходимо успешное выполнение аутентификации xhosts, для того, чтобы позволить установить соединение. Если аутентификация xhosts завершается неудачей, то выполняется стандартная password аутентификация.

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

Документацию касательно написания модулей вы можете найти в /usr/share/doc/pam?(version-number).

Флаги управления PAM.

Каждый модуль PAM возвращает результат успешного выполнения или неудачи. Флаги управления говорят PAM, что нужно делать с результатом. Когда модули расположены в определенной последовательности, флаги дают вам возможность установить «важность» модуля по отношению к следующему за ним.

Вернемся к нашему конфигурационному файлу PAM для xlogin:

Четыре типа флагов, стандартных для PAM.

В настоящий момент в PAM доступны новые флаги управления. Смотрите документацию PAM в /usr/share/doc/pam?(version-number) для получения информации.

Пути к PAM модулям.

Пути к модулям говорят PAM, где искать подключаемый модуль. Обычно, это представляет собой полный путь к модулю, такой как /lib/security/pam_stack.so. Если путь к модулю не будет указан (или он начинается не с ‘/’, то по-умолчанию считается, что модуль расположен в /lib/security.

Аргументы PAM.

PAM использует аргументы для передачи информации подключаемому модулю во время аутентификации. Аргументы позволяют в различных конфигурационных файлах PAM использовать модули по-разному.

Например, модуль pam_userdb.so использует информацию хранящуюся в файле Berkeley DB для аутентификации пользователя. Этому модулю нужно передать аргумент, определяющий имя используемого файла, который у каждого сервиса свой.

Таким образом, строка pam_userdb.so будет выглядеть следующим образом:

Неправильные аргументы будут проигнорированы и модуль не вернет никакого результата. Когда встречается неверный аргумент, ошибка обычно фиксируется в /var/log/mesages.

Примеры конфигурационного файла PAM.

Конфигурационный PAM файл приложения может выглядеть так:

Вторая строка проверяет наличие терминала с которого производится попытка а аутентификации в файле /etc/securetty, если таковой существует, в случае root логина. Если tty не указан в файле, то аутентификация не будет разрешена.

Третья строка запрашивает у пользователя пароль и проверяет его.

Четвертая строка проверяет наличие файла /etc/nologin. Если файл существует и пользоваетль не является root, аутентификация завершится неудачей.

Заметьте, что все три auth модуля будут обрабатываться одниаково, независимо от того, проход какого модуля завершится неудачей. Такая стратегия не позволяет узнать пользователю какой именно этап аутентификации он не прошел. Знание причин провала аутентификации может стать причиной обхода пользователем этого этапа в следующий раз. Вы можете изменить такое поведение системы, заменив required модуль на requisite. Если какой либо requisite модуль не будет пройден, PAM остановится немедленно и вернет результат неудачи. Остальные существующие модули при этом проверяться не будут.

Пятая строка производит необходимые проверки аккаунта. Например, если включены теневые пароли, модуль pam_unix.so проверяет время действия аккаунта или своевременную смену пароля пользователем.

Шестая строка проверяет, не могут ли измененные пароли быть взломаны при помощи программ перебирающих по словарю.

Восьмая, и последняя строка определяет, что модуль pam_unix.so будет управлять сеансом (сессией). В данный момент этот модуль ничего не делает; он должен быть заменен на необходимый модуль или дополнен stack’ингом (поправьте меня, кто может).

Обратите внимание на порядок строк в файле. Порядок вызова required модулей не имеет значения, доступны другие флаги управления. Использование в файле optional модулей обуславливает важность порядка выполнения модулей sufficient и requisite.

В качестве следующегь примера рассмотрим конфигурационный файл для rlogin:

Первое. Если существует файл /etc/nologin, никто кроме root не сможет зарегистрироваться в системе.

Второе. pam_securetty.so предотвращает регистрацию root с ненадежных терминалов. Неплохо было бы запретить логиниться root’у при помощи rlogin. Если вы желаете иметь такую возможность (в этом случае вы должны иметь хороший firewall или быть отключенным от интернета), смотрите документацию rlogin.

Третье. Модуль pam_env.so загружает переменные окружения, описанные в /etc/security/pam_env.conf.

Пятое. Если pam_rhosts_auth.so не был пройден, pam_stack.so с аргументом service=system-auth производит стандартную password аутентификацию.

NOTE:
Если вы не хотите запрашивать пароль в случае неудачной проверки securetty и определения попытки установления удаленного соединения, вы можете сменить pam_securetty.so с required на requisite. Как вариант, вы можете пожелать разрешить удаленные root регистрации, но это не является хорошей идеей.

Источник:
Red Hat Linux 7.1: The Official Red Hat Linux Reference Guide
Перевод:
Александр Шепетко

Источник

Подключаемые Модули Аутентификации (PAM)

FreeBSD это зарегистрированная торговая марка FreeBSD Foundation.

This article was written for the FreeBSD Project by ThinkSec AS and Network Associates Laboratories, the Security Research Division of Network Associates, Inc. under DARPA/SPAWAR contract N66001-01-C-8035 (“CBOSS”), as part of the DARPA CHATS research program.

Linux это зарегистрированная торговая марка Linus Torvalds.

Motif, OSF/1 и UNIX это зарегистрированные торговые марки, а IT DialTone и The Open Group это торговые марки Open Group в Соединенных Штатах и других странах.

Sun, Sun Microsystems, Java, Java Virtual Machine, JDK, JRE, JSP, JVM, Netra, Solaris, StarOffice, SunOS это торговые марки или зарегистрированные торговые марки Sun Microsystems, Inc. в Соединенных Штатах и других странах.

Многие из обозначений, используемые производителями и продавцами для обозначения своих продуктов, заявляются в качестве торговых марок. Когда такие обозначения появляются в этом документе, и Проекту FreeBSD известно о торговой марке, к обозначению добавляется знак “™” или “®”.

Table of Contents

1. Введение

Библиотека Pluggable Authentication Modules (PAM) является обобщённым API для служб, связанных с аутентификацией, которые позволяют системному администратору добавлять новые методы аутентификации простой установкой новых модулей PAM, и изменять политику аутентификации посредством редактирования конфигурационных файлов.

PAM описали и разработали Vipin Samar и Charlie Lai из Sun Microsystems в 1995 году, с тех он сильно не менялся. В 1997 году Open Group опубликовала предварительные спецификации на X/Open Single Sign-on (XSSO), что стандартизовало API для PAM и добавило расширения для одноразовой (или достаточно интегрированной) подписи. На момент написания этого документа эта спецификация ещё не была принята за стандарт.

Хотя эта статья посвящена в основном FreeBSD 5.x, в которой используется OpenPAM, она подойдёт для FreeBSD 4.x, использующей Linux-PAM, и других операционных систем, таких, как Linux и Solaris™.

2. Термины и соглашения

3. Определения

Терминология, используемая в PAM, достаточно запутана. Ни оригинальная работа Samar и Lai, ни спецификация XSSO не делают никаких попыток формально определить термины для различных объектов и участвующих в PAM сторон, а термины, которые они используют (но не определяют) иногда неверны и неоднозначны. Первой попыткой создать недвусмысленную и согласованную терминологию была работа, которую написал Andrew G. Morgan (автор Linux-PAM) в 1999 году. Хотя выбор терминологии, которую сделал Морган, был гигантским скачком вперед, это, по мнению автора данной статьи, не означает ее правильность. Далее делается попытка, в значительной степени на основе работы Моргана, дать точные и недвусмысленные определения терминов для всех участников и объектов PAM.

Набор полномочий, которые аппликант запрашивает от арбитратора.

Пользователь или объект, запрашивающие аутентификацию.

Пользователь или объект, имеющий привилегии, достаточные для проверки полномочий аппликанта и права подтвердить или отклонить запрос.

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

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

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

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

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

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

Класс серверов, предоставляющих похожую или связанную функциональность, и требующую подобную аутентификацию. Политики PAM задаются на основе сервисов, так что ко всем серверам, объявляющим одно и тоже имя сервиса, будет применяться одна и та же политика.

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

Блок информации, связанный с учётной записью, например, пароль или ключевая фраза, которую аппликант должен предоставить для своей идентификации.

Последовательность запросов от одного и того же аппликанта к одному и тому же экземпляру того же самого сервера, начиная с аутентификации и установления сеанса и заканчивая закрытием сеанса.

4. Примеры использования

Этот раздел предназначен для иллюстрации значений некоторых терминов, определенных выше, при помощи простых примеров.

5. Объединенные клиент и сервер

Процесс su(1) является как клиентом, так и сервером.

6. Клиент и сервер разделены

Клиентом является процесс ssh(1) пользователя Eve.

Сервером является процесс sshd(8) на машине login.example.com

7. Пример политики

Следующее является политикой, используемой во FreeBSD по умолчанию для sshd :

Эта политика применяется к службе sshd (что не обязательно ограничено сервером sshd(8)).

8. Основы PAM

9. Подсистемы и примитивы

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

Аутентификация. Эта подсистема, собственно говоря, реализует аутентификацию аппликанта и выяснение полномочий учётной записи. Она предоставляет два примитива:

Функция pam_authenticate(3) аутентифицирует аппликанта, обычно запрашивая аутентификационный ключ и сравнивая его со значением, хранящимся в базе данных или получаемым от сервера аутентификации.

Функция pam_setcred(3) устанавливает полномочия учётной записи, такие, как идентификатор пользователя, членство в группах и ограничения на использование ресурсов.

Управление учётной записью. Эта подсистема обрабатывает вопросы доступности учетной записи, не связанные с аутентификацией, такие, как ограничения в доступе на основе времени суток или загрузки сервера. Он предоставляет единственный примитив:

Функция pam_acct_mgmt(3) проверяет, доступна ли запрашиваемая учётная запись.

Управление сеансом. Эта подсистема отрабатывает задачи, связанные с установлением и закрытием сеанса, такие, как учет входов пользователей. Она предоставляет два примитива:

Управление паролем. Эта подсистема используется для изменения ключа аутентификации, связанного с учетной записью, по причине истечения его срока действия или желания пользователя изменить его. Она предоставляет единственный примитив:

Функция pam_chauthtok(3) изменяет ключ аутентификации, опционально проверяя, что он труден для подбора, не использовался ранее и так далее.

10. Модули

Модули являются центральной концепцией в PAM; в конце концов, им соответствует буква «M» в сокращении «PAM». Модуль PAM представляет собой самодостаточный кусок программного кода, который реализует примитивы одной или большего количества подсистем одного конкретного механизма; к возможным механизмам для подсистемы аутентификации, к примеру, относятся базы данных паролей UNIX®, системы NIS, LDAP или Radius.

11. Именование модулей

12. Версии модулей

Изначальная реализация PAM во FreeBSD, которая была основана на Linux-PAM, не использовала номера версий для модулей PAM. Это будет приводить к проблемам при работе унаследованных приложений, которые могут быть скомпонованы со старыми версиями системных библиотек, так как способа подгрузить соответствующую версию требуемых модулей нет.

OpenPAM, с другой стороны, ищет модули, которые имеют тот же самый номер версии, что и библиотека PAM (на данный момент 2), и использует модуль без версии, только если модуль с известной версией не был загружен. Поэтому для старых приложений могут предоставляться старые модули, при этом новые (или заново построенные) приложения будут использовать все возможности последних версий модулей.

Хотя модули PAM в Solaris™ имеют номер версии, по-настоящему номер версии в них не отслеживается, потому что номер является частью имени и должен включаться в конфигурацию.

13. Цепочки и политики

Когда сервер инициирует PAM-транзакцию, библиотека PAM пытается загрузить политику для службы, указанной при вызове функции pam_start(3). Политика определяет, как должны обрабатываться запросы на аутентификацию, и задаётся в конфигурационном файле. Это составляет другую основополагающую концепцию PAM: возможность администратору настраивать политику безопасности системы (в самом широком её понимании) простым редактированием текстового файла.

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

Понимание смысла управляющего флага необходимо для понимания конфигурационных файлов PAM. Существуют четыре различных управляющих флага:

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

Этот управляющий флаг был добавлен компанией Sun в Solaris™ 9 (SunOS™ 5.9), и поддерживается в OpenPAM.

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

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

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

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

14. Транзакции

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

Сервер вызывает функцию pam_start(3) для инициализации библиотеки PAM и задания имени сервиса и целевой учётной записи, а также регистрации подходящего способа общения.

Сервер получает различную информацию, относящуюся к транзакции (такую, как имя пользователя аппликанта и имя хоста, на котором запущен клиент), и отправляет её в PAM при помощи функции pam_set_item(3).

Сервер вызывает функцию pam_authenticate(3) для аутентификации аппликанта.

Теперь, когда аппликант полностью аутентифицирован, сервер вызывает функцию pam_setcred(3) для получения полномочий запрошенной учётной записи. Сделать это возможно, потому что он работает как арбитратор, и оставляет за собой полномочия арбитратора.

После получения необходимых полномочий, сервер вызывает функцию pam_open_session(3) для установления сеанса.

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

После того, как сервер закончил обслуживание клиента, он вызывает функцию pam_close_session(3) для закрытия сеанса.

Наконец, сервер вызывает функцию pam_end(3) для оповещения библиотеки PAM о том, что работа с ней завершена и какие-либо выделенные в течение сеанса ресурсы можно освободить.

Источник

PAM на страже ваших компьютеров

Давайте начнем с самого начала и рассмотрим, как программа аутентифицирует пользователя. Если не будет единого базового механизма аутентификации, тогда каждая программа должна содержать в себе логику аутентификации, такую как просмотр файла /etc/passwd на наличие пользователя и соответствия введенного пароля. Но что если таких программ много? Придется включать одну и ту же логику в каждую из них? А если требования к безопасности изменятся? Что, придется модифицировать и перекомпилировать все эти программы? Очевидно, это плохой метод и наверняка не самый безопасный. Как бы сделать так, чтобы все приложения сразу обновлялись до требуемого метода аутентификации и удовлетворяли новым требованиям безопасности?

Проект PAM предоставляет решение путем добавления дополнительного программного уровня. Программа, которой требуется аутентификация, должна использовать стандартную библиотеку или API (Application Programming Interface, Прикладной программный интерфейс), а системный администратор должен указать порядок аутентификации для данной конкретной программы (проверки осуществляются отдельными модулями; можно даже запрограммировать собственные модули). Таким образом, можно динамически изменять требования безопасности, причем все программы будут автоматически следовать вашим новым указаниям. Другими словами, можно модифицировать механизмы аутентификации программ (которые собраны с поддержкой PAM) без пересборки самих программ. С точки зрения программиста это очень хороший подход, ведь ему не требуется связываться с механизмами аутентификации. Когда мы используем модули PAM, требуемые проверки выполняются автоматически (см. рисунок 1).

Библиотека PAM разбивает механизм аутентификации на четыре группы (см. таблицу 1). Обратите внимание, что не всем программам требуются все четыре действия. К примеру, команде passwd требуется лишь последняя группа. Подсказка: как определить, использует ли программа PAM? Нужно вывести с помощью утилиты ldd все разделяемые библиотеки, используемые данной программой, и найти среди них libpam.so; пример см. в листинге 1.

Рисунок 1. Когда программа делает запрос аутентификации, библиотека PAM исполняет код модулей, указанных в конфигурационном файле и принимает решение, принять (успех) или отклонить (неудача) этот запрос.

Листинг 1. Чтобы узнать, использует ли программа PAM, воспользуйтесь утилитой ldd и найдите в ее выводе библиотеку libpam.so. Нужно писать полный путь до исполняемого файла. Если не знаете полный путь, узнайте его с помощью команды whereis. Например:

Таблица 1. Проверки PAM подразделяются на четыре группы, организованных в виде очереди. Задействование тех или иных групп определяется запросами пользователя.

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

Настройка PAM

Для каждой службы (такой как login или SSH), необходимо указать, какие проверки будут сделаны в каждой группе. Список этих действий называется стеком. В завимости от результата исполнения в каждом стеке, пользователю будет разрешен или отклонен доступ, либо что-то будет позволено или не позволено. Исполняемые действия задаются для каждой службы в отдельном файле в каталоге /etc/pam.d (новый метод), либо в едином файле /etc/pam.conf (старый метод). В данной статье рассмотрен первый, новый метод.

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

Каждый стек состоит из модулей, выполняющихся последовательно в заданном порядке. Для каждого модуля нужно указать, является ли он обязательным (неудача автоматически запрещает доступ), достаточным (успех автоматически разрешает доступ) либо желательным (проводит альтернативные проверки). В таблице 2 расписаны эти управляющие флаги. Файл конфигурации каждой службы состоит из списка правил, каждое начинается с новой строки (длинные строки можно разбивать с помощью символа \, но это требуется крайне редко). Строки, начинающиеся с символа решетки (#), являются комментариями и поэтому игнорируются. Каждое правило состоит из трех полей: контекст (таблица 1), управляющие флаги (таблица 2) и модуль, который требуется исполнить, с дополнительными (необязательными) параметрами. К примеру, спецификации PAM-проверок для программы login можно найти в файле /etc/pam.d/login.

Рекомендую провести беглый осмотр всех файлов в /etc/pam.d. Если найдете файлы неиспользуемых приложений, просто переименуйте их, и PAM задействует стандартную конфигурацию «other». Если позже программа понадобится, переименуйте соответствующий конфигурационный файл обратно, и все встанет на свои места.

Листинг 2. Безопасные правила «other» отклоняют все запросы доступа к службе, для которой не указаны другие правила. Модуль pam_deny.so всегда завершается неудачей, поэтому все попытки получения доступа будут отклонены, вдобавок к этому модуль pam_warn.so отправит системному администратору уведомление об этом событии.

Листинг 3. Правила PAM, эквивалентные стандартным правилам безопасности UNIX. Замечание: в некоторых дистрибутивах нужно указывать модуль pam_unix.so.

Листинг 4. Файл /etc/pam.d/sshd содержит правила безопасности для SSH-соединений. Обратите внимание, что модуль pam_access.so добавляет дополнительные проверки (см. листинг 5).

Листинг 5. Файл /etc/security/access.conf используется модулем pam_access.so, чтобы определить, каким пользователям позволено входить в систему и с каких IP-адресов. В данном примере, в систему теоретически может войти любой пользователь локальной сети, но лишь пользователю remoteKereki позволен удаленный доступ извне.

Листинг 6. Секция password в файле /etc/pam.d/passwd определяет хорошие требования, предъявляемые к новым паролям.

Безопасный удаленный доступ

Если вы взглянете на файл /etc/pam.d/sshd, который установлен в вашей системе, вы наверняка увидите то же самое, только не будет модуля pam_access. Он и представляет здесь наибольший интерес. Этот модуль обеспечивает дополнительные проверки, определяемые файлом /etc/security/access.conf. В нем я указал тех, кто может получать доступ к моему компьютеру (листинг 5). Первая строка определяет, что войти в систему может любой пользователь (ALL) из внутренней домашней сети. Вторая строка означает, что пользователь remoteKereki может войти в систему из любой точки мира, а последняя строка однозначно завершает политику доступа, запрещая доступ всем, кто не указан в предыдущих строках. Я создал пользователя remoteKereki с минимумом прав, чтобы я сам мог войти в систему, затем, выполнив su, стать собственно собой или пользователем root, если потребуется. Если злоумышленник угадает пароль для remoteKereki, это ему не поможет, ведь атакующему придется еще угадывать пароль для других, более полезных пользователей. Таким образом, пользователь remoteKereki является дополнительным барьером для злоумышленников.

Нужны хорошие пароли

Можно вызвать модуль с параметрами (их полный перечень смотри в man pam_pwcheck), которые описывают дополнительные правила:

Сходную функциональность предоставляет другой модуль, под названием pam_cracklib.so, однако у него другие параметры. К примеру, в нем можно указать, в скольких символах должны отличаться старый и новый пароли, нужно ли включать цифры, символы в верхнем и нижнем регистрах, а также неалфавитные символы. Более подробную информацию можно найти в руководстве man pam_cracklib.

Заключение

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

Модули, модули кругом

Источники информации

Источник