Version 1.9 of sudo is now feature complete: all major features are implemented. On the other hand, sudo 1.9 needs testing and a bit of polishing before it can be made generally available. This is where you can help. Testing is easy, as for most platforms the project provides ready-to-install packages. In this blog I will show you how to test the recording service.

• For an overview of 1.9 features see What is coming up in sudo 1.9?
• To get started with Python support in sudo, including compile instructions, see What’s new in sudo 1.9: Python

The recording service collects session recordings centrally, which offers many advantages compared to local storage:

• It is more convenient to search in one place
• Recordings are available even if the client machine is down
• Recordings cannot be deleted by a local user who wants to cover their tracks

In this blog, I will show you how to test the recording service. For production use, you can set up encrypted connection from sudo to the recording service. Here I only cover non-encrypted connections for simplicity’s sake. There are too many options to list when it comes to encryption, see the examples section in the documentation for instructions on setting up encrypted connections.

Note, that this is still beta software with possible bugs. It is good enough for testing and exploring new features, but production use is not currently recommended. As always, when you are experimenting with sudo: know the root password. Yes, even on Ubuntu. It is easy to create a syntactically correct configuration which shuts you out from your system.

To test the recording service you need to install sudo 1.9 beta at least on two different hosts. My tests were carried out on CentOS 7. When you are testing on a different operating system everything should work similarly except for package management commands.

Go to the sudo website to download binaries for your platform:

• Generic development release information: https://www.sudo.ws/devel.html
• Downloads: https://www.sudo.ws/dist/beta/packages/index.html
• Manuals: https://www.sudo.ws/man.html

In case of CentOS 7 it’s as easy as:

wget https://www.sudo.ws/sudo/dist/beta/packages/RHEL/7/sudo-1.9.0rc3-1.el7.x86_64.rpm
rpm -Uvh sudo-1.9.0rc3-1.el7.x86_64.rpm
wget https://www.sudo.ws/sudo/dist/beta/packages/RHEL/7/sudo-logsrvd-1.9.0rc3-1.el7.x86_64.rpm
rpm -ivh sudo-logsrvd-1.9.0rc3-1.el7.x86_64.rpm

Of course, by the time you get around to testing, the file name might be different. Check the download page for the exact file name.

As I mentioned earlier, you will need at least two hosts: a server to collect session recordings, and one (or more) clients to send their session recordings to the server.

If you do not use encrypted connections or a non-standard port number, you do not need create or edit /etc/sudo_logsrvd.conf at all. Just use the default settings and you are ready to go. All you need is to make a note of the server host’s IP address, you will need it when you configure the client side. On the client side you need to add two lines to your configuration: one to enable session recording and a one to tell sudo where to send it.

Start visudo and append the following lines to your configuration:

Defaults log_output
Defaults log_servers=172.16.167.128

Obviously, you will need to change the IP address on the second line to match your own environment.

Now login as a regular user who is allowed to use sudo (a member of the wheel group on most systems) and try to execute a command:

[czanik@centos7sudo ~]$ sudo ls /root/
[sudo] password for czanik: 
sudo: connect: Connection refused
sudo: unable to connect to log server
sudo: error initializing I/O plugin sudoers_io

By default, sudo refuses to run a command if the central session recording service is unavailable. You will need to start sudo_logsrvd on the central server. The sudo-logsrvd package includes an init.d script and a systemd service file, but for debugging purposes you can also start it from the command line:

[root@centos7 ~]# sudo_logsrvd -n

By using the -n line option, the command starts in the foreground so you can easily stop it later on using ^C. Now try to run something through sudo on the client host. This time it should work as expected. Go back to the host running the recording service and list recorded sessions. The output should be similar:

[root@centos7 ~]# sudoreplay -l
Mar 17 16:26:01 2020 : czanik : TTY=/dev/pts/0 ; CWD=/home/czanik ; USER=root ; TSID=000001 ; COMMAND=/bin/ls /root/
And /var/log/messages should have a similar log message:
Mar 17 16:26:01 centos7 sudo[9753]:   czanik : HOST=centos7.localdomain ; TTY=/dev/pts/0 ; PWD=/home/czanik ; USER=root ; TSID=000001 ; COMMAND=/bin/ls /root/

As you can see, there are still a few rough edges. These are being worked on and future beta releases will most likely include them. Here are a couple of items from our ToDo list:

• package Python support (for now you can use instructions from the previous blog)
• systemd service file to start sudo_logsrvd
• display originating host name in sudoreplay session listings

The above items were all spotted during user testing. Help us make sudo 1.9 a great release by testing and providing feedback! This way similar problems can be fixed before sudo 1.9 is made generally available. By being an early adopter you can enhance security at your site more quickly once 1.9 is released.

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