Here's something that I hope everyone understands about sudo but that I want to say explicitly anyways: sudo is not an auditing mechanism, not for sysadmins who are expected to use general and unrestricted root powers. There are at least three different problems with sudo as an audit mechanism:

• sudo cannot track what an intruder does as root. Once the intruder runs, say, 'sudo bash -i', sudo is simply not logging things any more. Only a very cooperative intruder will helpfully run all of their commands through sudo. Once a less cooperative one escapes into a general root environment, that's it.

• sudo can't even reliably tell you when an intruder has escaped into a general root environment if the intruder is at all subtle. Consider the following sudo invocation:

  sudo less /var/log/exim4/mainlog

  This is a perfectly reasonable way to examine your Exim mail logs. It's also a perfect way for an intruder to run arbitrary commands without any obvious signature in sudo logs, since less lets you start a shell with '!bash'.

• even if you assume no malice, sudo can't necessarily tell you if one of your sysadmins accidentally ran a command. Again, consider:

  sudo vi /some/file

  In the course of editing this file, I want to wordwrap a paragraph of something. As a hardened vi person I immediately and reflexively type !}fmt, except that I accidentally type !}famt instead and you have a famt command. This isn't logged by sudo, of course. Depending on the resulting output I may realize that something has gone badly wrong (and I may even realize what I've run), or I may just say 'whoops, some sort of vi mistake again, u and try again'. Certainly in the latter case I'm very likely to swear up and down later that I couldn't possibly have run famt, I was just editing a file, and sudo's logs will back me up.

This isn't to say that sudo's logs are useless, because of course they aren't. In many cases they'll be able to mostly or completely reconstruct the history of root actions. This can be very useful for troubleshooting (especially positive troubleshooting, where you want to know 'did I try <X>' and the sudo log will say 'yes, you did') and reverse engineering what you did when you were flailing around in a hurry and not keeping careful notes.

(If you feel like playing the blame game they can also be used to prove that someone did not do some particular thing that they should have during an incident. Doing this is a terrible idea but that's another blog entry and anyways it mostly consists of pointers to sources like John Allspaw.)

What sudo's logs can't do is record definitively or relatively definitively what happened and what commands were run as root (and by who). If you need this level of knowledge and certainty, you need more than sudo logs. At the extreme you need SELinux level audit logs.

Update: It's been pointed out that recent versions of sudo can log all session IO and allow you to examine them after the fact. This adds stronger semi-auditing but not in any convenient form (consider how hard it would be to see the !}famt vs !}fmt error in an IO log, for example).