Как остановить sudo PAM-сообщения в auth.log для конкретного пользователя?

Я использую Zabbix для мониторинга своей среды и zabbix_agentdвыполняю как пользователь zabbixодин пользовательский скрипт каждые 60 секунд; он использует sudoдля запуска этого скрипта как root.

В /var/log/auth.logI см через каждые 60 секунд:

Aug 11 17:40:32 my-server sudo: pam_unix(sudo:session): session opened for user root by (uid=0)
Aug 11 17:40:32 my-server sudo: pam_unix(sudo:session): session closed for user root

Я хочу остановить это сообщение от затопления моего журнала. Я добавил следующую строку в /etc/pam.d/sudoфайл, непосредственно перед session required pam_unix.so:

session [success=1 default=ignore] pam_succeed_if.so service in sudo quiet uid = 0

и сообщение исчезло.

Но проблема в том, что таким образом я подавляю каждое сообщение PAM, когда кто-то выполняет скрипт с sudoas root.

Я хочу остановить сообщение только для пользователя zabbix(не всех других пользователей). sudoзнает, что zabbixпользователь хочет выполнить скрипт с rootпривилегиями и есть ли способ сообщить PAM, что? Как я могу сказать PAM не входить в систему для конкретного пользователя при использовании sudo?

Примечание : я попытался отфильтровать сообщения в системном журнале; хотя это работает, у него та же проблема, что и выше, а именно, что оно слишком неразборчиво, так как в сообщении журнала не указывается, какой пользователь становится пользователем root.

Вы, кажется, довольно близки с вашей строкой конф. PAM:

session [success=1 default=ignore] pam_succeed_if.so service in sudo quiet uid = 0

Глядя на страницу руководства для pam_succeed_if, я думаю, вы хотите проверить, что запрашивающий пользователь ( ruser) zabbix.

Поэтому я предлагаю:

session [success=1 default=ignore] pam_succeed_if.so quiet uid = 0 ruser = zabbix

Это будет подавлять следующий тест, когда пользователь zabbixстановится root(но никаких других переходов). Я проверил это с парой моих собственных пользователей.

Удалите uid = 0описанный выше тест, если хотите сохранить молчание о том, чтобы zabbixстать любым пользователем, а не просто пользователем root.

Я удалил service in sudoтест: он избыточен, учитывая, что эта строка в /etc/pam.d/sudo.

Основываясь на ответе Тоби, я нашел способ настроить это немного по-другому в Debian / Ubuntu. Для контекста, см .:

• https://manpages.debian.org/stretch/libpam-runtime/pam-auth-update.8.en.html
• https://wiki.ubuntu.com/PAMConfigFrameworkSpec

Итак, в Debian / Ubuntu есть эта pam-auth-updateкоманда, и когда вы смотрите на /etc/pam.d/sudoнее, это выглядит так:

#%PAM-1.0

@include common-auth
@include common-account
@include common-session-noninteractive

и /etc/pam.d/common-session-noninteractiveвыглядит так:

#
# /etc/pam.d/common-session-noninteractive - session-related modules
# common to all non-interactive services
#
# This file is included from other service-specific PAM config files,
# and should contain a list of modules that define tasks to be performed
# at the start and end of all non-interactive sessions.
#
# As of pam 1.0.1-6, this file is managed by pam-auth-update by default.
# To take advantage of this, it is recommended that you configure any
# local modules either before or after the default block, and use
# pam-auth-update to manage selection of other modules.  See
# pam-auth-update(8) for details.

# here are the per-package modules (the "Primary" block)
session [default=1]         pam_permit.so
# here's the fallback if no module succeeds
session requisite           pam_deny.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
session required            pam_permit.so
# and here are more per-package modules (the "Additional" block)
session required    pam_unix.so
# end of pam-auth-update config

Конечно, я мог бы отредактировать любой из вышеперечисленных файлов, но очевидно, что здесь есть некоторая «большая мощность». Как сделать так, чтобы мои изменения хорошо сочетались с другими пакетами, в которые можно добавить правила pam? В довершение всего, мне казалось, что я не могу просто добавить строку /etc/pam.d/sudoмежду @includeэтими двумя, как это ..

##### THIS DIDN'T WORK :( ######
@include common-auth
@include common-account
session [default=ignore] pam_succeed_if.so quiet_success service = sudo uid = 0 ruser = myappuser
@include common-session-noninteractive

После прочтения приведенных выше ссылок, а также других примеров (см. /usr/share/pam-configs/unix) Я придумал следующее /usr/share/pam-configs/myapp:

# Don't log "session opened" messages for myapp user
# See: https://wiki.ubuntu.com/PAMConfigFrameworkSpec
#      https://manpages.debian.org/stretch/libpam-modules/pam_succeed_if.8.en.html
Name: myapp disable session logging
Default: yes
Priority: 300
Session-Type: Additional
Session:
    [default=ignore] pam_succeed_if.so quiet_success service = sudo uid = 0 ruser = myappuser

Sessionи Session-Typeконтролировать, какие файлы редактируются, и Priorityопределяет, в каком порядке они находятся . После добавления этого файла и запуска pam-auth-update, /etc/pam.d/common-session-noninteractiveвыглядит так (внизу :)

#... omitted
session required            pam_permit.so
# and here are more per-package modules (the "Additional" block)
session [default=ignore] pam_succeed_if.so quiet_success service = sudo uid = 0 ruser = myappuser
session required pam_unix.so 
# end of pam-auth-update config

... это то, что мы хотим, потому что наша pam_succeed_ifлиния должна прийти раньше session required pam_unix.so. (Эта строка взята /use/share/pam-configs/unixи имеет, Priority: 256поэтому она заканчивается на втором месте.) Также обратите внимание, что я оставил service = sudoпредикат, поскольку, common-session-noninteractiveкроме того, он может быть включен и в другие конфигурации sudo.

В моем случае я уже упаковал свой код в качестве установщика .deb, поэтому я добавил /usr/share/pam-configs/myappфайл, добавил pam-auth-update --packageв свои postinstи prermсценарии, и я готов!

Предостережение...

Если вы прочитали статью PAMConfigFrameworkSpec, на которую я ссылался выше , она определит Session-Interactive-Onlyпараметр, но не сможет указать только неинтерактивные правила . Так же /etc/pam.d/common-sessionбыло обновлено . Я не думаю, что есть способ обойти это. Если вы согласны с тем, что интерактивные сеансы не регистрируются для этого пользователя (это служебная учетная запись, верно?), То все должно быть готово!

Бонус: как убрать вывод sudo log

Помимо session openened|closedстрок, которые выдает PAM, в журнал sudoзаносится дополнительная информация о выполняемой команде. Это выглядит так:

[user] : TTY=unknown ; PWD=... ; USER=root ; COMMAND=...

Если вы также хотите удалить это, откройте эту ссылку и продолжите ниже ...

• https://www.sudo.ws/man/1.8.15/sudoers.man.html#Authentication_and_logging

Итак ... вы, вероятно, знакомы с типичной /etc/sudoers.d/___настройкой, которая может сделать что-то подобное для учетной записи службы, которой нужны привилегии суперпользователя для некоторых действий:

myuser ALL=(ALL) NOPASSWD: /bin/ping

это может войти /etc/sudoers.d/10_myuser. Ну, кроме всего прочего, вы также можете указатьDefaults . Обратите особое внимание на этот синтаксис'Defaults' ':' User_List

Теперь, посмотрите на раздел ОПЦИИ SUDOERS . Интересные биты включают log_input, log_outputно (вероятно), что более важно, syslogи logfile. Мне кажется, что в последних версиях Debian либо rsyslog, либо sudolog to stdoutили stderrпо умолчанию. Так что для меня это было обнаружено в журнале journald для моей службы, а не, например, /var/log/auth.logтам, где это не будет смешиваться с журналами моего приложения. Чтобы удалить ведение журнала sudo, я добавил следующее, /etc/sudoers.d/10_myuserчтобы оно выглядело так:

Defaults:myuser !logfile, !syslog
myuser ALL=(ALL) NOPASSWD: /bin/ping

YMMV, если вы чувствуете, что отключение ведения журнала создает проблемы с аудитом безопасности, вы также можете попытаться решить эту проблему с помощью фильтров rsyslog.

После довольно страшного тестирования и исследований я нашел рабочее решение для Debian Stretch (на Raspberry). Несомненно, есть несколько способов выполнить то, о чем просит OP. Но документация PAM огромна, поэтому большинство вещей на самом деле TL; DR.

1. Вы можете добавить собственный строковый фильтр для rsyslog в:, /etc/rsyslog.d/anyname.confиспользуя:
   :msg, contains, "session opened for user root by pi" stop
2. Вы можете напрямую редактировать /etc/pam.d/sudo
3. Вы можете сделать это правильно, создав специальный файл конфигурации PAM в: /usr/share/pam-configs/
4. Вы можете сделать некоторые путем создания пользовательских sudoers файл:/etc/sudoers.d/020_pi

Я покажу вам, как это сделать (2) и (4).

ПРЕДУПРЕЖДЕНИЕ

Не редактируйте файлы /etc/pam.d/без предварительного изменения их прав на запись. Если вы этого не сделаете и допустите ошибку, вы можете заблокировать любое будущее использование sudo / su ! Поэтому убедитесь, что вы проверили новые настройки, прежде чем изменить их обратно. (По умолчанию 644 )

Чтобы избавиться от «сеанса открытия / закрытия»:

Мы хотим избавиться от следующего /var/log/auth.logспама:

May 10 11:28:03 xxx sudo[26437]: pam_unix(sudo:session): session opened for user root by (uid=0)
May 10 11:28:07 xxx sudo[26437]: pam_unix(sudo:session): session closed for user root

Сделай это:

# sudo chmod 666 /etc/pam.d/sudo
# sudo cat /etc/pam.d/sudo

#%PAM-1.0

@include common-auth
@include common-account
session [success=1 default=ignore] pam_succeed_if.so quiet_success uid = 0 ruser = pi
@include common-session-noninteractive

Что имеет решающее значение здесь, является то , что success=1, значит , чтобы пропустить следующий пункт 1 (или в РАМ жаргоне «перепрыгнуть следующий модуль в стеке»), в случае успеха.

От man pam.conf:

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

done - эквивалентно ok с побочным эффектом завершения стека модулей и немедленного возврата PAM в приложение.

N - эквивалентно ok с побочным эффектом перепрыгивания через следующие N модулей в стеке.

Затем перезагрузите компьютер и дайте ему поработать несколько часов (например, для проверки заданий cron), чтобы проверить, что это работает. Затем обязательно восстановите права доступа к файлу, иначе у вас будет дыра в безопасности в вашей системе. ( sudo chmod 644 /etc/pam.d/sudo)

Чтобы избавиться от повторяющихся сообщений «TTY PWD COMMAND»:

Мы также хотим избавиться от таких сообщений:

May 11 18:23:20 xxx sudo:       pi : TTY=unknown ; PWD=... ; USER=root ; COMMAND=/usr/bin/arp-scan -q -l

В моем случае это было сгенерировано скриптом IDS, который запускал arp-scan каждые несколько минут. Чтобы удалить его из журналов, создайте следующий файл:

# sudo nano /etc/sudoers.d/020_pi
# sudo cat /etc/sudoers.d/020_pi

Defaults:pi     !logfile, !syslog
pi xxx = (root) NOPASSWD: /usr/bin/arp-scan

(Вот xxxимя вашей машины и piимя пользователя.)

Ты получишь:

pam_succeed_if(sudo:session): unknown attribute "ruser"

с вашим ответом.

#%PAM-1.0

@include common-auth
@include common-account
@include common-session-noninteractive
session     [success=1 default=ignore] pam_succeed_if.so service in zabbix quiet use_uid
session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid

работает, но вы все равно получите:

pam_unix(sudo:session): session opened for user root by (uid=0)

в ваших логах.