sudo is not an auditing mechanism

December 4, 2013

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

Comments on this page:

By Alex at 2013-12-04 04:20:54:

you may want to look at the recently added SUDOREPLAY command.

There's also pam_tty_audit, which I don't personally like using but it got a PCI auditor off my back once.

What about the noexec option in sudo. That should take care of shell escapes. Also, a long time ago, I had seen a kludgy solution to the "lack of audit" issue...where a combination of screen was used in conjunction with sudo, that would essentially track all keystrokes with associated during a sudo-initiated session.

By cks at 2013-12-04 10:56:40:

I don't believe that noexec is viable if sudo is to be the mechanism sysadmins use to get general root permissions. Too many general commands want to exec() something in the process of running, not to mention shell scripts and so on.

Written on 04 December 2013.
« The three faces of sudo
Some thoughts on a body of knowledge for system administration »

Page tools: View Source, View Normal, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Wed Dec 4 01:31:10 2013
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.