Na podstawie odpowiedzi Toby'ego znalazłem sposób, aby skonfigurować to w nieco inny sposób na Debian / Ubuntu. W kontekście zobacz:
Debian / Ubuntu ma więc to pam-auth-updatepolecenie i kiedy na nie patrzysz /etc/pam.d/sudo, wygląda to tak:
#%PAM-1.0
@include common-auth
@include common-account
@include common-session-noninteractive
i /etc/pam.d/common-session-noninteractivewygląda tak:
#
# /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
Tak, pewnie, mógłbym edytować dowolny z powyższych plików, ale najwyraźniej tutaj działa jakaś „wyższa moc”. Jak sprawić, by moje zmiany grały ładnie z innymi pakietami, które mogą chcieć dodać reguły pam? Podsumowując, wydawało mi się, że nie mogę po prostu dodać linii /etc/pam.d/sudomiędzy tymi dwoma @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
Po przeczytaniu powyższych linków oraz innych przykładów (patrz /usr/share/pam-configs/unix) wymyśliłem to w /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
Sessioni Session-Typesterowanie, które pliki są edytowane i Prioritydefiniuje jakiej kolejności idą w. Po dodaniu tego pliku i działa pam-auth-update, /etc/pam.d/common-session-noninteractivewygląda następująco (na dole :)
#... 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
... tego chcemy, ponieważ nasza pam_succeed_iflinia musi być wcześniejsza session required pam_unix.so. (Ta linia pochodzi z /use/share/pam-configs/unixi ma Priority: 256tak, że kończy się na drugim miejscu.) Zauważ też, że opuściłem service = sudopredykat, ponieważ common-session-noninteractivemoże być również zawarty w innych konfiguracjach poza tym sudo.
W moim przypadku spakowałem już swój kod jako instalator .deb, więc dodałem /usr/share/pam-configs/myappplik, dodałem pam-auth-update --packagedo mojego postinsti prermskryptów i jestem gotowy!
Zastrzeżenie ...
Jeśli czytasz artykuł PAMConfigFrameworkSpec, który podłączyłem powyżej , definiuje on Session-Interactive-Onlyopcję, ale nie ma sposobu na określenie tylko nieinteraktywnych reguł . Tak też/etc/pam.d/common-session został zaktualizowany . Nie sądzę, żeby można to obejść. Jeśli nie masz nic przeciwko sesjom interaktywnym dla tego użytkownika (jest to konto usługi, prawda?), Wszystko powinno być gotowe!
Bonus: jak również usunąć wyjście dziennika sudo
Oprócz session openened|closedwierszy emitowanych przez PAM sudorejestruje dodatkowe informacje o uruchamianym poleceniu. To wygląda tak:
[user] : TTY=unknown ; PWD=... ; USER=root ; COMMAND=...
Jeśli chcesz to również usunąć, otwórz ten link, a następnie kontynuuj poniżej ...
Więc ... prawdopodobnie znasz typową /etc/sudoers.d/___konfigurację, która może zrobić coś takiego dla konta usługi, które wymaga uprawnień administratora superużytkownika do niektórych działań:
myuser ALL=(ALL) NOPASSWD: /bin/ping
to może wejść /etc/sudoers.d/10_myuser. Cóż, między innymi możesz również określićDefaults . Zwróć szczególną uwagę na tę składnię'Defaults' ':' User_List
Teraz spójrz na sekcję OPCJE SUDOERS . Interesujące bity obejmują log_input, log_outputale (prawdopodobnie) co ważniejsze syslogi logfile. Wydaje mi się, że w najnowszych wersjach Debiana albo rsyslog, albo loguj się sudodo stdoutlub stderrdomyślnie. Dla mnie było to widoczne w dzienniku dziennika dla mojej usługi, a nie np. W /var/log/auth.logmiejscu, w którym nie zmieszałoby się ono z dziennikami aplikacji. Aby usunąć rejestrowanie sudo, dodałem następujące, aby /etc/sudoers.d/10_myuserwyglądało to tak:
Defaults:myuser !logfile, !syslog
myuser ALL=(ALL) NOPASSWD: /bin/ping
YMMV, jeśli uważasz, że wyłączenie rejestrowania powoduje problemy z audytami bezpieczeństwa, możesz również spróbować rozwiązać ten problem za pomocą filtrów rsyslog.
session closed for user roota jeśli ją filtruję, filtruję wszystkie wiadomości. Chcę konkretnego użytkownika, który nie jest wymieniony w wiadomości i nie mogę filtrować według jego nazwy ...