Wêrom't it ferpleatsen fan in VPN-sertifikaat syn SELinux-label brekt

Sertifikaten kinne yn de goede map stean mei in lêsbere modus en root-eigendom, en de tsjinst kin dochs melde dat er it bestân net iepenje kin. Op in SELinux-systeem wiist dy kombinaasje op ien spesifyk meganisme en net op rjochten. It label reizge mei it bestân, want in werneaming makket gjin nij objekt. De inode hold de befeiligingskontekst dy't er op it âlde paad hie, en it belied foar it nije paad krige nea de kâns om syn eigen ta te wizen.

Wat in werneaming eins mei in label docht

In bestân draacht syn SELinux-kontekst as attribútgegevens dy't oan de inode heakje. Werneaming binnen ien bestânsysteem feroaret de mapynfier en neat oars, wat fluch en atomêr is, en de reden dat de kontekst it ferpleatsen oerlibbet. Gjin belied wurdt frege, gjin standert wurdt tapast en gjin warskôging wurdt printe.

Kopiearjen hâldt him oars. In kopy makket in nije inode yn de bestimmingsmap, en it belied wiist in kontekst ta op grûn fan it type fan dy map, dus in kopiearre sertifikaat einiget meastentiids mei it goede label, wylst in ferpleatst ien ferkeard bliuwt. Krekt dat iene ferskil ferklearret it measte fan ’e betizing yn dit soarte kaartsje.

Ferpleatsingen tusken bestânsystemen falle werom op kopy-semantyk, dus itselde kommando kin him op twa masines oars hâlde, ôfhinklik fan oft /etc op in eigen folume wennet. Kontrolearje dat foardat jo konkludearje dat it ark ûnbetrouber is. Ien eachopslach op ’e mounttabel fertelt jo hokker soarte ferpleatsing jo dien hawwe.

Lês it hjoeddeiske label tsjin it ferwachte

Trije allinnich-lêzen-kommando’s beantwurdzje de fraach sûnder eat te feroarjen. De earste lit sjen wat it bestân no hat, de twadde meldt wat it belied foar krekt dat paad ferwachtet, en de tredde listet elk bestân ûnder de map op dêr't it label fan ferskilt.

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

De droege rin is dy't fertrouwe moat, want hy neamt elk bestân dêr't de kontekst fan fan it belied ôfwikt en lit it systeem dochs ûnoanrekke. As it sertifikaat yn dy list ferskynt, hawwe jo it ferskil fûn tusken wat it paad betsjut en wat it bestân beweart. As it net ferskynt, is it label al wat it belied wol en heart jo tiid earne oars.

Korrelearje dan it ferskil mei in echte wegering. In ôfwiking is bewiis fan in ferkeard label, net bewiis dat de tsjinst dêrtroch mislearre, en in korreksje tapast sûnder in byhearrende wegering yn it log is in gissing mei ekstra stappen.

Restaurearje de mappering ynstee fan in útsûndering te betinken

Foar in standertlokaasje mappet it belied it paad al, dus restorecon past it ta en it wurk is dien. Hâld it berik by de map dy't jo reparearje; it hiele bestânsysteem werlabelje is stadich, fersteurend, en it begraaft de oarspronklike flater ûnder in heul grutte feroaring.

Foar in oanpaste map is de folchoarder wichtich, en it omkearden dêrfan jout in kommando dat sukses meldt wylst neat feroaret. De mappering heart yn it belied, it werlabeljen heart oan ’e ein, en de droege rin heart foar beide. It lêste part oerslaan is hoe't in paad dat nea ferkeard wie dochs werlabelt wurdt.

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

restorecon past in mappering ta; it kin der gjin betinke. As gjin inkelde regel it paad beskriuwt, is der neat om fan te restaurearjen, en dêrom moat de bliuwende mappering bestean foardat it werlabeljen. Notearje hokker konfiguraasje dy mappering besit, want oars meitsje in lettere ferpleatsing, in pakketfernijing of in werlabeljen de flater op ’e nij en begjint de folgjende persoan by nul.

Wêrom chcon net de oplossing is

chcon skriuwt in kontekst direkt op it bestân. It wurket daliks en it is de minst duorsume opsje dy't beskikber is, want in werlabeljen fan it bestânsysteem past it belied op ’e nij ta en smyt hânmjittige feroarings fuort sûnder te freegjen. It bestân liket reparearre en de reparaasje hat in ferfaldatum dy't nimmen opskreaun hat. Wat jo ynstee wolle, is in regel dy't it paad beskriuwt, sadat elk bestân dat dêr oankomt automatysk deselde behanneling krijt.

Earst noch, it leart de ferkearde les: de ûnderlizzende mappering ûntbrekt noch hieltyd, dus de flater komt wiken letter werom sûnder in dúdlike oanlieding en sûnder oantinken oan ’e omwei. Brûk chcon allinnich as in tydlik eksperimint om in hypoteze te befêstigjen, ferfange it dan troch in mappering dy't it folgjende werlabeljen oerlibbet, en kontrolearje dat de ferfanging echt op syn plak is.

As it label goed is en tagong dochs mislearret

Begjin by de âlderlike mappen. Trochgongsrjocht wurdt kontrolearre op elk ûnderdiel fan it paad, dus in goed labele sertifikaat yn in map dêr't de tsjinst net yn komme kin, bliuwt ûnlêsber. Sawol SELinux as gewoane rjochten moatte elke stap tastean, en it iene reparearje reparearret it oare net.

Kontrolearje dan prosesidentiteit en de eigen sânbak fan ’e tsjinst. In ienheid mei in beheinende sânbak kin tagong wegerje ta in bestân dat it belied graach tastean soe, en út ’e logrigel lykje de twa oarsaken identyk. Befêstigje hokker proses echt freget, net hokker jo oannimme dat freget.

Tink derom dat dontaudit-regels wegeringsberjochten ûnderdrukke kinne, dus in leech auditspoar is swak bewiis ynstee fan bewiis. As it belied goed liket en tagong dochs mislearret, ûndersykje dan foardat jo in breed tastieningsmodule generearje, en skeakelje SELinux net út om it symptoom ferdwine te litten. Beide fluchten jouwe in systeem dat liket te wurkjen en in befeiligingsposysje dy't nimmen beskriuwe kin. In koart ûndersyk is better as ien fan beide.