O SELinux ou o AppArmor está bloqueando o meu serviço: como saber e o que fazer

O SELinux (AlmaLinux, Rocky e outros da família Red Hat) e o AppArmor (Ubuntu e Debian) são camadas de segurança que negam ações mesmo a quem tem as permissões certas. Se um serviço dá “Permission denied” e o dono e o chmod estão certos, é este o suspeito. Descobre-se pondo o módulo em modo de aviso por um momento e lendo o que foi negado; resolve-se com a regra certa, e não desligando a proteção. Num VPS não gerenciado, isto é consigo.

Qual é o seu

	SELinux	AppArmor
Onde costuma vir	AlmaLinux, Rocky, outros Red Hat	Ubuntu e Debian
Ver o estado	getenforce ou sestatus	sudo aa-status
Ver o que foi negado	sudo ausearch -m avc -ts recent (precisa do auditd) ou o registro do sistema	O registro do núcleo: sudo journalctl -k \| grep -i apparmor procure “DENIED”
Ensaio sem bloquear	sudo setenforce 0 (modo permissivo, até a próxima inicialização)	sudo aa-complain /caminho/do/perfil (do pacote apparmor-utils)
Voltar a proteger	sudo setenforce 1	sudo aa-enforce /caminho/do/perfil

Passo a passo

1	Confirme que é isto. Ponha o módulo em modo de aviso (linha “Ensaio” da tabela). Se o serviço passa a funcionar, a causa era o SELinux ou o AppArmor. Se continua falhando, não é isto: volte às permissões normais (permissões de arquivos) e ao registro do serviço (ler o systemctl status).

2	Volte a ligar a proteção logo a seguir. sudo setenforce 1 (SELinux) ou aa-enforce (AppArmor). O modo permissivo serve de diagnóstico e não de solução.

3	Leia o que foi negado. A linha diz o programa, o arquivo ou a porta, e a ação. Isso diz a regra que falta.

4	Aplique a regra mínima (ver abaixo), não uma exceção para tudo.

5	Teste outra vez com a proteção ligada.

Os casos mais comuns

Situação	Solução (SELinux)	Solução (AppArmor)
O servidor web não lê uma pasta fora de /var/www	sudo semanage fcontext -a -t httpd_sys_content_t "/srv/site(/.*)?" e sudo restorecon -Rv /srv/site (semanage vem do pacote policycoreutils-python-utils)	Edite o perfil do programa em /etc/apparmor.d/ para permitir a pasta e recarregue com sudo systemctl reload apparmor
O servidor web (como proxy) não consegue ligar-se à aplicação	sudo setsebool -P httpd_can_network_connect 1	Raro; é um perfil específico.
Um serviço quer escutar numa porta nova (por exemplo o SSH em outra porta)	sudo semanage port -a -t ssh_port_t -p tcp 2222 (2222 é um exemplo; para o servidor web, http_port_t)	Normalmente não é preciso.
Arquivos copiados ou movidos ficam com a etiqueta errada	sudo restorecon -Rv /pasta	Não se aplica.

Desligar o SELinux de vez é a resposta de que se arrepende. SELINUX=disabled em /etc/selinux/config tira uma proteção que defende o servidor de uma falha numa aplicação. O mesmo para parar o AppArmor. Prefira sempre a regra mínima; use o modo permissivo só para diagnosticar, e por pouco tempo.

Mudar a etiqueta ou o perfil sem perceber pode abrir o que devia estar fechado. Se não percebe a linha negada, copie-a e procure-a na documentação da distribuição antes de aplicar. Segundo o seu sistema, os nomes de pacotes e ferramentas podem variar.

Antes de culpar o SELinux ou o AppArmor, confira o básico: o serviço está rodando? a porta está aberta na firewall (portas e firewall)? o arquivo existe? A maioria dos “Permission denied” são permissões normais.

O servidor ficou inacessível por SSH depois de mexer nestas proteções? A console do painel entra sem passar pela rede: diga-nos o que fez.

Abrir um pedido de suporte

VEJA TAMBÉM

Permissões de arquivos num VPS Linux

Um serviço não inicia: ler o systemctl status

Mudar a porta do SSH sem se trancar fora

Perdi o acesso SSH ao servidor

PRODUTO RECOMENDADO

Hospedagem de sites com cPanel

Domínio e SSL incluídos, cópias diárias e o painel que já conhece. desde R$ 36,30/mês (plano de 3 anos, com cupom)

Ver planos

Categorias

Categorias