It has been possible to use wildcards in the sudoers file for many years. This can make configuration easier and more flexible, but it also introduces problems of its own. Regular expressions, introduced in in sudo 1.9.10, allow you to create more fine grained rules. From this blog you will learn about some of the problems when you use wildcards in your sudoers file, and how using regular expressions can resolve those problems.

We learned in my previous sudo blog that cvtsudoers is not just for LDAP. Version 1.9.9 of sudo extends the querying possibilities of cvtsudoers further and adds a brand new feature: merging multiple sudoers files into one. Both are especially useful when you have complex configurations. Querying lets you to better understand what the various rules allow in your sudoers file. Merging helps you to combine multiple configurations into one, so you do not have to maintain a separate sudoers file on each of your hosts.

The main feature of cvtsudoers is that it can convert between the sudoers file format and LDAP’s LDIF file format. As I do not use LDAP in my lab environment I stopped caring about cvtsudoers after I read the first few lines of its man page. However, cvtsudoers has additional features useful even without LDAP: querying the sudoers file and printing permissions belonging to a given user or host.

I must admit, I have no idea which version of sudo introduced the filtering (-m) option to cvtsudoers. I only know that the current openSUSE Leap and AlmaLinux versions already support it, with versions 1.9.5 and 1.8.29 respectively. If the version of sudo supplied with your operating system is too old, you can find up-to-date sudo packages for many Linux distributions and UNIX variants at https://www.sudo.ws/getting/packages/.

Version 1.9 of sudo was released almost two years ago. One of the major new features was support for Python plugins. Previously, you could only extend sudo by coding in C to better suit your environment, which is not the easiest task to manage. Python makes both coding and distributing the results easier. Starting with Safeguard for Sudo 7.2, Python support is also available in an enterprise sudo management solution.

A month ago, when sudo 1.9.8 was still under development, we checked out the new log_subcmds option. It allows you log all commands (with some limitations) that are executed by a command started through sudo. For example, you can see if a shell was started through a text editor. The intercept option brings this one step further: you can prevent sub-commands from even running.

To use sudo’s intercept option you need sudo 1.9.8 (or later). At the time of writing it is not available in any of the major Linux distributions. You can download ready-to-use binary packages for some Linux distributions and UNIX variants from the sudo website or build sudo yourself from source. Various BSDs also have an up-to-date version of sudo in ports.

Sudo development is at version 1.9.8 beta 3. There are two major new features: sudo can intercept sub-commands and log sub-commands. In this quick teaser I introduce you to log_subcmds. I hope it is interesting enough for you to test it out and provide feedback.

So, what is log_subcmds good for? There are many UNIX tools that can spawn external applications. You only see vi in the logs, but can you be sure without session recording that your admin only edits what he is supposed to? With log_subcmds you can see all the commands started from an application run through sudo. Or you can see all the commands started from a shell, even without session recording.

Using sudo_logsrvd to centrally collect sudo session recordings from your network is a huge step forward in security: users cannot delete or modify session recordings locally. However, by default, transmission of recordings is not encrypted, making it open to modifications and eavesdropping. Encrypting the connection between sudo and sudo_logsrvd can eliminate these problems. Larger environments usually either have in-house PKI tooling in place, or colleagues who know all openssl options off the top of their heads. However, small and medium enterprises often lack the infrastructure or knowledge to work with TLS certificates.

Relay mode was introduced to sudo_logsrvd in sudo version 1.9.7. But, first of all, what is sudo_logsrvd? It is the sudo recording service that allows you to collect sudo session recordings centrally. Using relay mode makes it possible to collect sudo session recordings even when the central service is inaccessible and provides you with a single exit point from your network.

In this blog you will learn why relay mode is important and how you can test it.

Sudo is an open source application allowing you to execute commands as another user. Safeguard for Privileged Sessions (SPS) by One Identity is commercial software that allows you to control, monitor and record privileged access. Starting with the upcoming SPS version 6.10 you will be able to collect and analyze sudo session recordings in SPS.

Session (I/O log) recording has been present in sudo for quite some time, but recordings were only saved locally. Replaying a sudo session like a movie was useful even locally, but a malicious user with shell access could easily delete the recordings. Starting with sudo version 1.9, it is possible to collect sudo session recordings centrally, which makes deleting session recordings a lot more difficult.

Before version 1.9 was released, alterting in sudo was limited to e-mail messages. If you wanted to send alerts somewhere else, like Slack, you could only do this using external applications, like syslog-ng. Beginning with sudo 1.9, there is an Audit API that can be called from Python.

Previously, we provided you with a simple example that show how to print some debug information to the terminal. In this blog post we will extend that example with Apprise, a universal Python notification library. By integrating with Apprise, you can easily send alerts to dozens of different messaging services directly from sudo itself.