Proč přesun certifikátu VPN rozbije jeho štítek SELinux

Certifikáty mohou ležet ve správném adresáři s čitelným režimem a vlastnictvím roota a služba přesto může hlásit, že soubor nemůže otevřít. V systému SELinux tato kombinace ukazuje na jeden konkrétní mechanismus, nikoli na oprávnění. Štítek cestoval se souborem, protože přejmenování nevytváří nový objekt. Inode si ponechal bezpečnostní kontext, který měl na staré cestě, a politika pro novou cestu nikdy nedostala šanci přiřadit ten svůj.

Co přejmenování skutečně dělá se štítkem

Soubor nese svůj kontext SELinux jako datová data atributu připojená k inode. Přejmenování v rámci jednoho souborového systému mění položku adresáře a nic jiného, což je rychlé a atomické, a je to důvod, proč kontext přesun přežije. Žádná politika se nekonzultuje, žádná výchozí hodnota se neuplatní a žádné varování se nevytiskne.

Kopírování se chová jinak. Kopie vytvoří v cílovém adresáři nový inode a politika přiřadí kontext podle typu tohoto adresáře, takže kopírovaný certifikát obvykle skončí se správným štítkem, zatímco přesunutý zůstane špatný. Právě tento jediný rozdíl vysvětluje většinu zmatení v této třídě tiketů.

Přesuny mezi souborovými systémy se vracejí k sémantice kopírování, takže stejný příkaz se může na dvou počítačích chovat různě podle toho, zda /etc žije na vlastním svazku. Ověřte to, než usoudíte, že nástroj je nespolehlivý. Jeden pohled na tabulku připojení vám řekne, jaký druh přesunu jste provedli.

Přečtěte aktuální štítek proti očekávanému

Tři příkazy pouze pro čtení odpovídají na otázku, aniž by cokoli měnily. První ukazuje, co soubor nyní má, druhý hlásí, co politika pro tuto přesnou cestu očekává, a třetí vypisuje každý soubor v adresáři, jehož štítek se liší.

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

Zkušební běh je ten, kterému se dá věřit, protože pojmenuje každý soubor, jehož kontext se odchyluje od politiky, a přesto systém nechá nedotčený. Pokud se certifikát v tomto seznamu objeví, našli jste rozpor mezi tím, co cesta znamená, a tím, co soubor tvrdí. Pokud se neobjeví, štítek už je to, co politika chce, a váš čas patří jinam.

Pak korelujte rozdíl se skutečným odmítnutím. Neshoda je důkazem špatného štítku, ne důkazem, že kvůli tomu služba selhala, a oprava provedená bez odpovídajícího odmítnutí v záznamu je dohad s kroky navíc.

Obnovte mapování místo vymýšlení výjimky

Pro standardní umístění politika cestu už mapuje, takže restorecon ji použije a práce je hotová. Držte rozsah v adresáři, který opravujete; přeznačení celého souborového systému je pomalé, rušivé a pohřbí původní chybu pod velmi velkou změnou.

U vlastního adresáře záleží na pořadí a jeho obrácení vytvoří příkaz, který hlásí úspěch, ale nic nemění. Mapování patří do politiky, přeznačení patří na konec a zkušební běh patří před obojí. Přeskočení této poslední části je způsob, jakým se cesta, která nikdy nebyla špatná, přesto přeznačí.

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

restorecon aplikuje mapování; nemůže ho vymyslet. Pokud cestu nepopisuje žádné pravidlo, není z čeho obnovovat, a proto musí trvalé mapování existovat před přeznačením. Zapište, která konfigurace toto mapování vlastní, protože pozdější přesun, aktualizace balíčku nebo přeznačení jinak znovu vytvoří závadu a další člověk začíná od nuly.

Proč chcon není řešení

chcon zapisuje kontext přímo na soubor. Účinkuje okamžitě a je to nejméně trvanlivá dostupná možnost, protože přeznačení souborového systému znovu uplatní politiku a zahodí ruční změny, aniž by se ptalo. Soubor vypadá opraveně a oprava má datum vypršení, které nikdo nezapsal. Co místo toho chcete, je pravidlo popisující cestu, aby každý soubor, který tam dorazí, dostal stejné zacházení automaticky.

Hůř, učí špatnou lekci: základní mapování stále chybí, takže závada se vrací po týdnech bez zjevného spouštěče a bez paměti na obchvat. chcon používejte jen jako dočasný experiment k potvrzení hypotézy, pak ho nahraďte mapováním, které přežije další přeznačení, a ověřte, že náhrada je skutečně na místě.

Když je štítek správný a přístup přesto selhává

Začněte nadřazenými adresáři. Průchodové oprávnění se kontroluje na každé komponentě cesty, takže správně označený certifikát v adresáři, do kterého služba nemůže vstoupit, zůstává nečitelný. SELinux i běžné oprávnění musí povolit každý krok a oprava jednoho neopraví druhé.

Pak zkontrolujte identitu procesu a vlastní sandbox služby. Unit s restriktivním sandboxem může odmítnout přístup k souboru, který by politika ráda povolila, a z řádku záznamu obě příčiny vypadají stejně. Potvrďte, který proces skutečně žádá, ne který předpokládáte, že žádá.

Pamatujte, že pravidla dontaudit mohou potlačit zprávy o odmítnutí, takže prázdný auditní záznam je slabý důkaz, ne důkaz. Pokud politika vypadá správně a přístup přesto selhává, prozkoumejte to, než vygenerujete široký modul povolení, a nevypínejte SELinux, aby symptom zmizel. Obě zkratky dají systém, který vypadá, že funguje, a bezpečnostní postoj, který nikdo nedokáže popsat. Krátké prošetření je lepší než kterákoli z nich.