How to stop sudo PAM messages in auth.log for a specific user?

You seem pretty close with your PAM conf line:

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

Looking at the manual page for pam_succeed_if, I think you want to test that the requesting user (ruser) is zabbix.

So I suggest:

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

That will suppress the next test when user zabbix becomes root (but no other transitions). I've tested this with a pair of my own users.

Remove the uid = 0 test in the above if you want to keep quiet about zabbix becoming any user, rather than just root.

I removed the service in sudo test: it's redundant given that this line is in /etc/pam.d/sudo.

Based on Toby's answer, I found a way to configure this in a slightly different way on Debian/Ubuntu. For context, see:

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

So Debian/Ubuntu have this pam-auth-update command and when you look at /etc/pam.d/sudo it looks like this:

#%PAM-1.0

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

and /etc/pam.d/common-session-noninteractive looks like this:

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

So sure, I could edit either of the above files but clearly there's some "higher power" at work here. How to get my changes to play nice with other packages that might want to add pam rules? To top it off, it seemed I couldn't just add a line in /etc/pam.d/sudo in between the two @includes like this..

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

After reading the above links as well as other examples (see /usr/share/pam-configs/unix) I came up with this, in /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 and Session-Type control which files are edited and Priority defines what order they go in. After adding that file and running pam-auth-update, /etc/pam.d/common-session-noninteractive looks like this (at the bottom:)

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

... which is what we want because our pam_succeed_if line needs to come before session required pam_unix.so. (That line comes from /use/share/pam-configs/unix and has a Priority: 256 so it ends up second.) Note also that I left the service = sudo predicate since common-session-noninteractive might also be included in other configs besides sudo.

In my case, I had already packaged my code as a .deb installer so I added the /usr/share/pam-configs/myapp file, and added pam-auth-update --package to my postinst and prerm scripts and I'm good to go!

Caveat...

If you read the PAMConfigFrameworkSpec article that I linked above, it defines a Session-Interactive-Only option, but does not have a way to specify only noninteractive rules. So /etc/pam.d/common-session was also updated. I don't think there's a way around this. If you're ok with interactive sessions not being logged for that user (it IS a service account, right?) then you should be all set!

Bonus: how to also remove sudo log output

In addition to the session openened|closed lines that PAM emits, sudo logs additional information about the command that's run. It looks like this:

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

If you also want to remove that, open this link then continue below...

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

So... you're probably familiar with typical /etc/sudoers.d/___ setup which might do something like this for a service account which needs superuser privs for a some actions:

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

that might go in /etc/sudoers.d/10_myuser. Well, among other things you can also specify Defaults. Note specifically this syntax 'Defaults' ':' User_List

Now, look at the SUDOERS OPTIONS section. Interesting bits include log_input, log_output but (probably) more importantly, syslog and logfile. It appears to me that in recent versions of Debian, either rsyslog or sudo log to stdout or stderr by default. So for me this was showing up in the journald log for my service, and not e.g. /var/log/auth.log where it wouldn't get mixed into my application logs. To remove the sudo logging, I added the following to /etc/sudoers.d/10_myuser so it looks like:

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

YMMV, if you feel disabling logging creates issues with security audits you might also try to solve this via rsyslog filters.

After quite a bit of scary testing and research, I have found a working solution for the Debian Stretch (on Raspberry). There are surely more than one way to accomplish what OP ask for. But the PAM documentation is overwhelming, so most stuff is really TL;DR.

1. You can add a custom string filter for rsyslog in: /etc/rsyslog.d/anyname.conf by using:
   :msg, contains, "session opened for user root by pi" stop
2. You can directly edit /etc/pam.d/sudo
3. You can do it the right way by creating a custom PAM config file in: /usr/share/pam-configs/
4. You can do some by creating a custom sudoers file in: /etc/sudoers.d/020_pi

I'll show you how to do (2) and (4).

WARNING

Do not edit any files in /etc/pam.d/ without first changing their world write permissions. If you do not, and make a mistake, you can get locked out of any future use of sudo/su! So make sure you have tested the new settings before you change it back. (Default is 644)

---

To get rid of "session open/close":

We want to get rid of the following /var/log/auth.log spam:

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

Do this:

# 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

What is of crucial importance here, is that success=1, means to skip the next 1 clause (or in PAM lingo "jump over the next module in the stack"), if successful.

From man pam.conf:

ignore - when used with a stack of modules, the module's return status will not contribute to the return code the application obtains.

done - equivalent to ok with the side effect of terminating the module stack and PAM immediately returning to the application.

N - equivalent to ok with the side effect of jumping over the next N modules in the stack.

Next, reboot and let it run a few hours (to check cron jobs for example) to test that this works. Then make sure to re-instate the file permissions, otherwise you'll have a gaping security hole in your system. (sudo chmod 644 /etc/pam.d/sudo)

---

To get rid of repeated "TTY PWD COMMAND" messages:

We also want to get rid of messages like this:

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

In my case, this was generated by an IDS script that was running arp-scan every few minutes. To remove it from showing up in the logs, create the following file:

# 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

(Here xxx is your machine name, and pi is the username.)