É provável que o (s) administrador (es) de um sistema deseje saber quando um usuário não privilegiado tenta, mas falha ao executar comandos usando sudo . Se isso acontecer, pode ser um sinal de
- um usuário legítimo curioso que está experimentando ou
- um hacker tentando fazer "coisas ruins".
Como sudo por si só não consegue distinguir entre eles, as tentativas malsucedidas de usar sudo são levadas ao conhecimento dos administradores.
Dependendo de como o sudo está configurado em seu sistema, qualquer tentativa (bem-sucedida ou não) de usar sudo será registrada. Tentativas bem-sucedidas são registradas para fins de auditoria (para poder acompanhar quem fez o quê) e falhas de segurança.
Em uma configuração Ubuntu bem bajuladora que eu tenho, isso está registrado em /var/log/auth.log .
Se um usuário fornecer a senha errada três vezes ou se não estiver no arquivo sudoers , um email será enviado para o root (dependendo da configuração de sudo , veja abaixo). Isso é o que significa "esse incidente será relatado".
O email terá um assunto de 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 nobody tentou executar ls a sudo como root, mas falhou porque não estavam no arquivo sudoers ).
Nenhum email é enviado se o email (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.
Veja a configuração mail_no_user (e as configurações mail_* relacionadas) no manual sudoers (minha ênfase abaixo):
mail_no_userIf set, mail will be sent to the mailto user if the invoking user is not in the
sudoersfile. This flag is on by default.