How to disable sudo related logging for successful command execution under CentOS/Fedora?

Question

You can disable sudo related log messages via adding something like

Defaults:juser !syslog

to the sudoers file.

That will disable logging to syslog. But under e.g. CentOS/Fedora there is an auditd enabled by default which continues to (verbosely) log a successful sudo execution via /var/log/audit/audit.log. That means one (successful) sudo call results in 5 auditd log entries.

One (perhaps too broad) method to silence those messages is to disable the auditing of those message via auditctl options like those:

-a exclude,always -F msgtype=USER_START
-a exclude,always -F msgtype=USER_END 
-a exclude,always -F msgtype=USER_CMD
-a exclude,always -F msgtype=CRED_ACQ
-a exclude,always -F msgtype=CRED_DISP

Is there a more elegant/fine-grained method to only disable the auditing of successful sudo-calls?

(Perhaps only for a certain sudo-user?)

Solution 1

check your current rules and disable as needed.

sudo auditctl -l

Solution 2

I looked this up on CentOS 7.

According to man auditctl you could check for the euid to filter out more specific for the user juser.

Comments

[maxschlepzig]

@WarrenYoung, well, you have to draw the line somewhere. Logging your sudo scp ... command does not really reduces its harm, or does it? The point in time you notice it (if you notice it at all!) it is already to late. Thus, it makes more sense to invest your energy into reviewing and testing your sudo setup and related systems. Also, logging unsuccessful is not necessarily about detecting a mischievous person, it is probably more important for detecting a misconfiguration. And - someone unauthorized who successfully executes your sudo command, is probably also able to escape the auditing.

[Warren Young]

You don't seem to be considering secure logging with an eye toward post-mortem incident analysis. If you log to localhost and/or purposely decrease the audit level and your box gets rooted, you may never be able to discover how it was done, so you may be unable to prevent the replacement from getting rooted the same way. A trap-door log server with plenty of disk space can help you reconstruct what happened.

[maxschlepzig]

@WarrenYoung, I'm not against secure-logging in principle; for some deployments you want/need it - for others you don't. Also, secure logging is no silver bullet, either. It may give you clues in a post-mortem. As well as a good backup schedule.

[Abolfazl Najjar]

The "secure logging" page is now at wpollock.com/AUnixSec/LoggingInfrastructure.htm

[maxschlepzig]

Hm, can you add some concrete disable commands?