What does the error "X is not in the sudoers file. This incident will be reported." philosophically/logically mean?
The administrator(s) of a system are likely to want to know when a non-privileged user tries but fails to execute commands using sudo
. If this happens, it could be a sign of
- a curious legitimate user just trying things out, or
- a hacker trying to do "bad things".
Since sudo
by itself can not distinguish between these, failed attempts to use sudo
are brought to the attention of the admins.
Depending on how sudo
is configured on your system, any attempt (successful or not) to use sudo
will be logged. Successful attempts are logged for audit purposes (to be able to keep track of who did what when), and failed attempts for security.
On a fairly vanilla Ubuntu setup that I have, this is logged in /var/log/auth.log
.
If a user gives the wrong password three times, or if they are not in the sudoers
file, an email is sent to root (depending on the configuration of sudo
, see below). This is what's meant by "this incident will be reported".
The email will have a prominent subject:
Subject: *** SECURITY information for thehostname ***
The body of the message contains the relevant lines from the logfile, for example
thehostname : Jun 22 07:07:44 : nobody : user NOT in sudoers ; TTY=console ; PWD=/some/path ; USER=root ; COMMAND=/bin/ls
(Here, the user nobody
tried to run ls
through sudo
as root, but failed since they were not in the sudoers
file).
No email is sent if (local) mail has not been set up on the system.
All of these things are configurable as well, and that local variations in the default configuration may differ between Unix variants.
Have a look at the mail_no_user
setting (and related mail_*
settings) in the sudoers
manual (my emphasis below):
mail_no_user
If set, mail will be sent to the mailto user if the invoking user is not in the
sudoers
file. This flag is on by default.
In Debian and its derivatives, the sudo
incident reports are logged to /var/log/auth.log
which contains system authorization information, including user logins and authentication mechanisms that were used:
$ sudo su
[sudo] password for regularjohn:
regularjohn is not in the sudoers file. This incident will be reported.
[as root]
$ tail -n 1 /var/log/auth.log
Jun 21 16:30:26 marvin sudo: regularjohn : user NOT in sudoers ; TTY=pts/19 ; PWD=/home/regularjohn ; USER=root ; COMMAND=/bin/su
This log file is typically only accessible to users in the adm
group, i.e. users with access to system monitoring tasks:
$ ls -la /var/log/auth.log
-rw-r----- 1 syslog adm 76189 Jun 21 16:30 /var/log/auth.log
From the Debian Wiki:
Group adm is used for system monitoring tasks. Members of this group can read many log files in /var/log, and can use xconsole. Historically, /var/log was /usr/adm (and later /var/adm), thus the name of the group.
Users in the adm
group are usually administrators, and this group permission is intended to allow them to read log files without having to su
.
By default sudo
uses the Syslog auth
facility for logging. sudo
's logging behavior can be modified using the logfile
or syslog
options in /etc/sudoers
or /etc/sudoers.d
:
- The
logfile
option sets the path to thesudo
log file. - The
syslog
option sets the Syslog facility whensyslog(3)
is being used for logging.
The Syslog auth
facility is redirected to /var/log/auth.log
in etc/syslog.conf
by the presence of the following configuration stanza:
auth,authpriv.* /var/log/auth.log
Technically, it doesn't mean anything much. Many (if not all) other software logs logins, failed or otherwise. For example sshd
and su
:
Jun 21 17:52:22 somehost sshd[25807]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=::1 user=root
Jun 21 17:52:22 somehost sshd[25807]: Failed password for root from ::1 port 37268 ssh2
Jun 21 17:52:23 somehost sshd[25807]: Connection closed by ::1 port 37268 [preauth]
Jun 21 17:52:28 somehost su[25809]: pam_unix(su:auth): authentication failure; logname= uid=1000 euid=0 tty=/dev/pts/15 ruser=someuser rhost= user=root
Jun 21 17:52:28 somehost su[25809]: pam_authenticate: Authentication failure
Jun 21 17:52:28 somehost su[25809]: FAILED su for root by someuser
Also, many systems have some sort of automation for detecting excessive authentication errors to be able to deal with possible brute-force attempts, or just use the information to reconstruct events after problems appear.
sudo
doesn't do anything especially exceptional here. All the message means is that the author of sudo
appears to have taken a somewhat aggressive philosophy in communicating with users that happen to run commands they cannot use.