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:
Debian / Ubuntu ont donc cette pam-auth-update
commande et quand vous la regardez, /etc/pam.d/sudo
elle ressemble à ceci:
#%PAM-1.0
@include common-auth
@include common-account
@include common-session-noninteractive
et /etc/pam.d/common-session-noninteractive
ressemble à 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/sudo
entre les deux @include
comme 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
Session
et Session-Type
contrôler quels fichiers sont modifiés et Priority
définit dans quel ordre ils vont. Après avoir ajouté ce fichier et exécuté pam-auth-update
, /etc/pam.d/common-session-noninteractive
ressemble à 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_if
gamme doit venir avant session required pam_unix.so
. (Cette ligne vient de /use/share/pam-configs/unix
et a Priority: 256
donc elle finit deuxième.) Notez également que j'ai laissé le service = sudo
prédicat car common-session-noninteractive
pourrait é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/myapp
fichier, et ajouté pam-auth-update --package
à mes postinst
et prerm
scripts 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-Only
option, mais n'a aucun moyen de spécifier uniquement des règles non interactives . Ainsi /etc/pam.d/common-session
a é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|closed
lignes émises par PAM, sudo
enregistre 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 ...
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_output
mais (probablement) plus important encore, syslog
et logfile
. Il me semble que dans les versions récentes de Debian, rsyslog ou sudo
log to stdout
ou stderr
par défaut. Donc, pour moi, cela apparaissait dans le journal journal de mon service, et non par exemple /var/log/auth.log
où 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_myuser
qu'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.
session closed for user root
et si je le filtre en fait, je filtre tous les messages. Je veux un utilisateur spécifique qui n'est pas mentionné dans le message et je ne peux pas filtrer par son nom ...