Root egy terminálban, SELinux alatt megtagadva: miért bukik el a hook

Rootként futtatja az up szkriptet, az lefut, majd ugyanaz a szkript meghiúsul, amikor a szolgáltatás meghívja. A fájl jogosultságaiban semmi sem változott, így a természetes következő lépés az, hogy újra lazítsa őket, ami semmit sem javít. Egy SELinux-gazdagépen a döntő tényező gyakran nem az, hogy ki a folyamat, hanem hogy melyik tartományban fut, és a root egy korlátozott tartományon belül is korlátozott marad.

Ugyanaz a parancs, két különböző biztonsági tartomány

A típusérvényesítés a forrástartományt, a célcímkét és a kért műveletet együtt értékeli. A terminálmunkamenete egy korlátlan vagy adminisztratív tartományban fut, a démon pedig abban a tartományban fut, amelyet az egységéhez rendeltek. Az azonos parancsok ezért eltérő döntéseket hoznak, és a különbség szándékos, nem pedig hiba a szabályzatban.

Ezért csak akkor hasznos a két futás összehasonlítása, ha a kontextusaikat hasonlítja össze. Futtassa ugyanazt a parancsot a héjból és a hookból; a héjból indított változat bizonyítja, hogy a bináris létezik és az argumentumok helyesek, de semmit sem bizonyít arról, hogy a szolgáltatás jogosult-e futtatni. Futtassa mindkét módon, és a tartományokat hasonlítsa össze, ne csak a kilépési kódokat. Ez az összehasonlítás teszi a homályos engedélypanaszt egy tartományra és egy címkére vonatkozó konkrét kérdéssé.

A hiba klasszikus formája egy segédprogram, amely külső eszközt hív meg. Maga a hook engedélyezett lehet, miközben a meghívott eszköz olyan címkét visel, amelyet a szolgáltatás tartománya nem futtathat, vagy olyan könyvtárba ír, amelynek címkéje ezt tiltja.

Olvassa el az AVC-rekordot a hook hibája mellett

Az AVC-elutasítás megnevezi azokat a mezőket, amelyek eldöntik az esetet: a folyamat forráskontextusát, az objektum célkontextusát, az objektumosztályt és a megtagadott konkrét engedélyt. Mind a négyet olvassa el, mielőtt elméletet alkot, mert a végrehajtásra vonatkozó elutasítás és az írásra vonatkozó elutasítás teljesen eltérő javításokat igényel.

ausearch -m AVC,USER_AVC -ts recent
ls -Z /usr/local/sbin/vpn-up.sh
ps -eZ | grep openvpn

A forráskontextusnak meg kell felelnie annak a tartománynak, amelyben a szolgáltatás valóban fut, a célkontextusnak pedig annak a fájlnak vagy könyvtárnak a címkéjének, amelyet a művelet érintett. Ha bármelyik nem illeszkedik ahhoz a hibához, amelyet követ, akkor másik eseményt olvas.

Jegyezze fel a rekord mellé a szabályzat verzióját és a futtatható fájl pontos útvonalát. Az egyik disztribúció szabályzatában szereplő tartománynév az adott telepítésre vonatkozó bizonyíték, nem garancia arra, hogy egy másik build ugyanazokat a szabályokat szállítja. Ez a kontextus teszi lehetővé, hogy valaki más a saját gazdagépén megismételje a következtetését. Enélkül a rekord anekdotaként olvasható, nem bizonyítékként.

Címke, konfiguráció vagy szabályzat: három javítás

Az első javítás egy olyan címke, amely nem egyezik a fájl telepített helyével. A cp-vel a helyére másolt vagy szerkesztővel írt szkript olyan alapértelmezett címkét hordozhat, amelyet a szolgáltatás tartománya nem használhat, és a várt kontextus visszaállítása ezt a szabályzat érintése nélkül megoldja.

A második a konfiguráció. A disztribúció kínálhat támogatott módot a művelet futtatására, dokumentált könyvtárat a segédprogramnak, vagy olyan frissített szabályzatcsomagot, amely már engedélyezi. Az elrendezését a támogatottra változtatni olcsóbb, mint szabályzatot írni, és túléli a frissítéseket.

A harmadik egy valóban hiányzó szabály, és ennek kell lennie az utolsó lehetőségnek. Hozzon létre egy jelöltet az audit eszközökkel, olvassa el, mit engedélyez valójában, szűkítse arra a műveletre és tartományra, amelyet megfigyelt, és kérjen meg valaki mást az átvizsgálására, mielőtt a termelés közelébe kerül.

Miért nem a válasz egy régi allow modul

A hiba keresési találatai tele vannak kész modulokkal, gyakran olyan eszközhöz, amelyet a hook már nem hív meg. Egy telepítése olyan engedélyeket ad, amelyeknek semmi közük nem lehet az elutasításához, és a helyén hagyja a valódi eltérést, miközben állandó lyukat ad hozzá.

Elrejti a következő hibát is. Egy széles műveletosztályt engedélyező modul eltünteti ezt a hibát, és a következőt sokkal nehezebben beszámíthatóvá teszi. A modul későbbi eltávolítása is olyan változás, amelyet senki sem akar ütemezni, ezért a rövidítés hajlamos állandóvá válni.

A fegyelmezett összehasonlítás az olvasható elutasítás és a javasolt változtatás között van. A Red Hat SELinux-hibaelhárítási útmutatója pontosan ezért helyezi a címkézési és konfigurációs ellenőrzéseket a generált szabályzat elé. Ha a rekordban nincs megfelelő elutasítás, a SELinux valószínűleg nem az Ön problémája, és az útvonal-, sandbox- vagy engedélykérdések továbbra is nyitottak.