SELinux no RHEL: como diagnosticar erros de acesso

O serviço está ativo, o arquivo existe e as permissões parecem permitir leitura, mas a página continua retornando erro. Em um servidor Red Hat, essa investigação pode envolver SELinux. Para diagnosticar erros de SELinux no RHEL, comece reunindo evidências: qual processo tentou acessar qual recurso, em que momento e com qual contexto. Essa sequência ajuda a corrigir a configuração responsável pela recusa.

É tentador desligar um controle para fazer a aplicação funcionar rapidamente. O problema é que isso não explica o acesso que estava sendo bloqueado nem define a permissão correta. Um diagnóstico bem feito verifica as camadas envolvidas e transforma a mensagem de negação em informação. Você consegue restaurar o comportamento esperado e compreender por que a correção é apropriada.

Este guia usa como referência o RHEL 9 e um cenário de laboratório com Apache. Os comandos precisam ser avaliados para a versão e a política do seu ambiente. Você deve ter acesso administrativo autorizado, dados de teste e um procedimento de recuperação. Não vamos desativar SELinux nem criar automaticamente uma política a partir de qualquer log. O foco será identificar estado, consultar registros, conferir contextos e aplicar uma correção pontual quando ela fizer sentido.

Entenda por que uma permissão tradicional pode não bastar

Permissões tradicionais de arquivos são uma parte do controle de acesso. SELinux acrescenta decisões baseadas na política e nos contextos envolvidos. Assim, um arquivo legível pela conta do serviço ainda pode ter um tipo inadequado para a operação tentada. Isso não significa que as permissões tradicionais deixaram de importar: as camadas precisam estar coerentes com a finalidade do serviço.

Imagine conteúdo web destinado à leitura pelo Apache. Você precisa confirmar que o processo atende a requisição, que o caminho configurado existe, que os diretórios permitem chegar ao arquivo e que a política permite o acesso ao conteúdo. Se uma dessas condições falha, o sintoma final pode ser parecido. A investigação deve distinguir as causas, em vez de modificar tudo ao mesmo tempo.

A introdução oficial a SELinux no RHEL ajuda a entender os conceitos. Não é necessário dominar toda a política para resolver um problema simples, mas é necessário saber o que você está observando. Comece por um recurso e uma operação, e amplie a investigação quando as evidências indicarem outra necessidade.

Descreva o incidente de forma reproduzível

Escreva o comportamento esperado e o comportamento observado. Página pública de teste deveria abrir e retorna HTTP 403 é um começo melhor do que o servidor está ruim. Registre a URL ou caminho envolvido, horário da tentativa e mudança recente. Em materiais compartilhados, substitua nomes internos e informações sensíveis por marcadores. Preserve a relação entre os dados para que o relato continue útil.

Confira o serviço e sua própria configuração antes de atribuir o erro a SELinux. Uma página pode falhar por diretório incorreto, regra da aplicação, autenticação, rede ou permissões tradicionais. Nosso conteúdo sobre rede no Red Hat Enterprise Linux oferece contexto para outra camada de diagnóstico. Os comandos e detalhes do material devem ser conferidos na edição instalada.

Reproduza somente a tentativa necessária no laboratório. Não gere dezenas de operações diferentes e depois tente adivinhar qual log corresponde ao problema. Um teste curto, com horário anotado, torna mais fácil correlacionar registros do serviço e auditoria. Se o ambiente é compartilhado, combine o teste com os responsáveis para não interpretar eventos de outros usuários como parte do seu exercício.

Confira o estado de SELinux

Use as ferramentas de consulta para saber como SELinux está funcionando naquele sistema. Enforcing aplica a política; permissive registra as decisões de negação sem aplicá-las da mesma forma; disabled indica que SELinux está desativado. O estado muda como interpretar a hipótese. Se não há aplicação da política, um erro observado pode ter outra causa, mesmo que existam configurações históricas relacionadas ao tema.

getenforce
sestatus
cat /etc/os-release

Registre a saída relevante antes de qualquer mudança. Não transforme essa consulta em uma sequência que altera o modo automaticamente. Em um servidor administrado por uma equipe, o estado pode refletir uma decisão ou uma configuração central. Uma alteração local sem registro pode criar divergência e dificultar o próximo diagnóstico, especialmente quando a configuração é reaplicada por automação.

Se o objetivo é estudar SELinux, use um laboratório cuja instalação e política sejam conhecidas. O artigo sobre instalação do RHEL publicado no site apresenta contexto de instalação. Para montar o laboratório agora, consulte a documentação oficial da edição pretendida e confirme licenciamento, acesso aos repositórios e requisitos aplicáveis ao seu caso.

Procure a negação no período da tentativa

Com o horário anotado e a operação reproduzida, consulte os eventos relevantes. O exemplo usa ausearch para registros recentes de SELinux. Ele pressupõe que as ferramentas e a auditoria apropriadas estão disponíveis. Se não houver resultado, isso não encerra automaticamente a investigação: verifique o serviço de auditoria, o período consultado e se a hipótese ainda corresponde ao erro observado.

sudo ausearch -m AVC,USER_AVC,SELINUX_ERR,USER_SELINUX_ERR -ts recent

A documentação oficial de diagnóstico no RHEL apresenta esse fluxo e alternativas para investigar negações. Use-a para o cenário da sua versão. Não misture registros antigos com a tentativa atual. Uma mensagem antiga pode apontar um problema já corrigido e levar a uma mudança desnecessária.

Leia a operação negada, o processo e os contextos de origem e destino. Os campos scontext e tcontext ajudam a identificar os lados da decisão, e tclass informa a classe do objeto. Não é preciso publicar o log inteiro para discutir o caso. Extraia os campos necessários e preserve o material completo em local adequado quando ele fizer parte de um incidente administrado.

Compare permissões, caminho e contexto

Para um arquivo de teste servido pelo Apache, examine o caminho real usado pela configuração. No exemplo, usamos /var/www/html/index.html como um caminho comum de conteúdo. Não crie nem sobrescreva esse arquivo em uma instalação existente apenas para acompanhar a demonstração. Faça a consulta somente quando ele for o recurso que você está investigando ou adapte ao recurso correspondente do laboratório.

ls -l /var/www/html/index.html
ls -Z /var/www/html/index.html
matchpathcon -V /var/www/html/index.html

O primeiro comando mostra permissões tradicionais; o segundo inclui o contexto; o terceiro compara o rótulo com o esperado pela configuração de contextos para o caminho. A comparação não substitui entender a finalidade do arquivo. Um caminho criado para outra aplicação pode ter uma regra diferente por uma razão válida. Você precisa relacionar o recurso ao serviço que realmente deve acessá-lo.

Considere também os diretórios que levam ao arquivo. O processo precisa atravessar o caminho, não apenas ler o último componente. Uma correção de contexto no arquivo final não resolve necessariamente uma permissão tradicional no diretório anterior. Esse é um motivo para fazer uma hipótese por vez: se você altera permissões, caminho e política simultaneamente, fica difícil saber qual mudança era necessária.

Use restorecon quando o rótulo padrão é o adequado

Quando você confirmar que o arquivo pertence à localização esperada e que seu rótulo diverge do padrão adequado, restorecon pode reaplicar o contexto configurado para aquele caminho. Antes de modificar, use a opção de simulação para observar a proposta. Confira o manual da versão instalada. O exemplo fica limitado ao arquivo investigado, reduzindo o alcance em comparação com uma relabelagem ampla do sistema.

sudo restorecon -n -v /var/www/html/index.html
sudo restorecon -v /var/www/html/index.html
ls -Z /var/www/html/index.html

O manual de restorecon detalha as opções de consulta e aplicação. Depois da alteração, repita a operação que falhou e consulte os eventos recentes. Se o problema continuar, não faça uma relabelagem maior por impulso. A hipótese inicial pode estar incompleta, ou outro componente do caminho pode exigir investigação.

Um caso comum envolve arquivos movidos de outro local que preservaram um contexto inadequado ao destino. A correção pertinente depende da origem, do destino e das regras existentes. Registre o contexto anterior, o contexto esperado e o resultado observado. Essa documentação ajuda a evitar que o mesmo método de implantação produza novamente o problema na próxima atualização da aplicação.

Um caminho personalizado pede uma regra persistente

Se o serviço usa um diretório diferente do caminho padrão, apenas reaplicar o contexto existente pode não representar a finalidade desejada. Primeiro, confirme que a configuração do serviço aponta para o diretório correto e que ele realmente deve conter conteúdo web de leitura. O exemplo abaixo pressupõe um diretório de laboratório dedicado, /srv/site-lab, e uma regra ainda não cadastrada para aquele padrão.

sudo semanage fcontext -a -t httpd_sys_content_t '/srv/site-lab(/.*)?'
sudo restorecon -n -R -v /srv/site-lab
sudo restorecon -R -v /srv/site-lab
ls -Zd /srv/site-lab

O semanage registra a associação do padrão ao tipo; restorecon aplica os rótulos correspondentes. Se a regra já existir, não repita -a esperando que o programa substitua qualquer configuração. Consulte as regras locais e avalie a alteração adequada com sua equipe. Um padrão amplo pode alcançar mais arquivos do que você pretendia, portanto mantenha o diretório dedicado e o escopo explícito.

A documentação de configurações não padrão no RHEL mostra como relacionar serviços e recursos. O tipo de conteúdo de leitura não é uma autorização genérica de escrita. Se a aplicação precisa gravar dados, separe esse requisito e use a política apropriada. Não amplie toda a árvore para solucionar a necessidade de uma única subpasta.

Booleans, portas e módulos resolvem necessidades diferentes

Nem toda negação envolve o rótulo de um arquivo. A aplicação pode tentar conectar a um banco, escutar uma porta ou executar uma operação sujeita a outra regra. SELinux possui recursos para configurações previstas, mas sua escolha precisa refletir a finalidade do serviço. Não habilite todos os booleans associados ao nome do programa para ver se algum deles resolve a falha.

Comece consultando o estado e o significado das opções pertinentes. Verifique na documentação quais permissões serão ampliadas e se a aplicação realmente precisa delas. Para portas, relacione a configuração do serviço à política e ao firewall: permitir uma porta no firewall não é a mesma coisa que permitir ao processo utilizá-la pela política. Essas camadas precisam ser administradas separadamente.

Uma política local pode ser necessária em cenários específicos, mas não deve ser produzida e instalada automaticamente a partir de qualquer negação. O evento pode revelar um erro da aplicação, um caminho errado ou uma tentativa que deveria continuar proibida. Antes de escrever regras novas, procure tipos e configurações já previstos. Quando houver necessidade real de política local, revisão e testes precisam acompanhar a decisão.

Defina sucesso com um teste positivo e um limite

A página abrir novamente é uma evidência importante, mas não conta toda a história. Confira que a correção foi aplicada ao recurso desejado e que o modo de operação continua conforme a configuração esperada. Não considere resolvido um problema que só desapareceu porque a proteção deixou de ser aplicada. O sucesso deve corresponder ao acesso necessário dentro da política administrada.

Em laboratório, mantenha um exemplo que precisa ser permitido e outro recurso que não deve ser exposto. Teste o comportamento com dados fictícios e registre o resultado. Não faça testes de acesso contra conteúdo de terceiros nem arquivos sensíveis para demonstrar a regra. A ideia é verificar o alcance da configuração, usando recursos preparados especificamente para essa finalidade.

Se o serviço permite leitura e não deve permitir escrita naquele local, confira que a configuração não ampliou essa finalidade sem necessidade. Em um projeto real, esses testes dependem do comportamento da aplicação e das permissões envolvidas. Descreva o que foi verificado e o que ficou fora. Um teste restrito oferece evidência restrita, e essa precisão ajuda quem vai revisar a alteração.

Documente a correção para a próxima implantação

Registre o sintoma, a tentativa reproduzida, os campos relevantes do log, a causa confirmada e a mudança aplicada. Inclua os comandos de verificação e o resultado esperado. Se a alteração faz parte da configuração permanente, incorpore-a ao procedimento de implantação aprovado. Uma correção manual esquecida pode desaparecer numa reconstrução e fazer o problema parecer novo a cada instalação.

O inventário deve distinguir regra persistente e estado aplicado no sistema de arquivos. Também deve mostrar qual conta executa o serviço e quais diretórios pertencem a ele. Evite documentos que contêm apenas uma longa sequência de comandos sem justificativa. A próxima pessoa precisa saber por que o tipo escolhido corresponde ao recurso, e não apenas reproduzir o que funcionou uma vez.

Para investigar arquivos e texto com mais facilidade, desenvolva sua prática com os comandos básicos do Linux. O conteúdo sobre navegação com cd ajuda a organizar o ponto inicial de uma consulta. Quando trabalhar com registros, limite o período e o escopo. Você ganha clareza e reduz a exposição desnecessária de informações operacionais.

Erros comuns que aumentam o trabalho de diagnóstico

O primeiro é atribuir qualquer HTTP 403 a SELinux. O segundo é alterar permissões tradicionais de forma ampla antes de conferir a mensagem. O terceiro é aplicar o mesmo tipo a todas as pastas da aplicação, embora elas tenham finalidades diferentes. O quarto é criar regras novas para um comportamento que a aplicação não deveria executar. Todos esses atalhos dificultam explicar a mudança final.

Outro erro é confundir ausência de um evento numa consulta limitada com prova definitiva de ausência de participação de SELinux. Consulte o período correto e confirme os mecanismos de registro. Se a hipótese não tiver evidência, diga isso e investigue outras camadas. Um diagnóstico útil consegue abandonar uma hipótese sem tentar forçar todos os sintomas a caberem nela.

Também evite usar uma correção de laboratório em produção sem comparar contexto e requisitos. Nomes iguais não garantem políticas, serviços e dados iguais. Uma mudança de ambiente exige avaliação proporcional ao impacto, com revisão e recuperação disponíveis. A prática no laboratório ajuda a compreender os comandos; a aplicação real ainda exige conhecer o sistema que será alterado.

Perguntas frequentes sobre SELinux no RHEL

Se chmod não resolveu, a causa é SELinux?

Essa conclusão precisa de evidência. O serviço pode estar usando outro caminho, uma regra própria ou uma configuração de aplicação diferente. Confira a tentativa e os registros. Uma negação correspondente ao evento ajuda a orientar a investigação, mas cada campo deve ser relacionado ao recurso esperado. Não use o fracasso de uma tentativa de correção como prova automática de outra causa.

restorecon cria uma nova permissão para qualquer caminho?

Ele reaplica rótulos conforme a configuração de contextos correspondente. Para um caminho personalizado, pode ser necessário definir a associação apropriada antes. Entender essa diferença evita repetir o comando esperando um efeito que ele não foi escolhido para produzir. Confira a proposta, o escopo e o resultado, e consulte as regras existentes antes de cadastrar outra associação.

Quando devo pedir ajuda especializada?

Quando a necessidade envolve política local, dados sensíveis, serviços compartilhados ou uma alteração cujo alcance você não consegue explicar. Prepare o relato com contexto e evidências, em vez de tentar muitas mudanças ao mesmo tempo. Isso permite uma revisão mais objetiva e preserva uma referência do estado original. O conhecimento básico continua útil, porque melhora a qualidade das informações que você leva ao responsável.

Diagnosticar erros de SELinux no RHEL é relacionar uma operação necessária à configuração que deve permiti-la. Confira o serviço, reproduza o caso, leia a negação e compare contextos. Aplique uma mudança pontual quando a causa estiver clara e verifique o comportamento. Essa sequência produz uma correção compreensível e uma documentação que ajuda na próxima implantação.