== _sudo_ is not an auditing mechanism

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 http://www.kitchensoap.com/]].)

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