Miért töri el a VPN-tanúsítvány SELinux-címkéjét az áthelyezés

A tanúsítványok a helyes könyvtárban lehetnek olvasható móddal és root-tulajdonnal, és a szolgáltatás mégis jelezheti, hogy nem tudja megnyitni a fájlt. Egy SELinux-rendszeren ez a kombináció egy konkrét mechanizmusra utal, nem az engedélyekre. A címke a fájllal együtt utazott, mert az átnevezés nem hoz létre új objektumot. Az inode megtartotta azt a biztonsági kontextust, amely a régi útvonalon volt hozzá rendelve, és az új útvonal szabályzata soha nem kapott esélyt a sajátjának hozzárendelésére.

Mit tesz valójában az átnevezés egy címkével

Egy fájl az SELinux-kontextusát az inode-hoz kapcsolt attribútumadatként hordozza. Az átnevezés egy fájlrendszeren belül a könyvtárbejegyzést változtatja meg és semmi mást, ami gyors és atomi, és ez az oka, hogy a kontextus túléli az áthelyezést. Semmilyen szabályzatot nem kérdezünk meg, semmilyen alapértelmezés nem érvényesül, és semmilyen figyelmeztetés nem jelenik meg.

A másolás másképp viselkedik. Egy másolat új inode-ot hoz létre a célkönyvtárban, és a szabályzat a könyvtár típusa alapján rendel kontextust, ezért a másolt tanúsítvány általában helyes címkét kap, míg az áthelyezett hibás marad. Ez az egyetlen különbség magyarázza a zavar nagy részét ebben a jegyosztályban.

A fájlrendszerek közötti áthelyezés visszaesik a másolási szemantikára, ezért ugyanaz a parancs két gépen eltérően viselkedhet attól függően, hogy /etc saját köteten él-e. Ellenőrizze ezt, mielőtt arra jutna, hogy az eszköz megbízhatatlan. Egy pillantás a csatolási táblázatra megmondja, milyen típusú áthelyezést végzett.

Olvassa össze a jelenlegi címkét az elvárttal

Három csak olvasó parancs válaszol a kérdésre anélkül, hogy bármit változtatna. Az első megmutatja, mi van most a fájlnál, a második jelzi, mit vár a szabályzat erre a pontos útvonalra, a harmadik pedig felsorolja a könyvtár alatti minden fájlt, amelynek a címkéje eltér.

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

A száraz futás az, amelyben meg lehet bízni, mert megnevezi minden fájlt, amelynek a kontextusa eltér a szabályzattól, és közben érintetlenül hagyja a rendszert. Ha a tanúsítvány megjelenik ezen a listán, megtalálta az eltérést aközött, amit az útvonal jelent, és amit a fájl állít. Ha nem jelenik meg, a címke már az, amit a szabályzat akar, és az ideje máshová tartozik.

Ezután korrelálja a különbséget egy tényleges elutasítással. Az eltérés hibás címke bizonyítéka, nem annak bizonyítéka, hogy a szolgáltatás emiatt hibázott, és a naplóban megfelelő elutasítás nélkül alkalmazott javítás extra lépésekkel járó találgatás.

Állítsa vissza a leképezést ahelyett, hogy kivételt találna ki

Szabványos helyen a szabályzat már leképezi az útvonalat, ezért restorecon alkalmazza azt, és a munka kész. Tartsa a hatókört a javított könyvtárnál; a teljes fájlrendszer újracímkézése lassú, zavaró, és nagyon nagy változás alá temeti az eredeti hibát.

Egyéni könyvtár esetén a sorrend számít, és a megfordítása olyan parancsot ad, amely sikert jelent, miközben semmit sem változtat. A leképezés a szabályzathoz tartozik, az újracímkézés a végéhez, a száraz futás pedig mindkettő elé. Ennek az utolsó résznek a kihagyása az, ahogyan egy soha nem hibás útvonal mégis újracímkéződik.

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

restorecon leképezést alkalmaz; kitalálni nem tud egyet. Ha egyetlen szabály sem írja le az útvonalat, nincs mit visszaállítani, ezért a tartós leképezésnek az újracímkézés előtt kell léteznie. Jegyezze fel, melyik konfiguráció birtokolja ezt a leképezést, mert különben egy későbbi áthelyezés, csomagfrissítés vagy újracímkézés újra létrehozza a hibát, és a következő ember nulláról kezdi.

Miért nem a chcon a megoldás

chcon közvetlenül a fájlra ír egy kontextust. Azonnal hat, és ez a legkevésbé tartós elérhető lehetőség, mert a fájlrendszer újracímkézése újra alkalmazza a szabályzatot, és kérdés nélkül eldobja a kézi módosításokat. A fájl javítottnak látszik, és a javításnak van egy lejárati dátuma, amelyet senki nem írt le. Amit helyette szeretne, az egy szabály, amely leírja az útvonalat, hogy minden oda érkező fájl automatikusan ugyanazt a kezelést kapja.

Ráadásul rossz leckét tanít: a mögöttes leképezés továbbra is hiányzik, ezért a hiba hetekkel később visszatér nyilvánvaló kiváltó ok és a megkerülés emléke nélkül. A chcon-ot csak ideiglenes kísérletként használja egy hipotézis megerősítésére, majd cserélje le egy olyan leképezésre, amely túléli a következő újracímkézést, és ellenőrizze, hogy a csere valóban a helyén van.

Amikor a címke helyes, és a hozzáférés mégis meghiúsul

Kezdje a szülőkönyvtárakkal. Az átjárási engedélyt az útvonal minden összetevőjén ellenőrzik, ezért egy helyesen címkézett tanúsítvány egy olyan könyvtárban, amelybe a szolgáltatás nem tud belépni, továbbra is olvashatatlan. A SELinuxnak és a szokásos engedélynek is engedélyeznie kell minden lépést, és az egyik javítása nem javítja a másikat.

Ezután ellenőrizze a folyamat identitását és a szolgáltatás saját homokozóját. Egy korlátozó homokozóval rendelkező egység megtagadhatja a hozzáférést egy olyan fájlhoz, amelyet a szabályzat szívesen engedélyezne, és a naplósorból a két ok azonosnak látszik. Erősítse meg, melyik folyamat kérdez valójában, és ne azt, amelyikről feltételezi, hogy kérdez.

Ne feledje, hogy a dontaudit szabályok elnyomhatják az elutasítási üzeneteket, ezért az üres auditnapló gyenge bizonyíték, nem bizonyíték. Ha a szabályzat helyesnek látszik, és a hozzáférés mégis meghiúsul, vizsgálódjon, mielőtt széles engedélyező modult generálna, és ne kapcsolja ki a SELinuxot, hogy a tünet eltűnjön. Mindkét rövidítés olyan rendszert ad, amely működni látszik, és olyan biztonsági helyzetet, amelyet senki nem tud leírni. Egy rövid vizsgálat jobb bármelyiknél.