Por qué mover un certificado VPN rompe su etiqueta SELinux

Los certificados pueden estar en el directorio correcto con un modo legible y propiedad de root, y el servicio aun así puede informar de que no puede abrir el archivo. En un sistema SELinux, esa combinación apunta a un mecanismo concreto y no a los permisos. La etiqueta viajó con el archivo, porque renombrar no crea un objeto nuevo. El inodo conservó el contexto de seguridad que tenía en la ruta antigua, y la política de la ruta nueva nunca tuvo la oportunidad de asignar el suyo.

Qué hace realmente un cambio de nombre a una etiqueta

Un archivo lleva su contexto SELinux como datos de atributo ligados al inodo. Renombrar dentro de un mismo sistema de archivos cambia la entrada de directorio y nada más, lo que es rápido y atómico, y es la razón por la que el contexto sobrevive al movimiento. No se consulta ninguna política, no se aplica ningún valor predeterminado y no se imprime ninguna advertencia.

Copiar se comporta distinto. Una copia crea un inodo nuevo en el directorio de destino, y la política asigna un contexto a partir del tipo de ese directorio, así que un certificado copiado suele acabar con la etiqueta correcta mientras que uno movido sigue mal etiquetado. Esa única diferencia explica la mayor parte de la confusión en esta clase de incidencias.

Los movimientos entre sistemas de archivos vuelven a la semántica de copia, así que el mismo comando puede comportarse distinto en dos máquinas según si /etc vive en un volumen propio. Compruébelo antes de concluir que la herramienta no es fiable. Un vistazo a la tabla de montajes le dice qué tipo de movimiento realizó.

Lea la etiqueta actual frente a la esperada

Tres comandos de solo lectura responden a la pregunta sin cambiar nada. El primero muestra lo que el archivo tiene ahora, el segundo informa de lo que la política espera para esa ruta exacta, y el tercero enumera cada archivo bajo el directorio cuya etiqueta difiere.

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

La ejecución en seco es la que hay que creer, porque nombra cada archivo cuyo contexto se aparta de la política y aun así deja el sistema intacto. Si el certificado aparece en esa lista, ha encontrado la discrepancia entre lo que significa la ruta y lo que afirma el archivo. Si no aparece, la etiqueta ya es la que quiere la política y su tiempo pertenece a otro sitio.

Luego correlacione la diferencia con una denegación real. Una falta de coincidencia es evidencia de una etiqueta incorrecta, no la prueba de que el servicio fallara por ella, y una corrección aplicada sin una denegación correspondiente en el registro es una conjetura con pasos extra.

Restaure la asignación en lugar de inventar una excepción

Para una ubicación estándar la política ya asigna la ruta, así que restorecon la aplica y el trabajo está hecho. Mantenga el alcance en el directorio que repara; reetiquetar todo el sistema de archivos es lento, perturbador y entierra el error original bajo un cambio muy grande.

Para un directorio personalizado el orden importa, e invertirlo produce un comando que informa de éxito mientras no cambia nada. La asignación pertenece a la política, el reetiquetado pertenece al final y la ejecución en seco pertenece antes de ambos. Saltarse esa última parte es como una ruta que nunca estuvo mal acaba reetiquetada de todos modos.

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

restorecon aplica una asignación; no puede inventar una. Si ninguna regla describe la ruta, no hay nada que restaurar, y por eso la asignación persistente debe existir antes del reetiquetado. Anote qué configuración posee esa asignación, porque de lo contrario un movimiento posterior, una actualización de paquete o un reetiquetado recrean la falla y la siguiente persona empieza de cero.

Por qué chcon no es la solución

chcon escribe un contexto directamente en el archivo. Surte efecto de inmediato y es la opción menos duradera disponible, porque un reetiquetado del sistema de archivos vuelve a aplicar la política y descarta los cambios manuales sin preguntar. El archivo parece reparado y la reparación tiene una fecha de caducidad que nadie anotó. Lo que usted quiere en su lugar es una regla que describa la ruta, para que cada archivo que llegue allí reciba el mismo trato automáticamente.

Peor aún, enseña la lección equivocada: la asignación subyacente sigue faltando, así que la falla vuelve semanas después sin un desencadenante obvio y sin memoria del apaño. Use chcon solo como experimento temporal para confirmar una hipótesis, luego sustitúyalo por una asignación que sobreviva al siguiente reetiquetado y compruebe que la sustitución está realmente en su sitio.

Cuando la etiqueta es correcta y el acceso sigue fallando

Empiece por los directorios padres. El permiso de recorrido se comprueba en cada componente de la ruta, así que un certificado correctamente etiquetado dentro de un directorio al que el servicio no puede entrar sigue siendo ilegible. Tanto SELinux como el permiso ordinario deben permitir cada paso, y arreglar uno no arregla el otro.

Luego compruebe la identidad del proceso y el aislamiento propio del servicio. Una unidad con un aislamiento restrictivo puede denegar el acceso a un archivo que la política permitiría de buen grado, y desde la línea del registro las dos causas parecen idénticas. Confirme qué proceso pregunta realmente, no cuál supone que pregunta.

Recuerde que las reglas dontaudit pueden suprimir los mensajes de denegación, así que un registro de auditoría vacío es una prueba débil y no una demostración. Si la política parece correcta y el acceso sigue fallando, investigue antes de generar un módulo de permiso amplio, y no desactive SELinux para hacer desaparecer el síntoma. Ambos atajos producen un sistema que parece funcionar y una postura de seguridad que nadie puede describir. Una investigación breve es mejor que cualquiera de los dos.