Waarom die skuif van ’n VPN-sertifikaat sy SELinux-etiket breek

Sertifikate kan in die korrekte gids sit met ’n leesbare modus en root-eienaarskap, en die diens kan steeds rapporteer dat hy die lêer nie kan oopmaak nie. Op ’n SELinux-stelsel dui daardie kombinasie op een spesifieke meganisme eerder as op regte. Die etiket het saam met die lêer gereis, want ’n herbenoeming skep nie ’n nuwe objek nie. Die inode het die sekuriteitskonteks behou wat hy by die ou pad gehad het, en die beleid vir die nuwe pad het nooit die kans gekry om sy eie toe te wys nie.

Wat ’n herbenoeming werklik aan ’n etiket doen

’n Lêer dra sy SELinux-konteks as kenmerkdata wat aan die inode geheg is. Herbenoeming binne een lêerstelsel verander die gidsinskrywing en niks anders nie, wat vinnig en atomies is, en die rede waarom die konteks die skuif oorleef. Geen beleid word geraadpleeg nie, geen verstek word toegepas nie, en geen waarskuwing word gedruk nie.

Kopiëring werk anders. ’n Kopie skep ’n nuwe inode in die bestemmingsgids, en die beleid wys ’n konteks toe op grond van daardie gids se tipe, so ’n gekopieerde sertifikaat kry gewoonlik die regte etiket terwyl ’n verskuifde een verkeerd bly. Daardie enkele verskil verduidelik die meeste verwarring in hierdie klas kaartjie.

Verskuiwings oor lêerstelsels heen val terug op kopie-semantiek, so dieselfde opdrag kan op twee masjiene anders werk, afhangend daarvan of /etc op sy eie volume woon. Gaan dit na voordat jy aflei dat die gereedskap onbetroubaar is. Een blik op die monteertabel vertel watter soort skuif jy gedoen het.

Lees die huidige etiket teen die verwagte een

Drie lees-alleen-opdragte beantwoord die vraag sonder om iets te verander. Die eerste wys wat die lêer nou het, die tweede rapporteer wat beleid vir daardie presiese pad verwag, en die derde lys elke lêer onder die gids wie se etiket verskil.

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

Die droë loop is die een om te vertrou, want dit noem elke lêer wie se konteks van beleid afwyk en laat die stelsel steeds onaangeraak. As die sertifikaat in daardie lys verskyn, het jy die verskil gevind tussen wat die pad beteken en wat die lêer beweer. As dit nie verskyn nie, is die etiket reeds wat beleid wil hê, en jou tyd hoort elders.

Korreleer dan die verskil met ’n werklike weiering. ’n Wanpassing is bewys van ’n verkeerde etiket, nie bewys dat die diens daaraan gefaal het nie, en ’n regstelling wat toegepas word sonder ’n ooreenstemmende weiering in die log, is ’n raaiskoot met ekstra stappe.

Herstel die kartering eerder as om ’n uitsondering te versin

Vir ’n standaardligging karteer die beleid reeds die pad, so restorecon pas dit toe en die werk is klaar. Hou die omvang by die gids wat jy herstel; om die hele lêerstelsel te herbenoem is stadig, ontwrigtend, en dit begrawe die oorspronklike fout onder ’n baie groot verandering.

Vir ’n pasgemaakte gids maak die volgorde saak, en om dit om te keer lewer ’n opdrag wat sukses rapporteer terwyl niks verander nie. Die kartering hoort in beleid, die herbenoeming hoort aan die einde, en die droë loop hoort voor albei. Om daardie laaste deel oor te slaan, is hoe ’n pad wat nooit verkeerd was nie, tog herbenoem word.

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

restorecon pas ’n kartering toe; dit kan nie een versin nie. As geen reël die pad beskryf nie, is daar niks om van te herstel nie, en daarom moet die blywende kartering bestaan voordat die herbenoeming plaasvind. Teken aan watter konfigurasie daardie kartering besit, want ’n latere skuif, ’n pakketopdatering of ’n herbenoeming skep andersins die fout weer, en die volgende persoon begin van nul.

Waarom chcon nie die oplossing is nie

chcon skryf ’n konteks direk op die lêer. Dit werk onmiddellik en dit is die mins duursame opsie beskikbaar, want ’n lêerstelsel-herbenoeming pas beleid weer toe en gooi handmatige veranderinge weg sonder om te vra. Die lêer lyk herstel en die herstelling het ’n vervaldatum wat niemand neergeskryf het nie. Wat jy eerder wil hê, is ’n reël wat die pad beskryf, sodat elke lêer wat daar aankom outomaties dieselfde behandeling kry.

Erger nog, dit leer die verkeerde les: die onderliggende kartering ontbreek steeds, so die fout kom weke later terug sonder ’n duidelike sneller en sonder geheue van die noodoplossing. Gebruik chcon slegs as ’n tydelike eksperiment om ’n hipotese te bevestig, vervang dit dan met ’n kartering wat die volgende herbenoeming oorleef, en kontroleer dat die vervanging werklik in plek is.

Wanneer die etiket reg is en toegang steeds misluk

Begin by die ouergidse. Deurgangsregte word op elke komponent van die pad nagegaan, so ’n korrek geëtiketteerde sertifikaat in ’n gids waar die diens nie kan ingaan nie, bly onleesbaar. SELinux en gewone regte moet albei elke stap toelaat, en om een reg te maak, maak nie die ander reg nie.

Kontroleer dan prosesidentiteit en die diens se eie sandkassering. ’n Eenheid met ’n beperkende sandkas kan toegang weier tot ’n lêer wat die beleid graag sou toelaat, en uit die loglyn lyk die twee oorsake identies. Bevestig watter proses werklik vra, nie watter een jy aanneem vra nie.

Onthou dat dontaudit-reëls weieringsboodskappe kan onderdruk, so ’n leë ouditlog is swak bewyse eerder as bewys. As die beleid reg lyk en toegang steeds misluk, ondersoek voordat jy ’n breë toelaatmodule genereer, en moenie SELinux afskakel om die simptoom te laat verdwyn nie. Albei kortpaaie lewer ’n stelsel wat werk asof dit werk en ’n sekuriteitsposisie wat niemand kan beskryf nie. ’n Kort ondersoek is beter as enigeen van die twee.