Основываясь на ответе Тоби, я нашел способ настроить это немного по-другому в Debian / Ubuntu. Для контекста, см .:
Итак, в 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=...
Если вы также хотите удалить это, откройте эту ссылку и продолжите ниже ...
Итак ... вы, вероятно, знакомы с типичной /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, либо sudo
log 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.
session closed for user root
и если я на самом деле его фильтрую, я фильтрую все сообщения. Я хочу для конкретного пользователя, который не упоминается в сообщении, и я не могу фильтровать по его имени ...