Что делает pam_parsec_mac

Модуль лежит в /usr/lib/security/pam_parsec_mac.so и ставится пакетом parsec-mac. Его работа — связать вход пользователя с мандатной подсистемой PARSEC: при входе прочитать мандатные атрибуты пользователя (уровни конфиденциальности и целостности), дать выбрать уровень сессии, где это предусмотрено, и выставить метку создаваемой сессии.

Атрибуты хранятся в базе /etc/parsec/macdb — по файлу на пользователя, имена файлов совпадают с uid. Смотреть их удобнее не в файлах, а штатной командой:

$ sudo pdpl-user admin
минимальная метка: Уровень_0:Низкий:Нет:0x0
максимальная метка: Уровень_0:Высокий:Нет:0x0

Подключён модуль в PAM-конфигурациях всех точек входа. Фрагмент штатного /etc/pam.d/fly-dm:

auth required pam_parsec_mac.so
account required pam_parsec_mac.so labelselect=appset
session required pam_parsec_mac.so

Модуль отрабатывает в трёх фазах: auth читает атрибуты и запоминает выбор уровня, account проверяет допустимость, session выставляет метку сессии. Это разделение — ключ к пониманию главной ошибки, о ней ниже.

Строка «session required pam_parsec_mac.so stub» — это не ошибка

В /etc/pam.d/sshd модуль встречается дважды:

session required pam_parsec_mac.so stub
...
session required pam_parsec_mac.so

Первая строка стоит до общего блока @include common-session, вторая — после. Аргумент stub помечает холостой вызов: этот проход метку сессии не выставляет. Точную семантику аргумента описывает документация пакета parsec-mac; практический вывод один — строка штатная, менять её не нужно.

Другие аргументы из штатных конфигураций, которые вызывают вопросы: unshare_root_only (управляет отделением пространства имён для root-сессий) и labelselect=appset (откуда берётся выбор уровня на экране входа). Оба — часть поставки, трогать их без задачи не стоит.

pam_parsec.so или pam_parsec_mac.so?

Модуля с именем pam_parsec.so в Astra нет — если вы ищете его по чьей-то инструкции, это описка. Есть семейство PARSEC-модулей, и в /usr/lib/security/ их четыре:

$ ls /usr/lib/security/ | grep parsec
pam_parsec_aud.so
pam_parsec_cap.so
pam_parsec_mac.so
pam_parsec_xauth.so

Разделение по подсистемам: pam_parsec_mac — мандатные атрибуты (наш герой), pam_parsec_cap — привилегии PARSEC (база /etc/parsec/capdb), pam_parsec_aud — флаги аудита (/etc/parsec/auddb), pam_parsec_xauth — передача мандатного контекста при графической авторизации. В штатных конфигурациях они работают вместе, и строку про каждый можно встретить в /etc/pam.d/.

«Can’t obtain required data» и «failed to get module data»

Механика ошибки простая. Фазы модуля обмениваются данными через внутреннее хранилище PAM: auth кладёт туда прочитанные атрибуты и выбранный уровень, account и session их забирают. Если account или session вызваны, а данных нет — модуль сообщает, что не может получить требуемые данные, и вход завершается ошибкой.

Это воспроизводится штатным pamtester: вызовем account-фазу напрямую, без auth:

$ sudo pamtester login admin acct_mgmt
pamtester: No module specific data is present

Откуда данные могут не появиться в реальной жизни — причины похожи по симптому, но механизм у каждой свой:

  1. Кастомная PAM-конфигурация, собранная выборочно. Если account- или session-строка pam_parsec_mac.so в /etc/pam.d/<сервис> выполняется, а нужных ей данных никто не положил, вход ломается. Какой набор фаз правильный — зависит от типа сервиса: у интерактивного входа (login, fly-dm) это связка auth + account + session, у sshd — своя схема session-строк со stub. Сверяйте свой конфиг со штатным сервисом того же типа, а не с универсальным шаблоном.
  2. У пользователя нет мандатных атрибутов. Проверяется командой sudo pdpl-user <имя>; если атрибутов нет — назначить их можно pdpl-user с параметрами или через графическую утилиту управления политикой. Ошибка «pdpl-setup: failed to get pam_parsec_mac module data» — из этой же семьи: инструмент настройки не получил от модуля данные пользователя.
  3. Доменные пользователи. При входе доменного пользователя (ALD, FreeIPA) атрибуты приходят не из локальной macdb, а из домена — источник атрибутов задаётся в /etc/parsec/mswitch.conf, а в PAM-стеке рядом с pam_parsec_mac в таких схемах стоит доменный модуль (например, pam_ald в ALD). Если служба домена недоступна или у учётной записи не заданы мандатные атрибуты на стороне домена, модуль получает пустоту — с той же ошибкой. Диагностируйте доступность домена и наличие атрибутов у пользователя в его панели управления.

Порядок диагностики

  1. sudo pdpl-user <имя> — есть ли у пользователя атрибуты вообще.
  2. grep pam_parsec_mac /etc/pam.d/<сервис> — все ли фазы на месте; эталон — штатный login или fly-dm.
  3. sudo pamtester <сервис> <имя> authenticate acct_mgmt — обе операции одним вызовом. Раздельные запуски для этой проверки бесполезны: каждый запуск pamtester — отдельная PAM-транзакция, данные auth-фазы живут только внутри неё, и второй запуск покажет отсутствие данных даже на здоровой системе.
  4. journalctl -t <сервис> и журнал безопасности — что модуль пишет в момент реального входа.

Частая развязка после диагностики: виноват кастомный сервис, куда строки модуля попали выборочно. Не собирайте набор фаз сами — возьмите за образец штатный сервис того же типа (интерактивный вход — login, удалённый — sshd) и перенесите его схему целиком. Добавлять auth-фазу туда, где её по замыслу нет (как в sshd), нельзя — так ломают вход. И любые правки PAM тестируйте, держа открытой запасную root-сессию.

База /etc/parsec/macdb правится только штатными инструментами — руками файлы с uid не редактируют.

Мандатные метки, которые модуль выставляет сессии, — тема соседнего разбора: что такое МКЦ и как жить с уровнями целостности.