O que está impedindo o auditd de gravar gravações pelo Syslog ao assistir a um arquivo Syslog?

Question

Recentemente, começamos a usar o auditd em um de nossos servidores Ubuntu.

O exemplo do arquivo audit.rules que recebemos tem uma regra como esta:

-w /var/log/syslog -p wra -k logs

No entanto, quando o syslog grava no arquivo, nada é registrado pelo auditd. Da mesma forma, se eu for para a linha de comando e executar o comando logger , o arquivo syslog será gravado sem gerar um log de auditoria. Se eu alterar o arquivo diretamente usando um editor ou anexando uma linha a ele a partir da linha de comando, ele será registrado.

Claro, eu não quero um registro de auditoria toda vez que o syslog for escrito, mas estou interessado em saber o que faz com que isso aconteça e se houver outros casos além do syslog em que isso poderia estar acontecendo sem o meu conhecimento.

Muito obrigado!

Informações adicionais:

Teste o arquivo audit.rules:

-D
-b 8192
-f 1
-w /var/log/syslog -p wra -k logs

Saída de auditctl -l e augenrules --check :

# auditctl -l
-w /var/log/syslog -p rwa -k logs

# augenrules --check
/sbin/augenrules: Rules have changed and should be updated

Usando o registrador:

# logger "logger example"
# ausearch -k logs
----
time->Fri Mar 10 14:35:20 2017
type=CONFIG_CHANGE msg=audit(1489156520.983:4463): auid=4294967295 ses=4294967295 op="add_rule" key="logs" list=4 res=1

Usando o redirecionamento de eco e saída:

# echo "echo example" >> /var/log/syslog
# ausearch -k logs
----
time->Fri Mar 10 14:35:20 2017
type=CONFIG_CHANGE msg=audit(1489156520.983:4463): auid=4294967295 ses=4294967295 op="add_rule" key="logs" list=4 res=1
----
time->Fri Mar 10 14:36:52 2017
type=PROCTITLE msg=audit(1489156612.334:4465): proctitle="bash"
type=PATH msg=audit(1489156612.334:4465): item=1 name="/var/log/syslog" inode=417506 dev=08:01 mode=0100640 ouid=104 ogid=4 rdev=00:00 nametype=NORMAL
type=PATH msg=audit(1489156612.334:4465): item=0 name="/var/log/" inode=411799 dev=08:01 mode=040775 ouid=0 ogid=108 rdev=00:00 nametype=PARENT
type=CWD msg=audit(1489156612.334:4465):  cwd="/etc/audit"
type=SYSCALL msg=audit(1489156612.334:4465): arch=c000003e syscall=2 success=yes exit=3 a0=a93108 a1=441 a2=1b6 a3=7ffe24385b98 items=2 ppid=28462 pid=28463 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts18 ses=4294967295 comm="bash" exe="/bin/bash" key="logs"

Cauda do / var / log / syslog:

# tail -n 2 /var/log/syslog
Mar 10 14:36:40 testserver root: logger example
echo example

    

Answer 1

Eu entendi a razão por trás desse comportamento.

A página auditctl man para os estados -p flag:

Describe the permission access type that a file system watch will trigger on. r=read, w=write, x=execute, a=attribute change. These permissions are not the standard file permissions, but rather the kind of syscall that would do this kind of thing. The read & write syscalls are omitted from this set since they would overwhelm the logs. But rather for reads or writes, the open flags are looked at to see what permission was requested.

Eu não entendi o que isso significava na época, mas depois de algumas horas pesquisando na lista de discussão do Linux-Audit, percebi que isso significa que, se você assiste a um arquivo para escrever, ele não t log quando há um syscall para gravar no arquivo. Ele apenas registra se um arquivo foi acessado com permissões de gravação, verificando open syscalls com as sinalizações O_RDWR ou O_WRONLY .

Então, quando eu uso o comando logger , na verdade estou pedindo ao meu daemon do Syslog para escrever no arquivo para mim. O daemon syslog sempre tem esse arquivo aberto para escrita, portanto, faz sentido que nada seja registrado.

Se eu reiniciar o daemon do Syslog, obtenho algo assim em meus logs de auditoria:

# ausearch -i -k logs
----
type=PROCTITLE msg=audit(10-03-2017 16:16:59.128:4613) : proctitle=/usr/sbin/rsyslogd -n 
type=PATH msg=audit(10-03-2017 16:16:59.128:4613) : item=1 name=/var/log/syslog inode=417506 dev=08:01 mode=file,640 ouid=syslog ogid=adm rdev=00:00 nametype=NORMAL 
type=PATH msg=audit(10-03-2017 16:16:59.128:4613) : item=0 name=/var/log/ inode=411799 dev=08:01 mode=dir,775 ouid=root ogid=syslog rdev=00:00 nametype=PARENT 
type=CWD msg=audit(10-03-2017 16:16:59.128:4613) :  cwd=/ 
type=SYSCALL msg=audit(10-03-2017 16:16:59.128:4613) : arch=x86_64 syscall=open success=yes exit=6 a0=0x7f5848003fb0 a1=O_WRONLY|O_CREAT|O_NOCTTY|O_APPEND|O_CLOEXEC a2=0640 a3=0x7f5848000088 items=2 ppid=1 pid=10638 auid=unset uid=syslog gid=syslog euid=syslog suid=syslog fsuid=syslog egid=syslog sgid=syslog fsgid=syslog tty=(none) ses=unset comm=rs:main Q:Reg exe=/usr/sbin/rsyslogd key=logs

    

Answer 2

Você pode começar verificando se a regra está ativa procurando por ela na saída de sudo auditctl -l .

Se auditd foi definido para tornar o conjunto de regras imutável (por exemplo, seu /etc/audit/audit.rules contém -e 2 ), somente uma reinicialização ativará novas regras.

Se a regra estiver visível, você recebe qualquer coisa se você executar sudo ausearch -k logs ? Além disso, o que você ganha se você executar sudo augenrules --check ?

Como você diz, registrar cada gravação no / var / log / syslog (ou / var / log / messages) pode ficar um pouco barulhento, portanto você pode considerar excluir raiz e / ou qualquer usuário usado para componentes syslog não privilegiados . Uma vez que funciona.