Diagnosticar as negações do Squid sob SELinux
Distinga as regras de acesso do Squid, as permissões do sistema de arquivos, os rótulos de porta e as negações da política de segurança do host antes de alterar a aplicação.
Uma negação de acesso HTTP gerada pelo Squid e um “Permission denied” do sistema operacional ocorrem em limites diferentes. Determine se o Squid estava abrindo um arquivo, vinculando um socket, conectando-se para fora ou rejeitando uma solicitação de cliente.
Correlacione o evento de auditoria
Em sistemas SELinux, associe o erro do serviço ao seu registro de auditoria. O domínio de origem, o tipo de destino, a classe do objeto e a permissão negada mostram qual operação a política bloqueou. A propriedade correta no Unix não prova que o rótulo de segurança seja adequado.
Uma porta de escuta personalizada pode exigir o rótulo de porta correspondente. Um diretório de logs ou de cache realocado pode exigir rotulagem de arquivos. Para uma falha no caminho de log do Squid, verifique também o percurso de diretórios e as permissões de escrita antes de atribuí-la a um rótulo. A permissão para um serviço de saída incomum é outra operação; os exemplos de Squid SELinux da Red Hat distinguem esses casos.
Use a política da distribuição instalada e as orientações de administração. Os caminhos dos pacotes, os rótulos e o confinamento podem variar entre imagens. Em sistemas que usam AppArmor, inspecione o perfil dele em vez de aplicar comandos SELinux.
Corrija a política ou o local indicado pelas evidências, mantendo a aplicação no host. A autenticação de clientes e as regras de acesso do próprio Squid continuam valendo após a correção do problema de política do host.