Waarom het verplaatsen van een VPN-certificaat het SELinux-label breekt

Certificaten kunnen in de juiste map staan met een leesbare modus en root-eigendom, en de dienst kan alsnog melden dat hij het bestand niet kan openen. Op een SELinux-systeem wijst die combinatie op één specifiek mechanisme en niet op rechten. Het label reisde mee met het bestand, omdat een hernoeming geen nieuw object maakt. De inode behield de beveiligingscontext die hij op het oude pad had, en het beleid voor het nieuwe pad kreeg nooit de kans om zijn eigen context toe te wijzen.

Wat een hernoeming feitelijk met een label doet

Een bestand draagt zijn SELinux-context als attribuutgegevens die aan de inode hangen. Hernoemen binnen één bestandssysteem verandert de mapinvoer en niets anders, wat snel en atomair is, en de reden dat de context de verplaatsing overleeft. Er wordt geen beleid geraadpleegd, geen standaardwaarde toegepast en geen waarschuwing afgedrukt.

Kopiëren gedraagt zich anders. Een kopie maakt een nieuwe inode in de doelmap, en het beleid wijst een context toe op basis van het type van die map, dus een gekopieerd certificaat krijgt meestal het juiste label, terwijl een verplaatst exemplaar onjuist blijft. Dat ene verschil verklaart het grootste deel van de verwarring in dit soort tickets.

Verplaatsingen tussen bestandssystemen vallen terug op kopieersemantiek, dus hetzelfde commando kan zich op twee machines anders gedragen, afhankelijk van of /etc op een eigen volume staat. Controleer dat voordat u concludeert dat het gereedschap onbetrouwbaar is. Eén blik op de mounttabel vertelt u welk soort verplaatsing u hebt uitgevoerd.

Lees het huidige label tegen het verwachte

Drie alleen-lezen-commando's beantwoorden de vraag zonder iets te wijzigen. De eerste toont wat het bestand nu heeft, de tweede meldt wat het beleid voor precies dat pad verwacht, en de derde somt elk bestand onder de map op waarvan het label afwijkt.

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

De proefrun is degene die u moet vertrouwen, want hij noemt elk bestand waarvan de context van het beleid afwijkt en laat het systeem toch onaangeroerd. Als het certificaat in die lijst voorkomt, hebt u de discrepantie gevonden tussen wat het pad betekent en wat het bestand beweert. Komt het er niet in voor, dan is het label al wat het beleid wil en hoort uw tijd ergens anders.

Koppel het verschil vervolgens aan een werkelijke weigering. Een afwijking is bewijs van een verkeerd label, niet het bewijs dat de dienst daardoor faalde, en een correctie die zonder overeenkomstige weigering in het log wordt toegepast is een gok met extra stappen.

Herstel de toewijzing in plaats van een uitzondering te verzinnen

Voor een standaardlocatie koppelt het beleid het pad al, dus restorecon past het toe en het werk is gedaan. Houd de scope bij de map die u repareert; het hele bestandssysteem opnieuw labelen is traag, verstorend, en het begraaft de oorspronkelijke fout onder een zeer grote wijziging.

Voor een aangepaste map is de volgorde belangrijk, en die omdraaien levert een commando op dat succes meldt terwijl er niets verandert. De toewijzing hoort in het beleid, het opnieuw labelen hoort aan het eind, en de proefrun hoort vóór beide. Dat laatste deel overslaan is hoe een pad dat nooit fout was toch opnieuw wordt gelabeld.

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

restorecon past een toewijzing toe; het kan er geen verzinnen. Als geen enkele regel het pad beschrijft, is er niets om van te herstellen, en daarom moet de blijvende toewijzing bestaan vóór het opnieuw labelen. Noteer welke configuratie die toewijzing bezit, want anders schept een latere verplaatsing, een pakketupdate of een herlabeling de fout opnieuw en begint de volgende persoon bij nul.

Waarom chcon niet de oplossing is

chcon schrijft een context rechtstreeks op het bestand. Het werkt onmiddellijk en het is de minst duurzame optie die beschikbaar is, omdat een herlabeling van het bestandssysteem het beleid opnieuw toepast en handmatige wijzigingen zonder vragen weggooit. Het bestand lijkt gerepareerd en de reparatie heeft een vervaldatum die niemand heeft opgeschreven. Wat u in plaats daarvan wilt, is een regel die het pad beschrijft, zodat elk bestand dat daar aankomt automatisch dezelfde behandeling krijgt.

Erger nog, het leert de verkeerde les: de onderliggende toewijzing ontbreekt nog steeds, dus de fout komt weken later terug zonder duidelijke trigger en zonder herinnering aan de omweg. Gebruik chcon alleen als tijdelijk experiment om een hypothese te bevestigen, vervang het daarna door een toewijzing die de volgende herlabeling overleeft, en controleer of de vervanging echt aanwezig is.

Wanneer het label juist is en toegang toch mislukt

Begin bij de bovenliggende mappen. Doorgangsrecht wordt op elk onderdeel van het pad gecontroleerd, dus een correct gelabeld certificaat in een map waar de dienst niet in kan, blijft onleesbaar. Zowel SELinux als de gewone toestemming moeten elke stap toestaan, en het ene repareren repareert het andere niet.

Controleer daarna de procesidentiteit en de eigen sandbox van de dienst. Een unit met een beperkende sandbox kan toegang weigeren tot een bestand dat het beleid graag zou toestaan, en uit de logregel zien de twee oorzaken er identiek uit. Bevestig welk proces werkelijk vraagt, niet welk u aanneemt dat vraagt.

Onthoud dat dontaudit-regels weigeringsberichten kunnen onderdrukken, dus een leeg auditlog is zwak bewijs en geen bewijs. Als het beleid juist lijkt en toegang toch mislukt, onderzoek het dan voordat u een brede toestemmingsmodule genereert, en schakel SELinux niet uit om het symptoom te laten verdwijnen. Beide snelwegen leveren een systeem dat lijkt te werken en een beveiligingshouding die niemand kan beschrijven. Een kort onderzoek is beter dan beide.