Jak zatrzymać wiadomości sudo PAM w auth.log dla konkretnego użytkownika?

Używam Zabbix do monitorowania środowiska i zabbix_agentdjako użytkownik wykonuje zabbixjeden niestandardowy skrypt co 60 sekund; używa sudodo uruchomienia tego skryptu jako root.

W /var/log/auth.logwidzę co 60 sekund:

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

Chcę powstrzymać ten komunikat przed zalaniem mojego dziennika. Dodałem następujący wiersz do /etc/pam.d/sudopliku, bezpośrednio przed session required pam_unix.so:

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

i wiadomość zniknęła.

Problem polega jednak na tym, że w ten sposób ukryłem każdą wiadomość PAM, gdy ktoś wykonuje skrypt za pomocą sudoas root.

Chcę zatrzymać wiadomość tylko dla użytkownika zabbix(nie dla wszystkich innych użytkowników). sudowie, że zabbixużytkownik chce wykonać skrypt z rootuprawnieniami i czy jest jakiś sposób, aby powiedzieć PAM o tym? Jak mogę powiedzieć PAM, aby nie rejestrował określonego użytkownika podczas korzystania sudo?

Uwaga : Próbowałem filtrować wiadomości w syslog; chociaż to działa, ma ten sam problem co powyżej, a mianowicie to, że jest zbyt niedyskryminujący, ponieważ komunikat dziennika nie wskazuje, który użytkownik rootuje.

Wydajesz się być blisko linii PAM conf:

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

Patrząc na stronę podręcznika pam_succeed_if, myślę, że chcesz przetestować, czy użytkownik żądający ( ruser) jest zabbix.

Więc sugeruję:

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

To powstrzyma następny test, gdy użytkownik zabbixsię zmieni root(ale nie ma innych przejść). Przetestowałem to z parą moich własnych użytkowników.

Usuń uid = 0powyższy test, jeśli chcesz zachować ciszę na temat zabbixzostania dowolnym użytkownikiem, a nie tylko rootowaniem.

Usunąłem service in sudotest: jest zbędny, biorąc pod uwagę, że ta linia jest w środku /etc/pam.d/sudo.

Na podstawie odpowiedzi Toby'ego znalazłem sposób, aby skonfigurować to w nieco inny sposób na Debian / Ubuntu. W kontekście zobacz:

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

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 ...

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

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.

Po dość przerażających testach i badaniach znalazłem działające rozwiązanie dla Debian Stretch (na Raspberry). Z pewnością istnieje więcej niż jeden sposób na spełnienie wymagań OP. Ale dokumentacja PAM jest przytłaczająca, więc większość rzeczy to tak naprawdę TL; DR.

1. Możesz dodać niestandardowy filtr ciągu dla rsyslog w: /etc/rsyslog.d/anyname.confużywając:
   :msg, contains, "session opened for user root by pi" stop
2. Możesz bezpośrednio edytować /etc/pam.d/sudo
3. Możesz to zrobić we właściwy sposób, tworząc niestandardowy plik konfiguracyjny PAM w: /usr/share/pam-configs/
4. Możesz to zrobić, tworząc niestandardowy plik sudoers w:/etc/sudoers.d/020_pi

Pokażę ci, jak to zrobić (2) i (4).

OSTRZEŻENIE

Nie edytuj żadnych plików /etc/pam.d/bez uprzedniej zmiany ich uprawnień do zapisu na świecie. Jeśli tego nie zrobisz i popełnisz błąd, możesz zablokować sobie jakiekolwiek przyszłe użycie sudo / su ! Upewnij się więc, że przetestowałeś nowe ustawienia przed ich powrotem. (Domyślnie 644 )

Aby pozbyć się „sesji otwierania / zamykania”:

Chcemy pozbyć się następującego /var/log/auth.logspamu:

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

Zrób to:

# 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

Kluczowe znaczenie ma tutaj success=1pominięcie następnej 1 klauzuli (lub w języku PAM „przeskocz nad kolejnym modułem w stosie”), jeśli się powiedzie.

Od man pam.conf:

ignore - w przypadku użycia ze stosem modułów, status powrotu modułu nie przyczyni się do otrzymania kodu powrotu, który otrzymuje aplikacja.

gotowe - równoważne z efektem ubocznym zakończenia stosu modułów i natychmiastowego powrotu PAM do aplikacji.

N - równoważne ok z efektem ubocznym przeskakiwania kolejnych N modułów na stosie.

Następnie uruchom ponownie i pozwól mu działać przez kilka godzin (na przykład w celu sprawdzenia zadań cron), aby sprawdzić, czy to działa. Następnie ponownie zainstaluj uprawnienia do plików, w przeciwnym razie w systemie będzie luka bezpieczeństwa. ( sudo chmod 644 /etc/pam.d/sudo)

Aby pozbyć się powtarzających się komunikatów „TTY PWD COMMAND”:

Chcemy również pozbyć się takich wiadomości:

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

W moim przypadku zostało to wygenerowane przez skrypt IDS, który uruchamiał arp-scan co kilka minut. Aby usunąć go z wyświetlania w dziennikach, utwórz następujący plik:

# 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

(Oto xxxnazwa twojego komputera i pinazwa użytkownika.)

Dostaniesz:

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

z twoją odpowiedzią.

#%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

działa, ale nadal otrzymasz:

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

w twoich logach.