Root nun terminal, denegado baixo SELinux: por que falla o hook

Executa o script up como root, remata, e o mesmo script falla cando o servizo o invoca. Non cambiou nada nos permisos do ficheiro, así que o seguinte paso natural é afrouxalos de novo, o que non arranxa nada. Nun host con SELinux o factor decisivo a miúdo non é quen é o proceso, senón en que dominio se executa, e root dentro dun dominio confinado segue confinado.

O mesmo comando, dous dominios de seguridade distintos

A aplicación de tipos avalía o dominio de orixe, a etiqueta de destino e a operación solicitada en conxunto. A túa sesión de terminal execútase nun dominio non confinado ou administrativo, e o daemon execútase no dominio que teña asignada a súa unidade. Por iso, comandos idénticos producen decisións distintas, e a diferenza é deliberada e non un fallo da política.

Por iso comparar as dúas execucións só é útil se comparas os seus contextos. Executa o mesmo comando desde a consola e desde o hook, e a versión da consola demostra que o binario existe e que os argumentos son correctos; non demostra nada sobre se o servizo ten permiso para executalo. Execútao de ambos os xeitos e compara os dominios, non só os códigos de saída. Esa comparación é a que converte unha queixa vaga sobre permisos nunha pregunta concreta sobre un dominio e unha etiqueta.

A forma clásica deste fallo é un axudante que chama unha ferramenta externa. O hook en si pode estar permitido, mentres que a ferramenta que invoca leva unha etiqueta que o dominio do servizo non pode executar, ou escribe nun directorio cuxa etiqueta o prohibe.

Le o rexistro AVC xunto ao erro do hook

Unha denegación AVC nomea os campos que deciden o caso: o contexto de orixe do proceso, o contexto de destino do obxecto, a clase de obxecto e o permiso concreto que se denegou. Le os catro antes de formular unha teoría, porque unha denegación de execución e unha de escritura teñen reparacións completamente distintas.

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

O contexto de orixe debería coincidir co dominio no que o servizo se executa realmente, e o contexto de destino coa etiqueta do ficheiro ou directorio que tocou a operación. Se algún dos dous non encaixa co erro que persegues, estás a ler outro evento.

Anota a versión da política e a ruta exacta do executable xunto ao rexistro. Un nome de dominio que aparece na política dunha distribución é evidencia sobre esa instalación, non unha garantía de que outra compilación inclúa as mesmas regras. Ese contexto é o que permite que outra persoa reproduza a túa conclusión no seu propio host. Sen el, o rexistro lese como unha anécdota e non como unha proba.

Etiqueta, configuración ou política: tres reparacións

A primeira reparación é unha etiqueta que non coincide coa localización instalada do ficheiro. Un script copiado ao seu sitio con cp ou escrito por un editor pode levar unha etiqueta predeterminada que o dominio do servizo non pode usar, e restaurar o contexto esperado arranxa iso sen tocar a política.

A segunda é a configuración. A distribución pode ofrecer unha forma admitida de executar a operación, un directorio documentado para o axudante ou un paquete de política actualizado que xa o permite. Cambiar a túa disposición pola admitida é máis barato que escribir política e sobrevive ás actualizacións.

A terceira é unha regra realmente ausente, e debería ser o último recurso. Xera un candidato coas ferramentas de auditoría, le o que permite realmente, redúceo á operación e ao dominio que observaches, e fai que outra persoa o revise antes de que se acerque á produción.

Por que un módulo allow antigo non é a resposta

Os resultados de busca para este fallo están cheos de módulos prefabricados, a miúdo para unha ferramenta que o hook xa non chama. Instalar un concede permisos que poden non ter nada que ver coa túa denegación, e deixa a desaliñación real no seu sitio mentres engade un burato permanente.

Tamén oculta o seguinte fallo. Un módulo que permite unha clase ampla de operacións fará desaparecer este erro e converterá o seguinte en algo moito máis difícil de atribuír. Eliminar o módulo máis adiante tamén é un cambio que ninguén quere planificar, así que o atallo tende a volverse permanente.

A comparación disciplinada é entre a denegación que podes ler e o cambio que propós. A guía de solución de problemas de SELinux de Red Hat sitúa as comprobacións de etiquetaxe e configuración por diante da política xerada exactamente por este motivo. Se non hai unha denegación correspondente no rexistro, probablemente SELinux non sexa o teu problema, e os problemas de ruta, de sandbox ou de permisos seguen abertos.