Пользовательские модули PAM и соображения безопасности

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

В моем /etc/pam.d/каталоге много конфигурационных файлов , и я знаю, что делает большинство сервисов (кроме пары, например, atd, polkit, ppp). Я предполагаю, что аутентификация со стеком PAM происходит примерно так:

1. Запускает стек на основе имени службы (если файл конфигурации существует)
2. Если не аутентифицировано, используйте common- *, где * - тип модуля (аутентификация, учетная запись и т. Д.)
3. Вернуть успех или не вызвать вызывающее приложение (и любые другие данные, конечно)

Я прав в этом предположении? Все ли платформы имеют общую аутентификацию, общую учетную запись, общий пароль и общий сеанс?

Если это так, я думал о том, чтобы просто поместить его на вершину common- * в качестве sufficientмодуля, чтобы при сбое обычный стек PAM оставался без изменений. Это особенно полезно, потому что я могу сделать это программно при установке программного обеспечения.

Я пропускаю какие-либо потенциальные уязвимости безопасности?

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

Когда вы вызываете Linux-PAM для какой-либо процедуры аутентификации, всегда выполняется один и только один стек.

Определение стека ищется в этих местах; первая успешная попытка определяет, какой файл читается:

1. файл /etc/pam.dназван в честь приложения «имя службы» (например, sshdили gdm), или

2. файл, /etc/pam.d/otherесли файл для конкретной службы не существует, или

3. файл, /etc/pam.confесли каталог /etc/pam.dне существует.

Подробности смотрите в документации по функции pam_start .

Файлы common- * - это соглашение, которому следуют многие дистрибутивы Linux, но оно не требуется самим программным обеспечением PAM. Они обычно включаются другими файлами PAM с помощью @include операторов; например, /etc/pam.d/otherфайл в Debian имеет следующее содержимое:

# We fall back to the system default in /etc/pam.d/common-*
@include common-auth
@include common-account
@include common-password
@include common-session

Те же @includeоператоры могут использоваться и для файла, специфичного для службы, и -indeed- они находятся в конфигурации по умолчанию в Debian. Обратите внимание, что это вопрос конфигурации: системный администратор может изменить файл так, /etc/pam.dчтобы он вообще не включал общие файлы *!

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