Utilizando o auditd para capturar avisos de “permissão negada”

Question

Estou tentando descobrir como registrar / rastrear quando um usuário recebe Permission denied notice após tentar acessar um arquivo. Eu li que adicionar uma regra ao /etc/audit/audit.rules pode fazer isso.

A única sugestão que vi mencionada parece não funcionar como pretendido. Ou, pelo menos, não faz o que eu gostaria. Muito bem pode funcionar da maneira como está escrito. A regra é

-a always,exit -F arch=b64 -S open -F success!=0

Na verdade, a sugestão no link acima não inclui a opção arch. Eu tive que adicionar isso.

Ao seguir /var/log/audit/audit.log , estou vendo tudo o que diz success=yes . Isso inclui quando clico em uma janela e altero o foco ou insiro combinações de teclas para alterar entre as funções da janela. O que eu não estou vendo é nada relacionado a Permission denied para incluir success=no entradas ou qualquer coisa sobre um arquivo específico que eu tente abrir sabendo que eu não tenho permissões nele.

Tudo o que posso dizer definitivamente é que quando eu grep para success=no in /var/log/audit/audit.log nada é retornado.

Qual deve ser a regra? Ou melhor ainda, isso é realmente possível? A solução está incorreta?

    

Answer 1

Eu trabalhei com ferramentas e descobri que, se eu usar success!=1 , então audit.log exibirá as entradas que indicam success=no . Isso parece contra-intuitivo para mim, pois um código de saída diferente de zero normalmente indica uma falha de algum tipo, mas !=1 poderia ser qualquer coisa, incluindo outros códigos de saída de falha, bem como um sucesso ( 0 ). Curiosamente, porém, esses não aparecem.

Um problema adicional é que ele não indica qual arquivo teve o acesso com falha. Em vez disso, ele lista apenas o comando executado quando o código de saída com falha foi retornado. No meu caso, eu estava executando cat /etc/shadow . Então, ao invés de ver

type=SYSCALL msg=audit(1438754257.463:11451): arch=c000003e syscall=2 success=no exit=-13 a0=7ffea511f35f a1=0 a2=1ffffffffffe0000 a3=0 items=1 ppid=1650 pid=5489 auid=1000 uid=1000 gid=100 euid=1000 suid=1000 fsuid=1000 egid=100 sgid=100 fsgid=100 tty=pts0 ses=1 comm="cat" exe="/usr/bin/cat" key="access"
type=CWD msg=audit(1438754257.463:11451):  cwd="/home/msnyder"
type=PATH msg=audit(1438754257.463:11451): item=0 name="/etc/shadow" inode=1131047 dev=00:20 mode=0100640 ouid=0 ogid=15 rdev=00:00 nametype=NORMAL

Eu só veria

type=SYSCALL msg=audit(1438752096.223:4952): arch=c000003e syscall=2 success=yes exit=3 a0=7f77d575c057 a1=80000 a2=1 a3=22 items=1 ppid=1650 pid=4873 auid=1000 uid=1000 gid=100 euid=1000 suid=1000 fsuid=1000 egid=100 sgid=100 fsgid=100 tty=pts0 ses=1 comm="cat" exe="/usr/bin/cat" key=(null)
type=CWD msg=audit(1438752096.223:4952):  cwd="/home/msnyder"

Em seguida, observei a% man_de% manpage. Eureka! A resposta estava lá o tempo todo:

-a always,exit -F arch=b64 -S open,openat -F exit=-EACCES -F key=access
-a always,exit -F arch=b64 -S open,openat -F exit=-EPERM -F key=access

Essas duas regras combinadas resolvem o problema. Não só registrará o acesso a arquivos com falha, mas também registrará em qual arquivo o acesso foi tentado. Isso resulta nas três primeiras entradas de log acima, incluindo o nome do arquivo.