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 asroot
. 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 throughsudo
. 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 followingsudo
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, sinceless
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 afamt
command. This isn't logged bysudo
, 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 ofvi
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 runfamt
, I was just editing a file, andsudo
'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).
Comments on this page:
|
|