Version 1.9.8 of sudo introduced support for logging and intercepting sub-commands. These features quickly became very popular. The original implementation is portable, however it also has a number of limitations. Version 1.9.11 of sudo introduced an alternative, Linux-specific, implementation that allows sudo to detect sub-commands in even more situations.

Version 1.9.11 of sudo was released very recently. There is a good chance that your OS of choice still has an earlier version. If you use one of the more popular Linux distributions, ready-to-install sudo packages are available on the sudo website at https://www.sudo.ws/getting/packages/.

Detecting sub-commands provides you with much better visibility into what your users are doing through sudo and gives you control as well. Both features were introduced earlier more in depth, here I just provide you with a quick overview:

Logging sub-commands allows you to see what happens inside a shell session or in an editor. Previously, sudo logs included only the very first command: the shell or editor a user started. Using auditd logs it was possible to see what was happening, but those logs can be difficult to work with. With built-in support for logging sub-commands, even commands executed from a bash profile on start-up are visible. You can read more about logging sub-commands at https://www.sudo.ws/posts/2021/08/what-is-coming-in-sudo-1.9.8/.

The other possibility is intercepting sub-commands. Even if a user has full root shell access, you can disable access to certain applications. Or, you can disable shell access entirely, so even if a user has access to an editor that can than start a shell, access to the shell can be prevented easily. You can read more about intercepting sub-commands at https://www.sudo.ws/posts/2021/10/sudo-1.9.8-intercepting-commands/.

In short, the old implementation operated at the C library level, wrapping execve(2) and related functions. This is portable and works on all platforms supported by sudo, but it does have some limitations. The new, Linux-specific implementation operates at the system call level using ptrace(2) and seccomp(2), so anything calling execve(2) will be trapped. It adds support for static binaries, support for 32-bit binaries running on a 64-bit kernel, and the new implementation should be compatible with SELinux (and other Linux security modules), unless your SELinux policy disables ptrace(2) (it is enabled by default).

The default is to use the new ptrace-based implementation where possible; the new intercept_type sudoers setting can be used to explicitly set the type.

If you use sudo on Linux, you should give sudo 1.9.11 a try and test the improvements yourself. Of course, even this change cannot detect the built-in commands of shells, but using the new implementation on Linux gives you even better visibility into what is happening on your hosts.

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