If there is one utility installed on almost all Linux/UNIX systems, it is sudo. Still, most sudo users – including myself until a year ago – only know this app as the prefix for administrative commands and using the default configuration. By the end of this blog you will know that it is a lot more. After a brief introduction to sudo you can learn a number of lesser know sudo features: digest check, configuration in LDAP, session recording, extensive logging and even plugins The current blog just introduces you to these features, in later blogs you can learn about them in depth.

By default, sudo comes with a simple configuration allowing a user or group of users to do anything with administrator privileges:

%wheel ALL=(ALL) ALL

This is OK, when you are the one and only user on your laptop, but for the rest it is probably a bit too permissive. Still, it is a lot better than handing out the root password for a machine on a piece of paper for those who need access to it. Not only because passwords stuck to a monitor are not the best idea, rather because when using a shared root account nobody knows who did what. When using sudo, even with the above simple settings you have a log of who did what. Like this one with my user name “czanik”:

Sep 13 12:09:47 linux-mewy sudo[28623]:   czanik : TTY=pts/1 ; PWD=/home/czanik ; USER=root ; TSID=000007 ; COMMAND=/usr/bin/ls /

You can find the configuration of sudo in the /etc/sudoers file. You should not edit this file directly, but should instead use the visudo command, which performs syntax checks on the new configuration before overwriting the previous version. You can change the default behavior of sudo here, create aliases to make your work easier and add rules to be a bit more restrictive than the rule above.

Customizing the sudoers file is worth a couple of blog posts alone, here I just want to give you an overview of some lesser known features.

If you store the SHA-2 digest of an application in the sudoers file, sudo will check the digest any time before the application is executed. Using digest check you can make sure that users can only execute unmodified binaries through sudo. Obviously it complicates the configuration of sudo (you need to update your sudoers file when you update software on your system), but with non-trusted users it can give an additional layer of protection.

Using session recording you can verify that your privileged users are using their privileges in the right way. With session recording, not only the command line but also the terminal output is recorded. You can play back sessions with sudoreplay and see everything that happened. Even if one of your users needs to start an interactive shell through sudo, you can see what commands were executed. Escaping to the shell from a text editor will no longer go unnoticed.

When you have many computers to maintain, one of the obvious choices to simplify your job is centralized configuration management. There are many different tools available for that, but sudo itself has built-in support for storing the configuration in LDAP.

This has the added benefit that users cannot modify it locally and circumvent sudo protection by editing the configuration. Rules propagate in real-time. On the other hand there are some limitations on what you can configure from LDAP. Learn more about it from the LDAP Readme and the sudoers.ldap manual!

There are three kinds of logs from sudo (or four, if you also count session recordings), and really there is not much point using sudo if you do not also check its log messages regularly. These are:

• all events are sent to syslog by default
• you can define e-mail alerts for specific events
• debug logs (hopefully you will never need them)

E-mail alerting is getting a bit old-fashioned, but as syslog messages contain all information about events, you can also use those for alerting. For example, you can forward your sudo events to a Slack channel so you can read them in real-time on your mobile or desktop. Here is an implementation for syslog-ng.

Version 1.8 of sudo introduced a plugin-based architecture. Most functionality of sudo is now implemented as plugins, so they can be extended or replaced by the user. The “Third-party Sudo Plugins” page on the sudo website lists some of them. For example, using the “sudo_pair” plugin, any command requires approval from another admin. The session can be followed on-screen and even terminated if necessary.

If you would like to be notified about new posts and sudo news, sign up for the sudo blog announcement mailing list.