Prečo premiestnenie certifikátu VPN rozbije jeho štítok SELinux

Certifikáty môžu ležať v správnom adresári s čitateľným režimom a vlastníctvom roota a služba napriek tomu môže hlásiť, že súbor nedokáže otvoriť. V systéme SELinux táto kombinácia ukazuje na jeden konkrétny mechanizmus, nie na oprávnenia. Štítok cestoval so súborom, pretože premenovanie nevytvára nový objekt. Inode si zachoval bezpečnostný kontext, ktorý mal na starej ceste, a politika pre novú cestu nikdy nedostala šancu priradiť ten svoj.

Čo premenovanie skutočne robí so štítkom

Súbor nesie svoj kontext SELinux ako údaje atribútu pripojené k inode. Premenovanie v rámci jedného súborového systému mení položku adresára a nič iné, čo je rýchle a atomické, a je to dôvod, prečo kontext premiestnenie prežije. Žiadna politika sa nekonsultuje, žiadna predvolená hodnota sa neuplatní a žiadne varovanie sa nevytlačí.

Kopírovanie sa správa inak. Kópia vytvorí v cieľovom adresári nový inode a politika priradí kontext podľa typu tohto adresára, takže kopírovaný certifikát zvyčajne skončí so správnym štítkom, zatiaľ čo premiestnený zostane nesprávny. Práve tento jediný rozdiel vysvetľuje väčšinu zmätku v tejto triede tiketov.

Premiestnenia medzi súborovými systémami sa vracajú k sémantike kopírovania, takže ten istý príkaz sa môže na dvoch počítačoch správať inak podľa toho, či /etc žije na vlastnom zväzku. Overte to, než usúdite, že nástroj je nespoľahlivý. Jeden pohľad na tabuľku pripojení vám povie, aký druh premiestnenia ste vykonali.

Prečítajte aktuálny štítok oproti očakávanému

Tri príkazy iba na čítanie odpovedajú na otázku bez toho, aby čokoľvek zmenili. Prvý ukazuje, čo súbor teraz má, druhý hlási, čo politika očakáva pre presne túto cestu, a tretí vypisuje každý súbor v adresári, ktorého štítok sa líši.

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

Dôverovať treba skúšobnému behu, pretože pomenúva každý súbor, ktorého kontext sa odchyľuje od politiky, a systém napriek tomu necháva nedotknutý. Ak sa certifikát v tomto zozname objaví, našli ste rozpor medzi tým, čo cesta znamená, a tým, čo súbor tvrdí. Ak sa neobjaví, štítok už je to, čo politika chce, a váš čas patrí inam.

Potom korelujte rozdiel so skutočným odmietnutím. Nezhoda je dôkazom nesprávneho štítku, nie dôkazom, že služba preto zlyhala, a oprava vykonaná bez zodpovedajúceho odmietnutia v zázname je dohad s krokmi navyše.

Obnovte mapovanie namiesto vymýšľania výnimky

Pre štandardné umiestnenie politika cestu už mapuje, takže restorecon ju použije a práca je hotová. Držte rozsah v adresári, ktorý opravujete; preznačenie celého súborového systému je pomalé, rušivé a pochová pôvodnú chybu pod veľmi veľkou zmenou.

Pre vlastný adresár záleží na poradí a jeho obrátenie vytvorí príkaz, ktorý hlási úspech, no nič nemení. Mapovanie patrí do politiky, preznačenie patrí na koniec a skúšobný beh patrí pred oboje. Preskočenie tejto poslednej časti je spôsob, akým sa cesta, ktorá nikdy nebola nesprávna, napriek tomu preznačí.

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

restorecon aplikuje mapovanie; nedokáže ho vymyslieť. Ak cestu neopisuje žiadne pravidlo, nie je z čoho obnovovať, preto musí trvalé mapovanie existovať pred preznačením. Zapíšte, ktorá konfigurácia toto mapovanie vlastní, pretože inak neskoršie premiestnenie, aktualizácia balíka alebo preznačenie znova vytvoria poruchu a ďalší človek začína od nuly.

Prečo chcon nie je riešenie

chcon zapisuje kontext priamo na súbor. Účinkuje okamžite a je to najmenej trvácna dostupná možnosť, pretože preznačenie súborového systému znova uplatní politiku a zahodí manuálne zmeny bez pýtania. Súbor vyzerá opravený a oprava má dátum vypršania, ktorý nikto nezapísal. Namiesto toho chcete pravidlo opisujúce cestu, aby každý súbor, ktorý tam dorazí, dostal rovnaké zaobchádzanie automaticky.

Horšie, učí nesprávnu lekciu: základné mapovanie stále chýba, takže porucha sa vracia po týždňoch bez zjavného spúšťača a bez pamäti na obchvat. chcon používajte iba ako dočasný experiment na potvrdenie hypotézy, potom ho nahraďte mapovaním, ktoré prežije ďalšie preznačenie, a overte, že náhrada je skutočne na mieste.

Keď je štítok správny a prístup napriek tomu zlyháva

Začnite nadradenými adresármi. Priechodové oprávnenie sa kontroluje na každej komponente cesty, takže správne označený certifikát v adresári, do ktorého služba nemôže vstúpiť, zostáva nečitateľný. SELinux aj bežné oprávnenie musia povoliť každý krok a oprava jedného neopraví druhé.

Potom skontrolujte identitu procesu a vlastný sandbox služby. Jednotka s reštriktívnym sandboxom môže odmietnuť prístup k súboru, ktorý by politika rada povolila, a z riadku záznamu obe príčiny vyzerajú rovnako. Potvrďte, ktorý proces skutočne žiada, nie ktorý predpokladáte, že žiada.

Pamätajte, že pravidlá dontaudit môžu potlačiť správy o odmietnutí, takže prázdny auditný záznam je slabý dôkaz, nie dôkaz. Ak politika vyzerá správne a prístup napriek tomu zlyháva, preskúmajte to pred vygenerovaním širokého modulu povolení a nevypínajte SELinux, aby symptóm zmizol. Obe skratky dajú systém, ktorý vyzerá, že funguje, a bezpečnostný postoj, ktorý nikto nevie opísať. Krátke prešetrenie je lepšie než ktorákoľvek z nich.