I'm asking myself whether system security substantially increases when I generate a security policy, i.e. sudoers file which contains one or more Cmnd_Alias definitions that enumerate all executable files prefixed by their SHA-2 checksums under directories such as /usr/bin, /usr/sbin etc.

Upon updating the system with packages from a trusted source I would then regenerate the security policy.

Any insights whether this is a good or bad idea?

3 Answers 3


Sounds like a huge pain to me. I don't think you're actually gaining anything in security, either, as those (a) can only be written as root, so already likely game over if someone can write to them; (b) likely load a bunch of shared libraries, which aren't being checked.

The sudoers manpage says the option "may be useful in situations where the user invoking sudo has write access to the command or its parent directory." I'm not sure who thought that setup would be a good idea, or for that matter how sudo does a checksum before exec w/o a race condition.

I suggest looking into a host-based IDS (e.g., samhain, tripwire, ...) instead. Those will attempt to quickly detect and report any tampering with system binaries (including shared libraries), regardless of whether anyone is attempting to sudo.


If you allow running almost any binary in the system binary directories, with arbitrary arguments, you almost certainly have allowed arbitrary access. Among other things, if you allow running an editor with arbitrary arguments, or mv, or a shell like bash, or a package manager like dpkg, or any program that supports writing data to files, then someone could easily use that to become the user you allow sudo to. Blacklisting commands will not work either; there are too many different ways to turn execution of a command into privilege escalation.

With sudo, you should either allow a very specific limited set of commands (with specific arguments), or allow all commands.

If you want to detect modifications to system files, you should use another mechanism for that. If someone has sufficient access to modify system binaries, they likely have enough access to change the sudoers file as well.


The other answer covers the hassle, I just want to point out that securing the sudoers file contents needs to also be consider what the checksums will not protect against...

Lets say you have the following in the sudoers file and you only want low priv users to use the apache binary (I have not provided a sha-2 checksum example as it will complicate the point I am trying to make)

Cmnd_Alias HTTPD = /etc/sbin/httpd
low_priv_user ALL=(ALL) NOPASSWD: HTTPD

Take a look at the error log if the low privileged user tried

sudo /etc/sbin/httpd -t /etc/shadow

So yes indexed checksums on the binaries and a way to manage could in theory improve the security if done right, though I suspect command availability (one of the three foundations of security) would be more at risk. You would still need to secure/harden other areas of the host.

I guess it all depends how much the assets you are protecting are worth versus the management overhead and the risk reduction that checksummed binaries give.

You must log in to answer this question.

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