Zakaj premikanje potrdila VPN pokvari njegovo oznako SELinux

Potrdila so lahko v pravi mapi z berljivim načinom in lastništvom roota, in storitev pa lahko vseeno sporoči, da datoteke ne more odpreti. V sistemu SELinux ta kombinacija kaže na en konkreten mehanizem in ne na dovoljenja. Oznaka je potovala z datoteko, ker preimenovanje ne ustvari novega predmeta. Inode je ohranil varnostni kontekst, ki ga je imel na stari poti, politika za novo pot pa ni nikoli dobila priložnosti dodeliti svojega.

Kaj preimenovanje v resnici naredi z oznako

Datoteka nosi svoj kontekst SELinux kot podatke atributa, pripete k inode. Preimenovanje znotraj enega datotečnega sistema spremeni vnos v mapi in nič drugega, kar je hitro in atomsko, in to je razlog, da kontekst premikanje preživi. Nobena politika ni vprašana, nobena privzeta vrednost ni uporabljena in nobeno opozorilo ni natisnjeno.

Kopiranje se obnaša drugače. Kopija ustvari nov inode v ciljni mapi, politika pa dodeli kontekst glede na vrsto te mape, zato kopirano potrdilo običajno dobi pravilno oznako, medtem ko premaknjeno ostane napačno. Prav ta edina razlika pojasni večino zmede v tej vrsti zahtevkov.

Premiki med datotečnimi sistemi se vrnejo k semantiki kopiranja, zato se lahko isti ukaz na dveh strojih obnaša različno, odvisno od tega, ali /etc živi na svojem nosilcu. To preverite, preden sklepate, da je orodje nezanesljivo. En pogled na tabelo priklopov vam pove, kakšno vrsto premika ste izvedli.

Preberite trenutno oznako proti pričakovani

Trije ukazi samo za branje odgovorijo na vprašanje, ne da bi karkoli spremenili. Prvi pokaže, kaj ima datoteka zdaj, drugi sporoči, kaj politika pričakuje za točno to pot, tretji pa našteje vsako datoteko v mapi, katere oznaka se razlikuje.

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

Zaupati velja poskusnemu izvajanju, ker poimenuje vsako datoteko, katere kontekst odstopa od politike, in sistem vseeno pusti nedotaknjen. Če se potrdilo pojavi na tem seznamu, ste našli neskladje med tem, kaj pot pomeni, in tem, kar datoteka trdi. Če se ne pojavi, je oznaka že taka, kot jo želi politika, in vaš čas pripada drugam.

Nato povežite razliko z dejansko zavrnitvijo. Neujemanje je dokaz napačne oznake, ne dokaz, da je storitev zaradi tega spodletela, popravek, uporabljen brez ustrezne zavrnitve v dnevniku, pa je ugibanje z dodatnimi koraki.

Obnovite preslikavo, namesto da bi si izmislili izjemo

Za standardno lokacijo politika pot že preslika, zato restorecon to uporabi in delo je opravljeno. Obseg omejite na mapo, ki jo popravljate; ponovno označevanje celotnega datotečnega sistema je počasno, moteče in izvirno napako pokoplje pod zelo veliko spremembo.

Za mapo po meri je vrstni red pomemben in njegova obrnitev ustvari ukaz, ki sporoči uspeh, ne da bi karkoli spremenil. Preslikava spada v politiko, ponovno označevanje spada na konec, poskusno izvajanje pa spada pred oboje. Preskočitev tega zadnjega dela je način, kako se pot, ki nikoli ni bila napačna, vseeno ponovno označi.

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

restorecon uporabi preslikavo; izmisliti si je ne more. Če nobeno pravilo ne opisuje poti, ni česa obnoviti, zato mora trajna preslikava obstajati pred ponovnim označevanjem. Zapišite, katera konfiguracija ima to preslikavo, saj sicer poznejši premik, posodobitev paketa ali ponovno označevanje znova ustvarijo napako in naslednja oseba začne od nič.

Zakaj chcon ni rešitev

chcon zapiše kontekst neposredno na datoteko. Učinkuje takoj in je najmanj trajna razpoložljiva možnost, ker ponovno označevanje datotečnega sistema znova uporabi politiko in zavrže ročne spremembe, ne da bi vprašalo. Datoteka je videti popravljena in popravek ima datum poteka, ki ga nihče ni zapisal. Namesto tega želite pravilo, ki opisuje pot, da vsaka datoteka, ki prispe tja, samodejno dobi enako obravnavo.

Še huje, uči napačno lekcijo: osnovna preslikava še vedno manjka, zato se napaka vrne tedne pozneje brez očitnega sprožilca in brez spomina na obhod. chcon uporabite le kot začasen poskus za potrditev hipoteze, nato ga nadomestite s preslikavo, ki preživi naslednje ponovno označevanje, in preverite, da je zamenjava res na mestu.

Ko je oznaka pravilna in dostop vseeno spodleti

Začnite z nadrejenimi mapami. Dovoljenje za prehod se preverja na vsaki komponenti poti, zato pravilno označeno potrdilo v mapi, v katero storitev ne more vstopiti, ostane neberljivo. Tako SELinux kot običajno dovoljenje morata dovoliti vsak korak in popravilo enega ne popravi drugega.

Nato preverite identiteto procesa in lasten peskovnik storitve. Enota z omejevalnim peskovnikom lahko zavrne dostop do datoteke, ki bi jo politika z veseljem dovolila, in iz vrstice dnevnika sta oba vzroka videti enaka. Potrdite, kateri proces v resnici sprašuje, ne kateri po vašem mnenju sprašuje.

Ne pozabite, da lahko pravila dontaudit zatrejo sporočila o zavrnitvi, zato je prazen revizijski dnevnik šibek dokaz in ne dokaz. Če je politika videti pravilna in dostop vseeno spodleti, raziščite, preden ustvarite širok modul dovoljenj, in ne onemogočite SELinux, da bi simptom izginil. Obe bližnjici dasta sistem, ki je videti, da deluje, in varnostno držo, ki je nihče ne more opisati. Kratka preiskava je boljša od obeh.