Per què moure un certificat VPN trenca la seva etiqueta SELinux

Els certificats poden ser al directori correcte amb un mode llegible i propietat de root, i el servei encara pot informar que no pot obrir el fitxer. En un sistema SELinux, aquesta combinació assenyala un mecanisme concret i no els permisos. L’etiqueta va viatjar amb el fitxer, perquè canviar el nom no crea cap objecte nou. L’inode va conservar el context de seguretat que tenia a la ruta antiga, i la política de la ruta nova no va tenir mai l’oportunitat d’assignar-ne un de propi.

Què fa realment un canvi de nom a una etiqueta

Un fitxer porta el seu context SELinux com a dades d’atribut lligades a l’inode. Canviar el nom dins d’un mateix sistema de fitxers canvia l’entrada de directori i res més, cosa que és ràpida i atòmica, i és la raó per la qual el context sobreviu al moviment. No es consulta cap política, no s’aplica cap valor per defecte i no s’imprimeix cap avís.

Copiar es comporta diferent. Una còpia crea un inode nou al directori de destinació, i la política assigna un context a partir del tipus d’aquest directori, així que un certificat copiat sol acabar amb l’etiqueta correcta mentre que un de mogut continua mal etiquetat. Aquesta única diferència explica la major part de la confusió en aquesta classe de tiquets.

Els moviments entre sistemes de fitxers tornen a la semàntica de còpia, així que la mateixa ordre es pot comportar diferent en dues màquines segons si /etc viu en un volum propi. Comproveu-ho abans de concloure que l’eina no és fiable. Una ullada a la taula de muntatges us diu quin tipus de moviment heu fet.

Llegiu l’etiqueta actual enfront de l’esperada

Tres ordres de només lectura responen la pregunta sense canviar res. La primera mostra què té ara el fitxer, la segona informa què espera la política per a aquesta ruta exacta, i la tercera llista cada fitxer sota el directori amb una etiqueta diferent.

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

L’execució en sec és la que cal creure, perquè anomena cada fitxer el context del qual s’allunya de la política i encara deixa el sistema intacte. Si el certificat apareix en aquesta llista, heu trobat la discrepància entre el que significa la ruta i el que afirma el fitxer. Si no hi apareix, l’etiqueta ja és la que vol la política i el vostre temps pertany a un altre lloc.

Després correlacioneu la diferència amb una denegació real. Una discordança és evidència d’una etiqueta incorrecta, no la prova que el servei hagi fallat per això, i una correcció aplicada sense una denegació corresponent al registre és una conjectura amb passos extra.

Restaureu la correspondència en lloc d’inventar una excepció

Per a una ubicació estàndard la política ja assigna la ruta, així que restorecon l’aplica i la feina està feta. Mantingueu l’abast al directori que repareu; reetiquetar tot el sistema de fitxers és lent, pertorbador i enterra l’error original sota un canvi molt gran.

Per a un directori personalitzat l’ordre importa, i invertir-lo produeix una ordre que informa d’èxit mentre no canvia res. La correspondència pertany a la política, el reetiquetatge pertany al final i l’execució en sec pertany abans de tots dos. Saltar-se aquesta darrera part és com una ruta que mai no era incorrecta acaba reetiquetada igualment.

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

restorecon aplica una correspondència; no pot inventar-ne una. Si cap regla no descriu la ruta, no hi ha res a restaurar, i per això la correspondència persistent ha d’existir abans del reetiquetatge. Anoteu quina configuració posseeix aquesta correspondència, perquè un moviment posterior, una actualització de paquet o un reetiquetatge altrament tornen a crear la fallada i la persona següent comença de zero.

Per què chcon no és la solució

chcon escriu un context directament al fitxer. Té efecte immediat i és l’opció menys duradora disponible, perquè un reetiquetatge del sistema de fitxers torna a aplicar la política i descarta els canvis manuals sense preguntar. El fitxer sembla reparat i la reparació té una data de caducitat que ningú no va escriure. El que voleu en lloc d’això és una regla que descrigui la ruta, perquè cada fitxer que hi arribi rebi el mateix tracte automàticament.

Pitjor encara, ensenya la lliçó equivocada: la correspondència subjacent encara falta, així que la fallada torna setmanes després sense cap desencadenant obvi i sense memòria de la solució temporal. Feu servir chcon només com a experiment temporal per confirmar una hipòtesi, després substituïu-lo per una correspondència que sobrevisqui al reetiquetatge següent i comproveu que la substitució és realment al seu lloc.

Quan l’etiqueta és correcta i l’accés encara falla

Comenceu pels directoris pares. El permís de travessa es comprova a cada component de la ruta, així que un certificat correctament etiquetat dins d’un directori on el servei no pot entrar continua sent il·legible. Tant SELinux com el permís ordinari han de permetre cada pas, i arreglar un no arregla l’altre.

Després comproveu la identitat del procés i l’aïllament propi del servei. Una unitat amb un aïllament restrictiu pot denegar l’accés a un fitxer que la política permetria de bon grat, i des de la línia del registre les dues causes semblen idèntiques. Confirmeu quin procés demana realment, no quin suposeu que demana.

Recordeu que les regles dontaudit poden suprimir els missatges de denegació, així que un registre d’auditoria buit és una prova feble i no una demostració. Si la política sembla correcta i l’accés encara falla, investigueu abans de generar un mòdul de permís ampli, i no desactiveu SELinux per fer desaparèixer el símptoma. Les dues dreceres produeixen un sistema que sembla funcionar i una postura de seguretat que ningú no pot descriure. Una investigació curta és millor que qualsevol de les dues.