Por que mover um certificado VPN quebra sua etiqueta SELinux

Os certificados podem estar no diretório correto com um modo legível e propriedade de root, e o serviço ainda pode informar que não consegue abrir o ficheiro. Num sistema SELinux, essa combinação aponta para um mecanismo específico e não para permissões. A etiqueta viajou com o ficheiro, porque um renomear não cria um novo objeto. O inode manteve o contexto de segurança que tinha no caminho antigo, e a política do novo caminho nunca teve a oportunidade de atribuir o seu.

O que um renomear realmente faz a uma etiqueta

Um ficheiro transporta o seu contexto SELinux como dados de atributo ligados ao inode. Renomear dentro de um mesmo sistema de ficheiros altera a entrada de diretório e nada mais, o que é rápido e atómico, e é a razão pela qual o contexto sobrevive à movimentação. Nenhuma política é consultada, nenhum valor predefinido é aplicado e nenhum aviso é impresso.

Copiar comporta-se de forma diferente. Uma cópia cria um novo inode no diretório de destino, e a política atribui um contexto a partir do tipo desse diretório, pelo que um certificado copiado costuma ficar com a etiqueta correta, enquanto um movido permanece errado. Essa única diferença explica a maior parte da confusão nesta classe de pedidos.

As movimentações entre sistemas de ficheiros recaem na semântica de cópia, pelo que o mesmo comando pode comportar-se de forma diferente em duas máquinas consoante /etc esteja num volume próprio. Verifique isso antes de concluir que a ferramenta não é fiável. Uma vista de olhos à tabela de montagens diz-lhe que tipo de movimentação realizou.

Leia a etiqueta atual contra a esperada

Três comandos apenas de leitura respondem à pergunta sem alterar nada. O primeiro mostra o que o ficheiro tem agora, o segundo relata o que a política espera para esse caminho exato, e o terceiro lista cada ficheiro sob o diretório cuja etiqueta difere.

ls -lZ /etc/openvpn/client/office-ca.crt
matchpathcon /etc/openvpn/client/office-ca.crt
restorecon -Rn -v /etc/openvpn/client

É na execução em seco que se deve confiar, porque nomeia cada ficheiro cujo contexto se afasta da política e ainda assim deixa o sistema intacto. Se o certificado aparecer nessa lista, encontrou a discrepância entre o que o caminho significa e o que o ficheiro afirma. Se não aparecer, a etiqueta já é a que a política quer e o seu tempo pertence a outro lugar.

Depois correlacione a diferença com uma recusa real. Uma divergência é evidência de uma etiqueta errada, não a prova de que o serviço falhou por causa dela, e uma correção aplicada sem uma recusa correspondente no registo é um palpite com passos extra.

Restaure o mapeamento em vez de inventar uma exceção

Para uma localização padrão a política já mapeia o caminho, pelo que restorecon aplica-a e o trabalho está feito. Mantenha o âmbito no diretório que está a reparar; reetiquetar todo o sistema de ficheiros é lento, perturbador, e enterra o erro original sob uma alteração muito grande.

Para um diretório personalizado a ordem importa, e invertê-la produz um comando que relata sucesso sem alterar nada. O mapeamento pertence à política, o reetiquetar pertence ao fim, e a execução em seco pertence antes de ambos. Saltar essa última parte é como um caminho que nunca esteve errado acaba reetiquetado de qualquer forma.

semanage fcontext -a -t openvpn_etc_t '/etc/openvpn/custom(/.*)?'
restorecon -Rv /etc/openvpn/custom

restorecon aplica um mapeamento; não pode inventar um. Se nenhuma regra descrever o caminho, não há nada de onde restaurar, e é por isso que o mapeamento persistente tem de existir antes do reetiquetar. Registe qual configuração possui esse mapeamento, porque de contrário uma movimentação posterior, uma atualização de pacote ou um reetiquetar recriam a falha e a pessoa seguinte começa do zero.

Por que o chcon não é a solução

chcon escreve um contexto diretamente no ficheiro. Tem efeito imediato e é a opção menos duradoura disponível, porque um reetiquetar do sistema de ficheiros reaplica a política e descarta alterações manuais sem perguntar. O ficheiro parece reparado e a reparação tem uma data de validade que ninguém escreveu. O que quer em vez disso é uma regra que descreva o caminho, para que cada ficheiro que lá chegue receba automaticamente o mesmo tratamento.

Pior, ensina a lição errada: o mapeamento subjacente continua em falta, pelo que a falha regressa semanas depois sem um gatilho óbvio e sem memória do contorno. Use chcon apenas como experiência temporária para confirmar uma hipótese, depois substitua-o por um mapeamento que sobreviva ao reetiquetar seguinte, e verifique que a substituição está realmente no lugar.

Quando a etiqueta está correta e o acesso continua a falhar

Comece pelos diretórios pais. A permissão de travessia é verificada em cada componente do caminho, pelo que um certificado corretamente etiquetado dentro de um diretório onde o serviço não consegue entrar continua ilegível. Tanto o SELinux como a permissão comum têm de permitir cada passo, e corrigir um não corrige o outro.

Depois verifique a identidade do processo e a sandbox do próprio serviço. Uma unidade com uma sandbox restritiva pode negar acesso a um ficheiro que a política permitiria de bom grado, e pela linha de registo as duas causas parecem idênticas. Confirme qual processo está realmente a pedir, não qual supõe que está a pedir.

Lembre-se de que as regras dontaudit podem suprimir mensagens de recusa, pelo que um registo de auditoria vazio é evidência fraca e não prova. Se a política parecer correta e o acesso continuar a falhar, investigue antes de gerar um módulo de permissão amplo, e não desative o SELinux para fazer o sintoma desaparecer. Ambos os atalhos produzem um sistema que parece funcionar e uma postura de segurança que ninguém consegue descrever. Uma investigação curta é melhor do que qualquer um deles.