Root en una terminal, denegado bajo SELinux: por qué falla el hook

Ejecuta el script up como root, se completa, y el mismo script falla cuando el servicio lo invoca. Nada de los permisos del archivo ha cambiado, así que el siguiente paso natural es relajarlos de nuevo, lo que no arregla nada. En un host con SELinux el factor decisivo a menudo no es quién es el proceso, sino en qué dominio se ejecuta, y root dentro de un dominio confinado sigue confinado.

El mismo comando, dos dominios de seguridad distintos

La aplicación de tipos evalúa el dominio de origen, la etiqueta de destino y la operación solicitada en conjunto. Tu sesión de terminal se ejecuta en un dominio no confinado o administrativo, y el demonio se ejecuta en el dominio que tenga asignada su unidad. Por eso, comandos idénticos producen decisiones distintas, y la diferencia es deliberada y no un fallo de la política.

Por eso comparar las dos ejecuciones solo es útil si comparas sus contextos. Ejecuta el mismo comando desde el intérprete y desde el hook, y la versión del intérprete demuestra que el binario existe y que los argumentos son correctos; no demuestra nada sobre si el servicio tiene permiso para ejecutarlo. Ejecútalo de ambas formas y compara los dominios, no solo los códigos de salida. Esa comparación es la que convierte una queja vaga sobre permisos en una pregunta concreta sobre un dominio y una etiqueta.

La forma clásica de este fallo es un ayudante que llama a una herramienta externa. El hook en sí puede estar permitido, mientras que la herramienta que invoca lleva una etiqueta que el dominio del servicio no puede ejecutar, o escribe en un directorio cuya etiqueta lo prohíbe.

Lee el registro AVC junto al error del hook

Una denegación AVC nombra los campos que deciden el caso: el contexto de origen del proceso, el contexto de destino del objeto, la clase de objeto y el permiso concreto que se denegó. Lee los cuatro antes de formular una teoría, porque una denegación de ejecución y una de escritura tienen reparaciones completamente distintas.

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

El contexto de origen debería coincidir con el dominio en el que el servicio se ejecuta realmente, y el contexto de destino con la etiqueta del archivo o directorio que tocó la operación. Si alguno de los dos no encaja con el error que persigues, estás leyendo otro evento.

Anota la versión de la política y la ruta exacta del ejecutable junto al registro. Un nombre de dominio que aparece en la política de una distribución es evidencia sobre esa instalación, no una garantía de que otra compilación incluya las mismas reglas. Ese contexto es lo que permite que otra persona reproduzca tu conclusión en su propio host. Sin él, el registro se lee como una anécdota y no como una prueba.

Etiqueta, configuración o política: tres reparaciones

La primera reparación es una etiqueta que no coincide con la ubicación instalada del archivo. Un script copiado a su sitio con cp o escrito por un editor puede llevar una etiqueta predeterminada que el dominio del servicio no puede usar, y restaurar el contexto esperado lo arregla sin tocar la política.

La segunda es la configuración. La distribución puede ofrecer una forma admitida de ejecutar la operación, un directorio documentado para el ayudante o un paquete de política actualizado que ya lo permite. Cambiar tu disposición por la admitida es más barato que escribir política y sobrevive a las actualizaciones.

La tercera es una regla realmente ausente, y debería ser el último recurso. Genera un candidato con las herramientas de auditoría, lee qué permite realmente, redúcelo a la operación y el dominio que observaste, y haz que otra persona lo revise antes de que se acerque a producción.

Por qué un módulo allow antiguo no es la respuesta

Los resultados de búsqueda para este fallo están llenos de módulos prefabricados, a menudo para una herramienta que el hook ya no llama. Instalar uno concede permisos que pueden no tener nada que ver con tu denegación, y deja la desalineación real en su sitio mientras añade un agujero permanente.

También oculta el siguiente fallo. Un módulo que permite una clase amplia de operaciones hará desaparecer este error y convertirá el siguiente en algo mucho más difícil de atribuir. Eliminar el módulo más adelante también es un cambio que nadie quiere planificar, así que el atajo tiende a volverse permanente.

La comparación disciplinada es entre la denegación que puedes leer y el cambio que propones. La guía de solución de problemas de SELinux de Red Hat sitúa las comprobaciones de etiquetado y configuración por delante de la política generada exactamente por este motivo. Si no hay una denegación correspondiente en el registro, probablemente SELinux no sea tu problema, y los problemas de ruta, de sandbox o de permisos siguen abiertos.