The Linux sudo command helps Linux administrators run specific programs in the context of another user, typically root. In this way, non-privileged users can run management programs on a system. The tool writes to a log to keep track of users who used sudo to run programs. The default format has been plain text, but from version 1.9.4, it can be configured to log in JSON format.

sudo Logging

By default, sudo uses syslog to send log messages, which means that, on a Linux system, the messages end up in the system journal. You can choose between JSON and sudo plain text as the log format. Text ensures that the messages are easy to read while keeping the amount of information that ends up in the log to a minimum (Figure 1).

Figure 1: By default, sudo uses an easy-to-read plain text log format for all messages routed by syslog.

If you are looking for more information on a sudo log event, you can change the format of the log message to JSON, which makes several data fields available in the journal (Figure 2). You will find more detailed information on the individual fields of the log format by entering

man 5 sudoers

for the sudoers help page.

Figure 2: Log messages in JSON format provide more information.

Logging Child Processes

Starting in version 1.9.8, a sudo option lets you log the child processes of the application launched by sudo [1]. For example, if you authorize a user to launch an editor with sudo, you would normally only see the call to the editor command in the logfile. However, if the user calls other commands from inside the editor, these calls are not shown in the logs. The case in which you potentially give a user the right to launch a new shell with sudo to gain complete root access to the system is particularly interesting. In the logs, you would only see the call to the shell, but not which tools were launched in the shell session.

To log all commands of a sudo session, you can use the log_subcmds option within the sudoers file. Of course, a large number of log messages will then end up in the journal, which will be almost impossible to analyze manually, and you will very likely overlook information that could help you track specific actions on a system.

Central Log

To solve this problem, it makes sense to collect all log messages from the individual computers on a central system, where they can then be managed and analyzed with your preferred log management software, such as Elasticsearch. Luckily, sudo can also store the log entries in a regular file instead of routing them by syslog. You can then use the machine-readable JSON format to process the sudo messages automatically.

However, sudo previously used a human-readable JSON format when writing messages to a file:

{
    "accept": {
      "server_time": {
        "seconds": 1716370731,
        "nanoseconds": 137298080,
        "iso8601": "20240522093851Z",
        "localtime": "May 22 09:38:51"
      },
      [...]
    },
  }

This file is easy to read because the log message comprises several lines of data fields, which facilitates finding the desired information. However, you might prefer sudo to output the same compact JSON format used when you route the messages to the local journal by syslog, and this is precisely what you can do with the current sudo 1.9.16 version.