Root num terminal, negado sob o SELinux: por que o hook falha

Você executa o script up como root, ele conclui, e o mesmo script falha quando o serviço o invoca. Nada nas permissões do arquivo mudou, então o próximo passo natural é afrouxá-las de novo, o que não corrige nada. Num host com SELinux, o fator decisivo muitas vezes não é quem é o processo, mas em qual domínio ele roda, e root dentro de um domínio confinado continua confinado.

O mesmo comando, dois domínios de segurança diferentes

A imposição de tipos avalia o domínio de origem, o rótulo de destino e a operação solicitada em conjunto. Sua sessão de terminal roda num domínio não confinado ou administrativo, e o daemon roda no domínio atribuído à sua unidade. Por isso comandos idênticos produzem decisões diferentes, e a diferença é intencional e não um defeito na política.

É por isso que comparar as duas execuções só é útil se você comparar os contextos delas. Execute o mesmo comando a partir do shell e do hook, e a versão do shell prova que o binário existe e que os argumentos estão corretos; ela não prova nada sobre o serviço ter permissão para executá-lo. Execute das duas formas e compare os domínios, não apenas os códigos de saída. É essa comparação que transforma uma queixa vaga de permissão numa pergunta específica sobre um domínio e um rótulo.

A forma clássica dessa falha é um auxiliar que chama uma ferramenta externa. O hook em si pode estar permitido, enquanto a ferramenta que ele invoca carrega um rótulo que o domínio do serviço não pode executar, ou escreve num diretório cujo rótulo proíbe isso.

Leia o registro AVC ao lado do erro do hook

Uma negação AVC nomeia os campos que decidem o caso: o contexto de origem do processo, o contexto de destino do objeto, a classe do objeto e a permissão específica que foi recusada. Leia todos os quatro antes de formar uma teoria, porque uma negação de execução e uma negação de escrita têm reparos completamente diferentes.

ausearch -m AVC,USER_AVC -ts recent
ls -Z /usr/local/sbin/vpn-up.sh
ps -eZ | grep openvpn

O contexto de origem deve corresponder ao domínio em que o serviço realmente roda, e o contexto de destino ao rótulo do arquivo ou diretório que a operação tocou. Se algum dos dois não bater com o erro que você está perseguindo, você está lendo outro evento.

Anote a versão da política e o caminho exato do executável ao lado do registro. Um nome de domínio que aparece na política de uma distribuição é evidência sobre aquela instalação, não garantia de que outra compilação traga as mesmas regras. É esse contexto que permite a outra pessoa reproduzir sua conclusão no próprio host. Sem ele, o registro é lido como anedota e não como prova.

Rótulo, configuração ou política: três reparos

O primeiro reparo é um rótulo que não corresponde à localização instalada do arquivo. Um script copiado para o lugar com cp ou escrito por um editor pode carregar um rótulo padrão que o domínio do serviço não pode usar, e restaurar o contexto esperado resolve isso sem tocar na política.

O segundo é configuração. A distribuição pode oferecer uma forma suportada de executar a operação, um diretório documentado para o auxiliar ou um pacote de política atualizado que já a permite. Mudar seu layout para o suportado é mais barato do que escrever política e sobrevive às atualizações.

O terceiro é uma regra realmente ausente, e deve ser o último recurso. Gere um candidato com as ferramentas de auditoria, leia o que ele realmente permite, restrinja-o à operação e ao domínio que você observou, e peça a outra pessoa para revisá-lo antes que chegue perto da produção.

Por que um módulo allow antigo não é a resposta

Os resultados de busca para essa falha estão cheios de módulos prontos, muitas vezes para uma ferramenta que o hook não chama mais. Instalar um concede permissões que podem não ter nada a ver com a sua negação, e deixa a incompatibilidade real no lugar enquanto adiciona um buraco permanente.

Ele também esconde a próxima falha. Um módulo que permite uma classe ampla de operações fará esse erro desaparecer e transformará o próximo em algo muito mais difícil de atribuir. Remover o módulo depois também é uma mudança que ninguém quer agendar, então o atalho tende a se tornar permanente.

A comparação disciplinada é entre a negação que você consegue ler e a mudança que você propõe. O guia de solução de problemas do SELinux da Red Hat coloca as verificações de rotulagem e configuração antes da política gerada exatamente por esse motivo. Se não houver uma negação correspondente no registro, o SELinux provavelmente não é o seu problema, e questões de caminho, sandbox ou permissões continuam abertas.