1. Overview

When using the sudo command in Linux, we can gain root access to perform certain activities. However, not all users have this access.

When someone attempts to raise their access level without permission to do so, then a report is written. We may wish to customize or review these reports.

In this tutorial, we look at where to find the sudo reports, how we can customize them, and how to send them via email.

2. Typical sudo Incident Reports

Let’s see how a system reacts to a failed executed event. Let’s imagine a user tries sudo without the proper permissions:

[unprivileged_user@host ~]$ sudo ls /root
[sudo] password for unprivileged_user:
unprivileged_user is not in the sudoers file. This incident will be reported.

Here we can see that system denies access and warns that the event is being reported.

We would expect to find the details of the attempt in the logs:

Mar 22 21:51:07 fedora sudo[2866]: unprivileged_user : user NOT in sudoers ; TTY=pts/1 ; PWD=/home/unprivileged_user ; USER=root ; COMMAND=/usr/bin/ls /root

Therefore, as an administrator, we can find out who tried to access sudo along with the details of when and how.

3. sudo Logging Reports

There are two places to find the logs of failed sudo attempts: the journalctl service and the rsyslog standard logfiles.

3.1. The journalctl Command

Linux collects logging data from various resources and services. We can access it with the journalctl command, which is part of the systemd-journald.service.

We can invoke the command with no parameters to find all logs. However, for this purpose, let’s apply a filter by specifying the absolute file path of the command we’re interested in:

$ journalctl /usb/bin/sudo
Apr 08 07:07:59 fedora sudo[3567]: unprivileged_user : TTY=pts/0 ; PWD=/home/unprivileged_user ; USER=root ; COMMAND=/usr/bin/less /etc/shadow
May 11 16:53:11 ubuntu sudo[22373]: tester : TTY=pts/0 ; PWD=/home/tester ; USER=root ; COMMAND=/etc/init.d/apache2 start

Even with this filter, the journalctl command might show us events we’re not interested in. Therefore, to focus on errors, let’s add the priority flag -p with value 3 (error status):

$ journalctl -p 3 /usr/bin/sudo
Mar 22 20:08:28 fedora sudo[3944]: unprivileged_user : user NOT in sudoers ; TTY=pts/1 ; PWD=/home/unprivileged_user ; USER=root ; COMMAND=/usr/bin/less /etc/shadow
Mar 22 23:25:20 fedora sudo[3944]: unprivileged_user : user NOT in sudoers ; TTY=pts/1 ; PWD=/home/unprivileged_user ; USER=root ; COMMAND=/usr/bin/service httpd stop

3.2. sudo Logfiles

The default log file containing sudo incidents depends on the specific Linux distribution. More specifically, for the most common Linux operating systems, the log files can be found in different files:

  • RPM-flavor (CentOS, Fedora) – /var/log/secure
  • Debian-Ubuntu flavor (Ubuntu) – /var/log/auth.log
  • openSUSE – /var/log/messages

We can customize these log files by editing /etc/sudoers along with the rsyslogd system configuration files.

We start editing the configuration file by invoking:

$ sudo visudo

and then insert the following line to set an alternative event logging file:

Defaults syslog=local1

Next, by using a text editor of our preference, we edit the /etc/rsyslog.conf file (/etc/rsyslog.d/50-default.conf for Ubuntu OS). We need to associate the local1 facility directive with the desired new log file. For this, we add the next line at the top of the other defined logging facilities:

local1.* /var/log/sudo.log

Finally, to activate the changes, we restart the rsyslogd service:

$ sudo systemctl restart rsyslog

4. sudo Reports via Email

If we prefer, we can communicate sudo warnings and generic information by email. We can customize this by editing the /etc/sudoers configuration file.

4.1. Email Options

Let’s try configuring our system to produce a report via email. To start, we define the email account that will collect the final report by adding some directives:

Defaults        mailto="ubuntu@localhost"
Defaults        env_reset
Defaults        mail_no_user  
Defaults        secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin"

Now, let’s see what happens when a non-privileged user tester attempts to set up a crontab job:

$ sudo crontab -e
[sudo] password for tester: 
tester is not in the sudoers file.  This incident will be reported.

As the user tester is not allowed to perform such action, the system launches a warning via email to the mailto email address ubuntu@localhost.

If we access the ubuntu user local mailbox with:

$ mail

then we can read the logged warning:

N 7 tester@ubuntu Wed May 11 19:16 16/581 *** SECURITY information for ubuntu ***

In this email, we are able to read the full log related to this event:

& 7
Message 7:
From tester@ubuntu  Wed May 11 19:16:06 2022
X-Original-To: ubuntu@localhost
To: ubuntu@localhost
From: tester@ubuntu
Auto-Submitted: auto-generated
Subject: *** SECURITY information for ubuntu ***
Date: Wed, 11 May 2022 19:16:06 +0000 (UTC)

ubuntu : May 11 19:16:06 : tester : user NOT in sudoers ; TTY=pts/0 ; PWD=/home/tester ; USER=root ; COMMAND=/usr/bin/crontab -e

Similarly, we can customize an email trigger with alternative options, such as when a user executes a sudo command with an incorrect password (Defaults mail_badpass) or when a sudo user executes commands not listed in the sudoers file entry or explicitly denied (Defaults mail_no_perms).

5. Conclusion

In this article, we saw how to find log entries notifying us about users attempting to use sudo without permissions.

We saw how to use journalctl and how to find the log files. We also looked at how to configure logging and how to trigger email messages on violations of the sudo policy.