Formato não documentado dos registros de log de auditoria do Linux

4

Estou escrevendo um analisador para o Linux Audit e me deparei com alguns casos estranhos que não parecem estar de acordo com o padrão.

A minha referência é a documentação da Red Hat .

Um registro de auditoria adequado deve ser assim:

type=USER_CMD msg=audit(1464013671.517:403): pid=3569 uid=0 auid=1000 ses=7 msg='cwd="/root" cmd=123 terminal=pts/1 res=success'

Um campo inválido name = value em um registro

Vamos ver o seguinte registro:

type=DAEMON_START msg=audit(1464013652.147:626): auditd start, ver=2.4 format=raw kernel=3.16.0-4-586 auid=4294967295 pid=3557 res=success

A documentação não diz nada sobre auditd start , que não se encaixa no formato name = value .

O que é isso? Onde eu posso ler sobre isso?

Uma vírgula e um espaço como separador

Além disso, a documentação diz que

Each record consists of several name=value pairs separated by a white space or a comma.

Isso claramente não é verdade, já que podemos ver que auditd start, ver=2.4 são separados com um comando e um espaço.

Por que isso acontece? Onde está o padrão realmente descrito?

Espaços adicionais em branco em um registro

Vamos ver o seguinte registro:

type=CWD msg=audit(1464013682.961:409):  cwd="/root"

Tem dois espaços entre type=CWD msg=audit(1464013682.961:409): e cwd="/root" . Não faz nenhum sentido. Na verdade, observei esse comportamento apenas em registros com type=CWD e cwd="/root" .

Por que isso acontece?

Nota: Eu criei esses logs em um Debian recente.

    
por Mateusz Piotrowski 05.07.2016 / 11:28

1 resposta

1

Então resolvi uma pequena parte do problema - descobri que auditd start, ver=2.2 é válido. Eu não consegui encontrar nenhuma documentação embora. O único documento que tenho é um exemplo do manual da Red Hat:

Example 7.5. Additional audit.log events

The following Audit event records a successful start of the auditd daemon. The ver field shows the version of the Audit daemon that was started.

type=DAEMON_START msg=audit(1363713609.192:5426): auditd start, ver=2.2 format=raw kernel=2.6.32-358.2.1.el6.x86_64 auid=500 pid=4979 subj=unconfined_u:system_r:auditd_t:s0 res=success

The following Audit event records a failed attempt of user with UID of 500 to log in as the root user.

type=USER_AUTH msg=audit(1364475353.159:24270): user pid=3280 uid=500 auid=500 ses=1 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:authentication acct="root" exe="/bin/su" hostname=? addr=? terminal=pts/0 res=failed'

O triste é que estes são apenas exemplos. Eu adoraria ler a documentação atual do padrão, já que não consigo encontrá-lo em lugar nenhum.

Atualizar

Eu fiz as perguntas da lista de discussão oficial ( veja a resposta completa à minha pergunta ).

Veja o que aprendi:

Um campo inválido name = value em um registro

Não estou claro para mim por que auditd start existe, mas aqui está a resposta de Steve Grubb à minha pergunta.

Where are all the elements like auditd start, user, etc. listed? I cannot find any document which specifies what can occurs between the colon (separating the type and the msg=audit(…) from the fields) and the record’s fields.

     

Realmente não existe nenhum, Libauparse cuida de tudo isso para que você   não precisa. Se você está querendo fazer a tradução, você pode alimentar o   registra-se no auparse e depois formata o evento da maneira que você quiser.

Basicamente, a resposta está escondida em algum lugar da biblioteca auparse.

Uma vírgula e um espaço como separador

Why do some records are separated by a comma and a whitespace? Example:

type=DAEMON_START msg=audit(1363713609.192:5426): auditd start, ver=2.2 format=raw kernel=2.6.32-358.2.1.el6.x86_64 auid=500 pid=4979 subj=unconfined_u:system_r:auditd_t:s0 res=success
     

Há muito tempo, os registros foram feitos para serem legíveis para humanos   (não ria) e consumível da máquina. Com o tempo, estes foram   pares de name = value convertidos. Mesmo o que você mencionou acima foi   fixo.

Espaços adicionais em branco em um registro

Este já foi corrigido por Steve Grubb.

O patch: link

    
por 12.07.2016 / 17:06