Muitas vezes, você será presenteado com informações e espera-se que escolha os bits que são relevantes para seus propósitos. Por exemplo, quando você usa strace de um programa, você terá uma carga grande de saída e estará focando apenas nas partes que parecem relacionadas a porque você está olhando para strace output.
Os registros de auditoria seguem um raciocínio similar. Vamos ver o seu:
type=PROCTITLE msg=audit(03/27/2015 02:58:34.764:439) : proctitle=/bin/sh
Não é demais explodir. Ele fornece um timestamp e o valor do proctitle do executável, que geralmente é o nome do processo. Não tenho certeza porque logind tem isso como um proctitle, no entanto.
type=AVC msg=audit(03/27/2015 02:58:34.764:439) : avc: denied { getattr } for pid=3861 comm=systemd-logind name=kvm dev="devtmpfs" ino=11755 scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:kvm_device_t:s0 tclass=chr_file permissive=1
Esta é a mensagem de erro do SELinux e a coisa com a qual você deve se preocupar mais. O type=AVC é o que dá isso. AVC significa access vector cache que é um componente do SELinux .
As partes importantes a serem observadas são o que está na sub-rotina denied (nesse caso, getattr ), que informa o que o programa estava fazendo especificamente para ser negado. Depois disso, analisamos o contexto de origem (também conhecido como scontext ), que lhe dará uma ideia do que a categoria geral do componente ofensivo estava executando. Nesse caso, o contexto completo é system_u:system_r:system_dbusd_t que encurtou para a única parte que é substantivamente significativa (99% do tempo) apenas system_dbusd_t . Fazendo a mesma coisa no contexto de destino, obtemos kvm_device_t . Os campos comm e pid são importantes e óbvios. A exceção aconteceu com systemd-logind que estava sendo executado com um PID de 3861.
Portanto, juntando , temos systemd-logind sendo executado como system_dbusd_t e tentando fazer algum tipo de getattr em um arquivo com um contexto de kvm_device_t .
Saber o que isso significa que você deve fazer é com o administrador. Para a parte do SELinux, tudo o que se sabe é que tal coisa não é permitida por sua política, então ela lhe dá os detalhes para que você possa fazer sua própria ligação.
type=SYSCALL msg=audit(03/27/2015 02:58:34.764:439) : arch=x86_64 syscall=getxattr success=no exit=-61(No data available) a0=0x1fef030 a1=0x7fc0dbf2ef9f a2=0x7fff6aaa1da0 a3=0x84 items=0 ppid=1 pid=3861 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=systemd-logind exe=/lib/systemd/systemd-logind subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 key=(null)
Isso é um pouco fora de seqüência em termos de como você o apresentou, mas eu o coloco desde então, o que torna mais fácil entender como você deve lê-lo. O type=AVC é a parte importante, mas geralmente registra o syscall que falhou, para que você possa obter mais detalhes.
Por exemplo, dado o nome do programa, sabemos o que é systemd-logind , mas se ele for mais ambíguo, o exe=/lib/systemd/systemd-logind poderá identificar qual programa causou o erro. Coisas como auid (o loginuid do processo) ou uid também podem ser informações úteis se você não tivesse certeza do motivo pelo qual o executável em questão estava sendo expulso.
Espero que ajude. Se você tiver alguma dúvida, atualizarei minha resposta.
EDIT: Outra coisa no seu último ponto. Normalmente, você pode ver a política que o audit2allow gera e o tipo de alteração que está sendo feita. Na verdade, não aplica as alterações até você inserir o módulo de política. Então, você ainda pode gerá-lo e examiná-lo em um editor de texto para ver se é o tipo de coisa que você gostaria de permitir que acontecesse. Pode ser mais rápido do que rastrear os detalhes lendo audit.log diretamente.