linux pam что такое
Настройка PAM в Linux
Этот механизм появился примерно в 1997 году и с тех пор дошёл до нашего времени практически неизменным. Конечно, были дописаны новые модули, но суть работы осталась такая же как изначально. В этой статье мы рассмотрим как выполняется настройка PAM в Linux.
Как работает PAM в Linux?
Теперь рассмотрим как выполняется настройка PAM Linux.
Как настроить PAM в Linux
Все конфигурационные файлы PAM для различных приложений находятся в папке /etc/pam.d. Давайте посмотрим на конфигурационный файл для утилиты sudo:
Каждая строчка файла состоит из нескольких полей:
тип обязательность модуль параметры
Кроме того, существуют директивы include, которые включают строки из других файлов так, как будто они были написаны в этом файле. Файл настройки sudo кажется совсем коротким, но в него включаются другие файлы. Давайте посмотрим ещё на файл /etc/pam.d/common-auth:
Здесь можно видеть более расширенный синтаксис параметра обязательности. Он позволяет лучше понять как всё это работает. Давайте его рассмотрим:
[значение1 = действие1 значение2 = действие2 …]
Модули PAM могут возвращать около 30-ти значений и они зависят от выбранного типа (account/auth/session. ), вот они все: success, open_err, symbol_err, service_err, system_err, buf_err, perm_denied, auth_err, cred_insufficient, authinfo_unavail, user_unknown, maxtries, new_authtok_reqd, acct_expired, session_err, cred_unavail, cred_expired, cred_err, no_module_data, conv_err, authtok_err, authtok_recover_err, authtok_lock_busy, authtok_disable_aging, try_again, ignore, abort, authtok_expired, module_unknown, bad_item, conv_again, incomplete и default. Последнее, default, означает все поля, которые явно не заданы.
В качестве действия могут быть указанны такие значения:
Таким образом, те четыре варианта обязательности, которые мы рассматривали выше можно описать вот так:
Обратите внимание. что модуль возвращает только одно определенное значение и уже к нему применяется действие.
Чтобы закрепить всё это на практике давайте рассмотрим как запретить авторизацию от имени пользователя losst на компьютере с помощью PAM. Для этого можно воспользоваться модулем /lib/security/pam_listfile.so. Он позволяет ограничить доступ для пользователей на основе файла со списком. Откройте файл /etc/pam.d/sshd и добавьте туда такую строчку:
sudo vi /etc/pam.d/sshd
auth required pam_listfile.so \
onerr=succeed item=user sense=deny file=/etc/denyusers
Здесь мы используем тип запроса auth, обязательность required и указанный выше модуль. Вот его опции и их значения:
Теперь в файл /etc/denyusers добавьте имя пользователя losst, естественно, такой пользователь должен существовать в системе. Затем попробуйте перейти в любую консоль и авторизоваться от его имени. У вас ничего не выйдет, а в логе /var/log/security или /var/log/auth.log будет сообщение об ошибке:
А если эту строчку закомментировать, то всё снова заработает.
Выводы
В этой статье мы рассмотрели как настроить PAM Linux, как видите, это очень гибкая система, но будьте осторожны. Любая неверная настройка может отнять у вас доступ к собственной системе!
Разработка и применение модуля PAM для аутентификации в Astra Linux с использованием Рутокен ЭЦП и Рутокен S
В этой статье мне бы хотелось рассказать о том, как приложения в Linux могут использовать систему Подключаемых Модулей Безопасности (Pluggable Authentication Modules) для прозрачной аутентификации пользователей. Мы немного покопаемся в истории развития механизмов аутентификации в Linux, разберемся с системой настроек PAM и разберем исходный код модуля аутентификации pam_p11, который позволяет проводить аутентификацию пользователей по смарт-картам.
В конце статьи мы рассмотрим на практике настройку и работу модуля аутентификации в сертифицированном по 3 классу защищенности СВТ и 2 уровню контроля отсутствия недекларированных возможностей дистрибутиве Astra Linux для аутентификации по USB-токенам Рутокен ЭЦП и Рутокен S. Учитывая то, что Рутокен S имеет сертификаты ФСТЭК по НДВ 3, а Рутокен ЭЦП по НДВ 4, это решение может применяться в информационных системах, обрабатывающих конфиденциальную информацию, вплоть до информации с грифом «С».
Немного истории
Структура PAM
Конфигурация PAM
Если приложению требуется аутентификация, то оно должно создать файл со своим именем в каталоге /etc/pam.d, в котором должны быть указаны модули, с помощью которых производится аутентификация и прочие действия. Посмотрим, что лежит в каталоге /etc/pam.d в Ubuntu 11.10
Для примера, посмотрим на абстрактный файл конфигурации для приложения login
Каждая строчка конфига записывается в виде
Разработка модуля аутентификации для PAM
В этом разделе мы разберем исходный код модуля pam_p11 и рассмотрим основные моменты, которым стоит уделить внимание при написании своего собственного модуля.
pam_p11
Собственно разработка модуля
Эти константы необходимы, чтобы PAM знал, что наш модуль может выполнять все функции, описанные выше. Конечно, если мы реализуем только аутентификацию, то остальные функции можно отбросить, но разработчики pam_p11 решили, что надежнее будет поставить заглушки вместо неиспользуемых функций.
Приступим к написанию функции pam_sm_authenticate. Она имеет следующую сигнатуру:
Затем проверим, передали ли нам путь к библиотеке PKCS#11
После чего инициализируем OpenSSL и контекст PKCS#11
Запросим у PAM имя пользователя
Теперь загрузим библиотеку PKCS#11, найдем первый доступный токен и получим с него сертификаты
Теперь среди сертификатов на токене найдем тот, что лежит у нас в
А сейчас самое интересное – нам нужно запросить через PAM пароль пользователя (который в нашем случае будет PIN-кодом к токену), а затем выполнить аутентификацию на токене
Теперь мы можем выполнить аутентификацию на токене:
На этом завершается первый этап аутентификации. Теперь нам нужно проверить, обладает ли владелец токена закрытым ключом. Для этого вычислим ЭЦП для произвольного блока данных и проверим ее с помощью доверенного сертификата.
Для начала считаем 128 байт из /dev/random
Затем получим закрытый ключ, соответствующий сертификату и подпишем на нем случайные данные
Проверим подпись. Для этого сначала средствами OpenSSL получим открытый ключ из сертификата, а затем выполним проверку ЭЦП
Если проверка подписи прошла успешно, то мы можем завершить работу с библиотекой PKCS#11 и вернуть PAM_SUCCESS.
Вместо остальных функций оставим никому не интересные заглушки, соберем модуль и приступим к его настройке и использованию.
Практическое использование
Установка дополнительных пакетов
Для Рутокен S
Для Рутокен ЭЦП
Модуль PAM и его зависимости
Настройка pam_p11
К счастью, нам не почти не придется править конфиги руками. Достаточно только создать файл /usr/share/pam-configs/p11 со следующим содержанием:
Интерес предоставляет последняя строчка конфига, в которой мы указываем тип модуля, имя библиотеки и параметры, передаваемые модулю. Наш модуль принимает в качестве параметра путь к библиотеке PKCS#11.
Теперь нам осталось только выполнить команду
В появившемся диалоге необходимо выбрать pam_p11. Если вы хотите отключить аутентификацию по паролям, то можно отключить Unix authentication. Поскольку в конфигурационном файле профиля было указано, что модуль будет «sufficient», то при получении от нашего модуля ответа «PAM_SUCCESS» весь процесс аутентификации будет считаться успешным.
Создание ключа и сертификата
Для начала создаем ключевую пару RSA длины 2048 бит c ID «45» (id стоит запомнить, он понадобится при создании сертификата).
Проверим сгенерированный ключ:
Теперь с помощью OpenSSL создадим самоподписанный сертификат. Запускаем openssl и подгружаем модуль поддержки pkcs11:
Создаем сертификат в PEM-формате:
Занесение сертификата в список доверенных
На данном этапе нам осталось только прочитать с токена сертификат с нужным ID и записать его в файл доверенных сертификатов:
Немного обо всем и все о немногом, или практический опыт системного администратора.
| Пн | Вт | Ср | Чт | Пт | Сб | Вс |
|---|---|---|---|---|---|---|
| « Фев | Апр » | |||||
| 1 | 2 | 3 | 4 | 5 | 6 | 7 |
| 8 | 9 | 10 | 11 | 12 | 13 | 14 |
| 15 | 16 | 17 | 18 | 19 | 20 | 21 |
| 22 | 23 | 24 | 25 | 26 | 27 | 28 |
| 29 | 30 | 31 | ||||
Все эти действия или процедуры (функции) реализованы в виде отдельных модулей, которые расположены в каталоге /lib/security/. То есть можно сказать, есть модули группы auth, модули группы account и т.д. Соответственно система PAM является модульной и если вам необходимо реализовать биометрическую аутентификацию, то необходимо просто установить модуль, которых может это процедуру выполнить.
Реакция может быть четырех типов: required, requisite, optional, sufficient. На примере строки auth sufficient pam_rootok.so рассмотрим, что означают эти значения.
Если во втором поле установлено значение requisite, то это означает, что если модуль pam_rootok.so завершился с ошибкой, то дальнейшее выполнение файла testpam прерывается и система PAM возвращает приложению ошибку. Если модуль вернул положительные результат, то выполнение цепочки продолжается.
required похож на requisite. Если модуль pam_rootok.so завершился с ошибкой, то PAM также вернет, ошибку, но после того как будут выполнены остальные модули, то есть цепочка не прерывается. Если модуль вернул положительные результат, то выполнение цепочки продолжается.
Более подробно о системе PAM и назначении той или иной библиотеки можно прочитать на сайте http://kernel.org/pub/linux/libs/pam/Linux-PAM-html/Linux-PAM_SAG.html. Сейчас выполним небольшое практическое упражнение которое позволить лучше понять как работает система PAM и как составлять конфигурационные файлы.
Перейдите в каталог /etc/pam.d/. Скопируйте файл su в домашнюю директорию (чтобы можно было восстановить его) и удалите файл в su из директории /etc/pam.d/. Попробуйте теперь выполнить команду su в терминале чтобы перейти в режим суперпользователя. После ввода пароля система выдаст ошибку аутентификации, так как отсутствует конфигурационный файл для программы su.
Создаем файл /etc/pam.d/su и пишем в нем такую строку:
Сохраняем файл. Пробуем снова выполнить команду su, и видим, что теперь мы становимся суперпользователем без запроса пароля. Это произошло потому, что модуль pam_permit.so всегда возвращает положительный результат, sufficient тут же прерывает выполнение цепочки и система PAM возвращает положительный результат. Отредактируем файл к следующему виду:
Модуль pam_deny.so всегда возвращает ошибку. Какой будет результат? Проверьте. А если заменить requisite на required?
Теперь напишем в файле следующее правило:
Теперь после выполнения команды su будет запрошен пароль пользователя root. Если пароль ввести правильно, то вы станете рутом, если пароль будет неверный, то останетесь обычным пользователем. Теперь добавим в файл еще одну строку, так чтобы получились следующие правила:
Модуль pam_wheel.so возвращает успех если учетная запись пользователя принадлежит группе wheel. Если попробовать сейчас выполнить команду su, то она тут же завершиться с ошибкой. То есть сейчас команду su смогут выполнить только пользователи, который входят в группу wheel и знают пароль учетной записи root. Если создать группу wheel и добавить туда свою учетную запись, то команда su сработает.
Попробуйте ответить кто сможет успешно выполнить команду su и, что для этого нужно будет сделать?
На этом завершим практическое упражнение (не забудьте вернуть на место оригинальный файл su).
Хочу еще раз подчеркнуть, что конфигурационные файлы в каталоге /etc/pam.d/ можно создавать только для файлов которые используют систему PAM. Например, если создать файл /etc/pam.d/ls со строкой auth requisite pam_deny.so, то команда ls все равно будет выполнятся так как она не использует систему PAM. Чтобы проверить использует ли команда систему PAM можно использовать команду ldd, которой в качестве параметра передается полный путь к файлу команды. Например:
Команда ldd покажет какие библиотеки использует программа и если в перечне есть libpam.so.0, libpam_misc.so.0 значит программа использует систему PAM.
В завершении хочу еще упомянуть о таком файле как /etc/nsswitch.conf. Первые три строки этого файла как раз и задают какая система аутентификации будет работать в системе:
Ключевое слово compat как раз и “говорит” о том что в качестве системы аутентификации, будет использована система PAM.
И еще. Будьте осторожны в экспериментах с PAM. По незнанию или неосторожности можно запросто заблокировать свою систему. Поэтому перед тем как что-то менять обязательно сохраните исходные конфигурационные файлы, чтобы в случае проблем можно было их быстро восстановить.
Linux pam что такое
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 будет выглядеть следующим образом:
| auth required /lib/security/pam_userdb.so db=path/to/file |
Неправильные аргументы будут проигнорированы и модуль не вернет никакого результата. Когда встречается неверный аргумент, ошибка обычно фиксируется в /var/log/mesages.
Примеры конфигурационного файла PAM.
Конфигурационный PAM файл приложения может выглядеть так:
| #%PAM-1.0 auth required /lib/security/pam_securetty.so auth required /lib/security/pam_unix.so shadow nullok auth required /lib/security/pam_nologin.so account required /lib/security/pam_unix.so password required /lib/security/pam_cracklib.so password required /lib/security/pam_unix.so shadow nullok use_authtok session required /lib/security/pam_unix.so |
| auth required /lib/security/pam_securetty.so |
Вторая строка проверяет наличие терминала с которого производится попытка а аутентификации в файле /etc/securetty, если таковой существует, в случае root логина. Если tty не указан в файле, то аутентификация не будет разрешена.
| auth required /lib/security/pam_unix.so shadow nullok |
Третья строка запрашивает у пользователя пароль и проверяет его.
| auth required /lib/security/pam_nologin.so |
Четвертая строка проверяет наличие файла /etc/nologin. Если файл существует и пользоваетль не является root, аутентификация завершится неудачей.
Заметьте, что все три auth модуля будут обрабатываться одниаково, независимо от того, проход какого модуля завершится неудачей. Такая стратегия не позволяет узнать пользователю какой именно этап аутентификации он не прошел. Знание причин провала аутентификации может стать причиной обхода пользователем этого этапа в следующий раз. Вы можете изменить такое поведение системы, заменив required модуль на requisite. Если какой либо requisite модуль не будет пройден, PAM остановится немедленно и вернет результат неудачи. Остальные существующие модули при этом проверяться не будут.
| account required /lib/security/pam_unix.so |
Пятая строка производит необходимые проверки аккаунта. Например, если включены теневые пароли, модуль pam_unix.so проверяет время действия аккаунта или своевременную смену пароля пользователем.
| account required /lib/security/pam_cracklib.so |
Шестая строка проверяет, не могут ли измененные пароли быть взломаны при помощи программ перебирающих по словарю.
| password required /lib/security/pam_unix.so shadow nullok use_authtok |
Восьмая, и последняя строка определяет, что модуль pam_unix.so будет управлять сеансом (сессией). В данный момент этот модуль ничего не делает; он должен быть заменен на необходимый модуль или дополнен stack’ингом (поправьте меня, кто может).
Обратите внимание на порядок строк в файле. Порядок вызова required модулей не имеет значения, доступны другие флаги управления. Использование в файле optional модулей обуславливает важность порядка выполнения модулей sufficient и requisite.
В качестве следующегь примера рассмотрим конфигурационный файл для rlogin:
Первое. Если существует файл /etc/nologin, никто кроме root не сможет зарегистрироваться в системе.
| auth required /lib/security/pam_securetty.so |
Второе. pam_securetty.so предотвращает регистрацию root с ненадежных терминалов. Неплохо было бы запретить логиниться root’у при помощи rlogin. Если вы желаете иметь такую возможность (в этом случае вы должны иметь хороший firewall или быть отключенным от интернета), смотрите документацию rlogin.
| auth required /lib/security/pam_env.so |
Третье. Модуль pam_env.so загружает переменные окружения, описанные в /etc/security/pam_env.conf.
| auth sufficient /lib/security/pam_rhosts_auth.so |
| auth required /lib/security/pam_stack.so service=system-auth |
Пятое. Если 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
Перевод:
Александр Шепетко