Collection Point

The sudo tool lets users run programs with any account, as long as it has been allowed explicitly up front. Administrators can thus hand control over certain areas of the system to other users. For example, you could assign someone the rights in the sudo configuration file /etc/sudoers to create, delete, or modify users on a system with the visudo statement:

visudo <foobar> ALL=(ALL) /usr/sbin/useradd, /usr/sbin/userdel, /usr/sbin/usermod

If the <foobar> user now wants to execute one of these admin commands, they simply prepend the sudo command to the program to be executed. For newcomers to the world of sudo, a look at the help pages for the configuration file /etc/sudoers (man sudoers) is recommended to get an overview of how the sudo configuration can look in detail.

I/O Logging with sudo

A special feature of sudo is I/O logging, which lets you tell sudo to execute every command inside a pseudo-terminal to log all input and output. This feature is very useful if you want to create an audit trail for a user on the basis of certain compliance requirements. Previously, sudo could only store logfiles locally when generated in this way. However, since version 1.9, you can also store them on a remote machine.

To activate local logging of all inputs and outputs of a user session with visudo, add the Defaults log_output statement to the existing configuration. If a user now uses the sudo command, a new log is created for each session in the directory /var/log/sudo-io. If you prefer to store the logs in a different folder, you can specify the folder with the iolog_dir configuration option in the sudoers file. In addition to the user data, the logs also contain timestamps, so you can replay a session in real time. An overview of the log sessions generated by sudo is shown by sudoreplay -l. Each session is marked with a unique ID (TSID), which can be passed to sudoreplay to replay a session:

sudoreplay 000001

The tool now shows you the complete sudo session at the original speed. However, you can set the execution speed (-s) and the maximum permissible length (-m) of a pause between running two commands.

Logging Data over the Network

At this point, the logfiles generated by sudo are always stored locally. However, quite a few compliance requirements stipulate that logfiles be stored in a central location so that it is no longer possible to modify the logs, even after a successful attack. For purely practical reasons, it also makes sense to store the logs on a centralized and specially secured server.

Classic logging services such as syslogd or journald offer such a function, but the sudo tool also supports remote logging since version 1.9 [1]. To store logs on a remote machine, the sudo_logsrvd service is now part of the sudo source code [2]. The server accepts sudo logs from client systems on a network port. By default, the service listens on TCP port 30343, and TCP port 30344 is used for encrypted traffic.

Certificates for Secure Communication

For test purposes, transmitting the sudo logs in plaintext may be acceptable, but for production use, encrypted transmission of the data is indispensable, for which the server needs its own X.509 certificate, which you have to store in the /etc/sudo_logsrvd.conf configuration file along with the corresponding private key and the certificate from the certification authority (CA) that issued the certificate for sudo_logsrvd. Listing 1 shows an example transport layer security (TLS) configuration.

tls = true
listen_address = *:30344(tls)
tls_cacert = /etc/pki/tls/cert.pem
tls_cert = /etc/pki/tls/certs/logsrvd-cert.pem
tls_key = /etc/pki/tls/certs/private/logsrvd-key.pem

The man sudo_logsrvd help page contains some instructions on how to generate a self-signed X.509 certificate with an OpenSSL-based certificate for test purposes. For serious testing, however, you should have a certificate issued by a CA that is already trusted on your systems. If the certificate is issued by another authority, you must first deposit it in the certificate stores of all your systems; otherwise, the certificate cannot be verified successfully, and transferring the sudo log data fails.

After including the certificate, you can finally start sudo_logsrvd. The prebuilt packages on the sudo website [3] have both a systemd and a SysVinit script. If you use the sudo packages from the repository of your Linux distribution, some of the packages may be somewhat outdated and might not offer an init script yet. On Fedora 33, I used the following packages:

rpm -qa sudo*
sudo-1.9.2-1.fc33.x86_64
sudo-logsrvd-1.9.2-1.fc33.x86_64

However, the sudo-logsrvd package does not yet contain an init script, so you have to start the service manually by calling sudo_logsrvd. The process moves directly into the background to avoid blocking the shell. If you would rather it run in the foreground, you can simply use the -n option when starting the service. To verify that sudo-logsrvd was started successfully, you can call netstat with the

netstat -tlpn | grep sudo_logsrvd

command.

Client Configuration for Secure Data Transmission

To let the client know to which system to send the sudo logs, use visudo to add the following statements to the sudoers file:

Defaults log_servers=<IP address>:30344(tls)
Defaults log_server_cabundle=/etc/pki/tls/cert.pem

Of course, you will need to replace <IP address> with the IP address of the system on which you just set up the sudo_logsrvd service. From now on, the client's sudo session logs will end up on the central logging system. A call to sudoreplay -l should confirm this.

Conclusions

In the new 1.9 version, sudo now offers the ability to store I/O logs on remote systems. A new sudo_logsrvd service exists for this purpose, and it can communicate with clients over a secure TLS channel. To structure the data to be transmitted, sudo uses Google's Protocol Buffer Language [4].