Por que mover un certificado VPN rompe a súa etiqueta SELinux

Os certificados poden estar no directorio correcto cun modo lexible e propiedade de root, e o servizo aínda así pode informar de que non pode abrir o ficheiro. Nun sistema SELinux, esa combinación apunta a un mecanismo concreto e non aos permisos. A etiqueta viaxou co ficheiro, porque renomear non crea un obxecto novo. O inodo conservou o contexto de seguridade que tiña na ruta antiga, e a política da ruta nova nunca tivo a oportunidade de asignar o seu.

Que fai realmente un cambio de nome a unha etiqueta

Un ficheiro leva o seu contexto SELinux como datos de atributo ligados ao inodo. Renomear dentro dun mesmo sistema de ficheiros cambia a entrada de directorio e nada máis, o que é rápido e atómico, e é a razón pola que o contexto sobrevive ao movemento. Non se consulta ningunha política, non se aplica ningún valor predeterminado e non se imprime ningún aviso.

Copiar compórtase distinto. Unha copia crea un inodo novo no directorio de destino, e a política asigna un contexto a partir do tipo dese directorio, así que un certificado copiado adoita acabar coa etiqueta correcta mentres que un movido segue mal etiquetado. Esa única diferenza explica a maior parte da confusión nesta clase de incidencias.

Os movementos entre sistemas de ficheiros volven á semántica de copia, así que o mesmo comando pode comportarse distinto en dúas máquinas segundo se /etc vive nun volume propio. Comprobe iso antes de concluír que a ferramenta non é fiable. Unha ollada á táboa de montaxes dille que tipo de movemento realizou.

Lea a etiqueta actual fronte á esperada

Tres comandos de só lectura responden á pregunta sen cambiar nada. O primeiro mostra o que o ficheiro ten agora, o segundo informa do que a política espera para esa ruta exacta, e o terceiro enumera cada ficheiro baixo o directorio cuxa etiqueta difire.

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

A execución en seco é a que hai que crer, porque nomea cada ficheiro cuxo contexto se aparta da política e aínda así deixa o sistema intacto. Se o certificado aparece nesa lista, atopou a discrepancia entre o que significa a ruta e o que afirma o ficheiro. Se non aparece, a etiqueta xa é a que quere a política e o seu tempo pertence a outro sitio.

Despois correlacione a diferenza cunha denegación real. Unha falta de coincidencia é evidencia dunha etiqueta incorrecta, non a proba de que o servizo fallase por ela, e unha corrección aplicada sen unha denegación correspondente no rexistro é unha conxectura con pasos extra.

Restaure a asignación en lugar de inventar unha excepción

Para unha localización estándar a política xa asigna a ruta, así que restorecon aplícaa e o traballo está feito. Manteña o alcance no directorio que repara; reetiquetar todo o sistema de ficheiros é lento, perturbador e enterra o erro orixinal baixo un cambio moi grande.

Para un directorio personalizado a orde importa, e invertela produce un comando que informa de éxito mentres non cambia nada. A asignación pertence á política, o reetiquetado pertence ao final e a execución en seco pertence antes de ambos. Saltarse esa última parte é como unha ruta que nunca estivo mal acaba reetiquetada de todos os xeitos.

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

restorecon aplica unha asignación; non pode inventar unha. Se ningunha regra describe a ruta, non hai nada que restaurar, e por iso a asignación persistente debe existir antes do reetiquetado. Anote que configuración posúe esa asignación, porque doutro xeito un movemento posterior, unha actualización de paquete ou un reetiquetado recrean a falla e a seguinte persoa comeza de cero.

Por que chcon non é a solución

chcon escribe un contexto directamente no ficheiro. Surte efecto de inmediato e é a opción menos duradeira dispoñible, porque un reetiquetado do sistema de ficheiros volve aplicar a política e descarta os cambios manuais sen preguntar. O ficheiro parece reparado e a reparación ten unha data de caducidade que ninguén anotou. O que vostede quere no seu lugar é unha regra que describa a ruta, para que cada ficheiro que chegue alí reciba o mesmo trato automaticamente.

Peor aínda, ensina a lección equivocada: a asignación subxacente segue faltando, así que a falla volve semanas despois sen un desencadeante obvio e sen memoria do apaño. Use chcon só como experimento temporal para confirmar unha hipótese, despois substitúao por unha asignación que sobreviva ao seguinte reetiquetado e comprobe que a substitución está realmente no seu sitio.

Cando a etiqueta é correcta e o acceso segue fallando

Empece polos directorios pais. O permiso de percorrido compróbase en cada compoñente da ruta, así que un certificado correctamente etiquetado dentro dun directorio ao que o servizo non pode entrar segue sendo ilexible. Tanto SELinux como o permiso ordinario deben permitir cada paso, e arranxar un non arranxa o outro.

Despois comprobe a identidade do proceso e o illamento propio do servizo. Unha unidade cun illamento restritivo pode denegar o acceso a un ficheiro que a política permitiría de bo grado, e desde a liña do rexistro as dúas causas parecen idénticas. Confirme que proceso pregunta realmente, non cal supón que pregunta.

Lembre que as regras dontaudit poden suprimir as mensaxes de denegación, así que un rexistro de auditoría baleiro é unha proba feble e non unha demostración. Se a política parece correcta e o acceso segue fallando, investigue antes de xerar un módulo de permiso amplo, e non desactive SELinux para facer desaparecer o síntoma. Ambos atallos producen un sistema que parece funcionar e unha postura de seguridade que ninguén pode describir. Unha investigación breve é mellor que calquera dos dous.