Comment arrêter les messages sudo PAM dans auth.log pour un utilisateur spécifique?

J'utilise Zabbix pour surveiller mon environnement et zabbix_agentdexécute en tant qu'utilisateur zabbixun script personnalisé toutes les 60 secondes; il utilise sudopour exécuter ce script en tant que root.

Dans /var/log/auth.logje vois toutes les 60 secondes:

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

Je veux empêcher ce message d'inonder mon journal. J'ai ajouté la ligne suivante au /etc/pam.d/sudofichier, immédiatement avant session required pam_unix.so:

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

et le message a disparu.

Mais le problème est que de cette façon, j'ai supprimé tous les messages PAM lorsque quelqu'un exécute un script avec sudoas root.

Je souhaite arrêter le message uniquement pour l'utilisateur zabbix(pas tous les autres utilisateurs). sudosait que l' zabbixutilisateur veut exécuter le script avec des rootprivilèges et est-il possible de le dire à PAM? Comment puis-je dire à PAM de ne pas se connecter pour un utilisateur spécifique lors de l'utilisation sudo?

Remarque : j'ai essayé de filtrer les messages dans syslog; bien que cela fonctionne, il a le même problème que ci-dessus, à savoir qu'il est trop aveugle, car le message de journal n'indique pas quel utilisateur devient root.

Vous semblez assez proche de votre ligne de conf PAM:

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

En regardant la page de manuel pour pam_succeed_if, je pense que vous voulez tester que l'utilisateur demandeur ( ruser) est zabbix.

Je suggère donc:

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

Cela supprimera le prochain test lorsque l'utilisateur zabbixdeviendra root(mais pas d'autres transitions). J'ai testé cela avec une paire de mes propres utilisateurs.

Supprimez le uid = 0test ci-dessus si vous voulez garder le silence sur le fait de zabbixdevenir un utilisateur, plutôt que simplement root.

J'ai supprimé le service in sudotest: c'est redondant étant donné que cette ligne est dedans /etc/pam.d/sudo.

Sur la base de la réponse de Toby, j'ai trouvé un moyen de configurer cela d'une manière légèrement différente sur Debian / Ubuntu. Pour le contexte, voir:

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

Debian / Ubuntu ont donc cette pam-auth-updatecommande et quand vous la regardez, /etc/pam.d/sudoelle ressemble à ceci:

#%PAM-1.0

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

et /etc/pam.d/common-session-noninteractiveressemble à ceci:

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

Donc, bien sûr, je pourrais modifier l'un des fichiers ci-dessus, mais il y a clairement une "puissance plus élevée" à l'œuvre ici. Comment faire en sorte que mes modifications fonctionnent correctement avec d'autres packages qui pourraient vouloir ajouter des règles de pam? Pour couronner le tout, il semblait que je ne pouvais pas simplement ajouter une ligne /etc/pam.d/sudoentre les deux @includecomme ceci ..

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

Après avoir lu les liens ci-dessus ainsi que d'autres exemples (voir /usr/share/pam-configs/unix), j'ai trouvé ceci, dans /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

Sessionet Session-Typecontrôler quels fichiers sont modifiés et Prioritydéfinit dans quel ordre ils vont. Après avoir ajouté ce fichier et exécuté pam-auth-update, /etc/pam.d/common-session-noninteractiveressemble à ceci (en bas :)

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

... c'est ce que nous voulons parce que notre pam_succeed_ifgamme doit venir avant session required pam_unix.so. (Cette ligne vient de /use/share/pam-configs/unixet a Priority: 256donc elle finit deuxième.) Notez également que j'ai laissé le service = sudoprédicat car common-session-noninteractivepourrait également être inclus dans d'autres configurations sudo.

Dans mon cas, je l' avais déjà emballé mon code comme installateur .deb donc j'ajouté le /usr/share/pam-configs/myappfichier, et ajouté pam-auth-update --packageà mes postinstet prermscripts et je suis bon pour aller!

Caveat...

Si vous lisez l' article PAMConfigFrameworkSpec que j'ai lié ci - dessus , il définit une Session-Interactive-Onlyoption, mais n'a aucun moyen de spécifier uniquement des règles non interactives . Ainsi /etc/pam.d/common-sessiona également été mis à jour . Je ne pense pas qu'il y ait un moyen de contourner cela. Si vous êtes d'accord avec les sessions interactives qui ne sont pas enregistrées pour cet utilisateur (c'est un compte de service, non?), Alors vous devriez être prêt!

Bonus: comment supprimer également la sortie du journal sudo

Outre les session openened|closedlignes émises par PAM, sudoenregistre des informations supplémentaires sur la commande exécutée. Cela ressemble à ceci:

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

Si vous souhaitez également supprimer cela, ouvrez ce lien puis continuez ci-dessous ...

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

Donc ... vous êtes probablement familier avec une /etc/sudoers.d/___configuration typique qui pourrait faire quelque chose comme ça pour un compte de service qui a besoin de privilèges de superutilisateur pour certaines actions:

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

qui pourrait entrer /etc/sudoers.d/10_myuser. Eh bien, entre autres choses, vous pouvez également spécifierDefaults . Notez spécifiquement cette syntaxe'Defaults' ':' User_List

Maintenant, regardez la section OPTIONS SUDOERS . Les bits intéressants incluent log_input, log_outputmais (probablement) plus important encore, sysloget logfile. Il me semble que dans les versions récentes de Debian, rsyslog ou sudolog to stdoutou stderrpar défaut. Donc, pour moi, cela apparaissait dans le journal journal de mon service, et non par exemple /var/log/auth.logoù il ne serait pas mélangé dans mes journaux d'application. Pour supprimer la journalisation sudo, j'ai ajouté ce qui suit pour /etc/sudoers.d/10_myuserqu'il ressemble à ceci:

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

YMMV, si vous pensez que la désactivation de la journalisation crée des problèmes avec les audits de sécurité, vous pouvez également essayer de résoudre ce problème via les filtres rsyslog.

Après pas mal de tests et de recherches effrayants, j'ai trouvé une solution de travail pour Debian Stretch (sur Raspberry). Il y a sûrement plus d'une façon d'accomplir ce que demande OP. Mais la documentation PAM est écrasante, donc la plupart des choses sont vraiment TL; DR.

1. Vous pouvez ajouter un filtre de chaîne personnalisé pour rsyslog dans: /etc/rsyslog.d/anyname.confen utilisant:
   :msg, contains, "session opened for user root by pi" stop
2. Vous pouvez directement modifier /etc/pam.d/sudo
3. Vous pouvez le faire de la bonne façon en créant un fichier de configuration PAM personnalisé dans: /usr/share/pam-configs/
4. Vous pouvez en faire en créant un fichier sudoers personnalisé dans:/etc/sudoers.d/020_pi

Je vais vous montrer comment faire (2) et (4).

AVERTISSEMENT

Ne modifiez aucun fichier /etc/pam.d/sans avoir préalablement modifié ses autorisations d'écriture universelles. Si vous ne le faites pas et que vous faites une erreur, vous pouvez être exclu de toute utilisation future de sudo / su ! Assurez-vous donc que vous avez testé les nouveaux paramètres avant de les modifier à nouveau. (La valeur par défaut est 644 )

Pour se débarrasser de «ouverture / fermeture de session»:

Nous voulons nous débarrasser du /var/log/auth.logspam suivant :

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

Faites ceci:

# 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

Ce qui est d'une importance cruciale ici, c'est que success=1, signifie ignorer la clause 1 suivante (ou dans le jargon PAM "sauter par-dessus le module suivant dans la pile"), en cas de succès.

De man pam.conf:

ignore - lorsqu'il est utilisé avec une pile de modules, le statut de retour du module ne contribuera pas au code retour obtenu par l'application.

done - équivalent à ok avec pour effet secondaire de terminer la pile de modules et de retourner immédiatement PAM à l'application.

N - équivalent à ok avec l'effet secondaire de sauter par-dessus les N modules suivants de la pile.

Ensuite, redémarrez et laissez-le fonctionner quelques heures (pour vérifier les tâches cron par exemple) pour tester que cela fonctionne. Assurez-vous ensuite de rétablir les autorisations de fichier, sinon vous aurez un trou de sécurité béant dans votre système. ( sudo chmod 644 /etc/pam.d/sudo)

Pour se débarrasser des messages «TTY PWD COMMAND» répétés:

Nous voulons également nous débarrasser des messages comme celui-ci:

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

Dans mon cas, cela a été généré par un script IDS qui exécutait arp-scan toutes les quelques minutes. Pour le supprimer de l'affichage dans les journaux, créez le fichier suivant:

# 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

(Voici xxxle nom de votre machine et pile nom d'utilisateur.)

Tu auras:

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

avec votre réponse.

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

fonctionne mais vous obtiendrez toujours un:

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

dans vos journaux.