Como faço para solucionar esses erros do SELinux AVC?

2

Background: Eu tenho um servidor CentOS 6 LAMP. Recentemente, o servidor começou a não responder a cada poucos dias. Originalmente, o mysqld lançava um alerta de nagios e eu não conseguiria nem mesmo ssh no servidor, uma reinicialização forçada era necessária. Mysqltuner levou-me a aumentar o buffer pool, que parecia ajudar. Agora, o sintoma mudou para nagios lançando um alerta do apache http. Eu consegui fazer o ssh no servidor desta vez, mas o apache falhou ao reiniciar e uma reinicialização foi necessária.

Depois de examinar / var / log / messages e /var/log/audit/audit.log, vejo que existem centenas de erros de AVC. audit.log é vários MB diariamente, enquanto meus outros servidores são apenas kb em tamanho. Isso poderia ser uma pista para o problema subjacente?

Uma entrada típica de / var / log / messages é esta:

Mar 31 16:50:39 web1 setroubleshoot: SELinux is preventing /bin/ps from getattr access on the directory /proc/<pid>. For complete SELinux messages. run sealert -l be51d126-d70e-491f-9ec8-f897677d9989

Executá-lo por meio de sealert produz o seguinte:

SELinux is preventing /bin/ps from getattr access on the directory /proc/<pid>.

*****  Plugin catchall (100. confidence) suggests  ***************************

If you believe that ps should be allowed getattr access on the <pid> directory by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# grep ps /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp

Aqui está uma entrada típica em audit.log:

type=SYSCALL msg=audit(1427837702.229:721164): arch=c000003e syscall=4 success=no exit=-13 a0=8164d0 a1=3eaee11cc0 a2=
3eaee11cc0 a3=8164d6 items=0 ppid=2792 pid=2800 auid=4294967295 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48
 fsgid=48 tty=(none) ses=4294967295 comm="ps" exe="/bin/ps" subj=system_u:system_r:httpd_t:s0 key=(null)
type=AVC msg=audit(1427837702.219:721127): avc:  denied  { getattr } for  pid=2800 comm="ps" path="/proc/875" dev=proc
 ino=9349054 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:system_r:kernel_t:s0 tclass=dir

UPDATE Ok, meses depois aconteceu de novo. Não estou nem perto de descobrir por que meu servidor LAMP está congelando de tempos em tempos (suspeito que o MySQL seja o primeiro serviço a lançar um alerta nagios), mas sei por que os alertas do SE Linux (da minha pergunta original) estão acontecendo: um dos sites hospedados é uma loja online Magento, e o script cron.php que é acionado a cada cinco minutos está causando os erros do SE Linux, todas as vezes.

Portanto, minha pergunta atualizada é: isso é algo com o que se preocupar, além das enormes quantidades de entradas em minhas mensagens e registros de auditoria?

    
por Rocky 01.04.2015 / 02:02

1 resposta

2

Finalmente consegui reduzir e resolver o problema. Foi uma combinação de dois problemas:

  1. Um site Magento no servidor foi desativado no arquivo vhosts. Mas o trabalho do Magento cron ainda estava rodando, falhando e causando todos os erros do AVC. A remoção do cron job órfão interrompeu os erros do AVC.

  2. Como Manuel Faux sugeriu nos comentários, no entanto, os erros do SELinux não estavam relacionados com as falhas aleatórias do servidor. Mas com as entradas do AVC não ocupando mais meus arquivos de log, consegui localizar o seguinte nos logs do mysql pouco antes de o servidor congelar:

    InnoDB: Aviso: uma longa espera de semáforo: --Thread 140485795231488 esperou na linha 1706 do btr0sea.c por 241.00 segundos o semáforo: X-lock no RW-latch em 0x5583b18 criado no arquivo btr0sea.c linha 178

Os registros sobre o semáforo wait me levaram a esta pergunta relacionada . Então a solução final foi setar innodb_adaptive_hash_index = 0 na configuração do mysql.

Como um passo adicional, também criei um mysqlcheck semanal para otimizar todos os bancos de dados. Já se passaram várias semanas e não há falhas espontâneas nem mais logs de erros malucos para o mysql ou SELinux.

    
por 22.06.2015 / 20:01