O que faz o erro "X não está no arquivo sudoers. Este incidente será relatado." filosoficamente/logicamente significa?

É provável que o(s) administrador(es) de um sistema queiram saber quando um usuário não privilegiado tenta, mas não consegue executar comandos usando sudo. Se isso acontecer, pode ser um sinal de

1. um usuário legítimo curioso apenas experimentando coisas, ou
2. um hacker tentando fazer "coisas ruins".

Uma vez que sudopor si só não pode distinguir entre eles, as tentativas fracassadas de uso sudosão levadas ao conhecimento dos administradores.

Dependendo de como sudoestá configurado em seu sistema, qualquer tentativa (bem sucedida ou não) de uso sudoserá registrada. As tentativas bem-sucedidas são registradas para fins de auditoria (para poder acompanhar quem fez o quê e quando) e as tentativas com falha por segurança.

Em uma configuração bastante baunilha do Ubuntu que eu tenho, isso está logado no /var/log/auth.log.

Se um usuário der a senha errada três vezes, ou se ela não estiver no sudoersarquivo, um e-mail é enviado para o root (dependendo da configuração do sudo, veja abaixo). Isso é o que significa "este incidente será relatado".

O e-mail terá um assunto em destaque:

Subject: *** SECURITY information for thehostname ***

O corpo da mensagem contém as linhas relevantes do arquivo de log, por exemplo

thehostname : Jun 22 07:07:44 : nobody : user NOT in sudoers ; TTY=console ; PWD=/some/path ; USER=root ; COMMAND=/bin/ls

(Aqui, o usuário tentou nobodyexecutar como root, mas falhou, pois não estava no arquivo).lssudosudoers

Nenhum e-mail é enviado se o e-mail (local) não tiver sido configurado no sistema.

Todas essas coisas também são configuráveis, e as variações locais na configuração padrão podem diferir entre as variantes do Unix.

Dê uma olhada na mail_no_userconfiguração (e mail_*configurações relacionadas) no sudoersmanual (minha ênfase abaixo):

mail_no_user

Se definido, o correio será enviado ao usuário mailto se o usuário que está chamando não estiver no sudoersarquivo. Este sinalizador está ativado por padrão .

No Debian e seus derivados, os sudorelatórios de incidentes são registrados nos /var/log/auth.logquais contém informações de autorização do sistema, incluindo logins de usuários e mecanismos de autenticação que foram usados:

$ 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

Este arquivo de log normalmente é acessível apenas aos usuários do admgrupo, ou seja, usuários com acesso às tarefas de monitoramento do sistema :

$ ls -la /var/log/auth.log
-rw-r----- 1 syslog adm 76189 Jun 21 16:30 /var/log/auth.log

Do Debian Wiki :

O grupo adm é usado para tarefas de monitoramento do sistema. Os membros deste grupo podem ler muitos arquivos de log em /var/log e podem usar o xconsole. Historicamente, /var/log era /usr/adm (e depois /var/adm), daí o nome do grupo.

Os usuários do admgrupo geralmente são administradores , e essa permissão de grupo destina-se a permitir que eles leiam arquivos de log sem precisar su.

Por padrão , sudousa o recurso Syslog authpara registro . sudoo comportamento de log do pode ser modificado usando as opções logfileou em ou :syslog/etc/sudoers/etc/sudoers.d

• A logfileopção define o caminho para o sudoarquivo de log.
• A syslogopção configura o recurso Syslog quando syslog(3)está sendo usado para registro.

O recurso Syslog authé redirecionado /var/log/auth.logpela etc/syslog.confpresença da seguinte sub-rotina de configuração:

auth,authpriv.*         /var/log/auth.log

Tecnicamente, isso não significa muita coisa. Muitos (se não todos) outros softwares registram logins, com falha ou não. Por exemplo sshde 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

Além disso, muitos sistemas possuem algum tipo de automação para detectar erros excessivos de autenticação para poder lidar com possíveis tentativas de força bruta ou apenas usar as informações para reconstruir eventos após o aparecimento de problemas.

sudonão faz nada de especialmente excepcional aqui. Tudo o que a mensagem significa é que o autor de sudoparece ter adotado uma filosofia um tanto agressiva na comunicação com usuários que executam comandos que eles não podem usar.

Significa simplesmente que alguém tentou usar o sudocomando (para acessar privilégios de administrador), que não tem autorização para usá-lo (porque não está listado no arquivo sudoers). Isso pode ser uma tentativa de hacking ou algum outro tipo de risco de segurança, então a mensagem está dizendo que a tentativa de uso sudoserá relatada ao administrador do sistema, para que eles possam investigar.