chroot meghiúsul OpenVPN alatt: AppArmor-szabály vagy képesség?

A démon naplózza a chroot meghiúsulását, és a profil már bőkezűnek tűnik, így a csábító javítás egy útvonalszabály kiszélesítése és az újraindítás. Ez általában nem változtat semmit, mert a chroot-ot olyan jogosultság őrzi, amelyet a profil soha nem tudott átadni. Annak eldöntése, melyik réteghez nyúljunk, három ellenőrzést igényel, és ezek olcsók: mit tarthat a folyamat, mit enged a szabályzat, és mit távolított el az indító, mielőtt bármelyik számított volna.

Két külön kapu, és csak az egyik tartozik az AppArmorhoz

A chroot-nak CAP_SYS_CHROOT kell abban a felhasználói névtérben, amelyben a folyamat fut. Ez közönséges Linux-jogosultság, és a kernel ellenőrzi, mielőtt a hívás bármit tenne az útvonalakkal. Ettől függetlenül egy kényszerítő AppArmor-profil akkor is megtagadhatja a képességet, ha a folyamat rendelkezik vele, mert a kötelező szabályzatot a hitelesítő adatok mellett, nem azok helyett veszik figyelembe. A különbség a gyakorlatban számít: a két réteg külön fájlokban él, és általában különböző emberek tartják karban.

Mindkét kapu ugyanazzal az errno-val hibázik. Mindkettő EPERM-et ad, és mindkettő általános jogosultsági panasz formájában jelenik meg a démon naplójában, ezért veszteget el annyi időt a profil tartalmának találgatása. Az az útvonalszabály, amelyet éppen hozzá akart tenni, a fájlhozzáférést szabályozza a sikeres chroot után; semmi köze ahhoz, hogy a művelet egyáltalán engedélyezett-e.

Egy harmadik kapu mindkettő felett áll. Ha a szolgáltatáskezelő vagy egy burkoló a folyamatot a képesség nélkül indította el annak határhalmazában, egyetlen AppArmor-változtatás sem hozhatja vissza, és a képességek hozzáadása a profilhoz csak egy szándékot dokumentál, amelyet a kernel nem fog tiszteletben tartani.

Olvassa ki a jogosultsági állapotot, mielőtt a szabályzatot szerkeszti

A futó folyamatból induljon ki, ne abból a konfigurációból, amelyet aktívnak hisz. Az állapotfájl öt képességmaszkot és a no-new-privileges jelzőt mutatja, és ezek különböző kérdésekre válaszolnak:

grep -E '^(CapInh|CapPrm|CapEff|CapBnd|CapAmb|NoNewPrivs):' /proc/$(pidof openvpn)/status
sudo aa-status | grep -i openvpn

A CapEff az a halmaz, amely a hívás szempontjából számít: a CapBnd-ben jelen lévő, de a CapEff-ből hiányzó képességet a felső korlát engedi, és pillanatnyilag nem tartják. A CapAmb akkor számít, ha a bináris nem privilegizált a szokásos setuid értelemben, mert a környező képességek azok, amelyekkel egy szolgáltatás az exec során megtartja a jogosultságot fájlképességek nélkül. A CapInh olyan biteket tartalmaz, amelyek az exec során örökölhetők, de csak akkor, ha a végrehajtott fájl örökölhető halmaza ezt engedi, tehát egy ott lévő bit önmagában semmit nem ad.

Ezután erősítse meg, melyik profil van valóban csatolva. Egy folyamatot olyan profilnév is korlátozhat, amelyre nem számított, különösen amikor egy disztribúció a saját unit-fájlját és a profilt együtt szállítja, és a /proc/PID/attr/current olvasása ezt egy sorban eldönti. A szerkesztett fájl összevetése a kernel által jelentett profillal a különbség az ok javítása és egy senki által be nem töltött fájl szerkesztése között.

Csak akkor adja hozzá a képességszabályt, ha az auditnyom ezt mondja

A kernel- és auditrekordok megnevezik az elutasító réteget. Keressen olyan elutasítást, amely a capable műveletet és a sys_chroot nevet hordozza, együtt azzal a profillal, amely létrehozta. Ha ilyen rekord létezik, a folyamat már tartotta a képességet, és az AppArmor tagadta meg, a célzott változtatás pedig egy képességszabály a valódi profilon belül:

capability sys_chroot,

Tartsa töredékként abban a profilban, amely valóban csatolva van, és ellenőrizze a kulcsszót az apparmor.d profilreferencia alapján, ahelyett hogy egy kapcsolódó oktatásból másolna szabályt. Megosztott include-be téve minden korlátozott program megkapja, amely behúzza azt a fájlt, a profilok panaszmódba állítása pedig elrejti a következő elutasítást ahelyett, hogy ezt megoldaná. A profilszabály megszüntet egy szabályzati elutasítást; nem teremt jogosultságot, tehát egy folyamat, amelynek hatékony halmazában soha nem volt CAP_SYS_CHROOT, a szabály ellenére is meghiúsul.

Ha az auditrekord egyáltalán nem mutat AppArmor-elutasítást, hagyja abba a profil szerkesztését. Hitelesítő adatok problémájával áll szemben, és a hátralévő munka az unit-fájlban vagy a szülőfolyamatban van, nem a szabályzat nyelvében.

A szolgáltatáskezelő saját felső korlátot tart

A systemd minden szolgáltatáshoz képesség-határhalmazt állít be, és ez alapértelmezés szerint szűk. Ami ott kizárásra kerül, az a folyamat számára elérhetetlen, bármit mond a profil, ezért a megszigorított unitegységek olyan műveletnél is elbukhatnak, amely kézi indításnál működött. A vonatkozó direktívák könnyen olvashatók az unitban, és könnyen figyelmen kívül maradnak, amikor az alkalmazás jelenti a hibát. A disztribúciós csomag által szállított drop-in fájlok a szokásos forrása egy olyan felső korlátnak, amelynek beállítására senki sem emlékszik.

A felső korlát emelése és a képesség megadása két változtatás, nem egy. A határhalmaz bejegyzése azt mondja, hogy a folyamat tarthatja a képességet; nem adja hozzá a hatékony halmazhoz, és a NoNewPrivs megakadályozhatja egy későbbi emelés sikerét akkor is, ha minden más egyezik. Csak azt adja hozzá, amire a műveletnek szüksége van, tartsa érintetlenül a többi megszigorítást, és álljon ellen a rövidítésnek, hogy minden képességet megadjon egyetlen hívás átengedéséért.

A sorrend itt is számít. Először az unit felső korlátját módosítsa, ellenőrizze, hogy a CapEff most tartalmazza a bitet, és csak utána döntse el, hogy az AppArmor még mindig elutasít-e. Ha mindkét változtatást egyszerre végzi el, tartós hiba esetén ismét találgatni fog.

Miután az elutasítás megszűnt, ellenőrizze magát a börtönt

A sikeres chroot elmozdítja a gyökeret, így minden útvonal, amelyet a démon utána érint, az új fán belül oldódik fel. A hiányzó konfiguráció, egy hiányzó eszközcsomópont vagy egy be nem másolt tanúsítványkönyvtár most fájlhibaként jelenik meg, és ez a hiba elrendezési probléma, nem képességprobléma. Olvassa a következő eseményt ahelyett, hogy még egy széles engedélyt adna hozzá. Az elmozdítás azt is megváltoztatja, mit jelent egy relatív útvonal, ezért a megszigorítási útmutatók abszolút útvonalakat követelnek a démon konfigurációjában.

Az is segít, ha emlékszünk arra, mit nem tesz a chroot. Ez útvonalhatár, nem homokozó: az a folyamat, amely megtartja a jogosultságot, ki tud szökni belőle, ezért a képességet általában a hívás után ejtik, és ezért kell a korlátozásnak a démon körül megmaradnia. Az AppArmor-profil, a képesség-határhalmaz és a fájlrendszer-korlátozások együttes megtartása a gyakorlat lényege, nem pedig egy maradék, amelyet a szolgáltatás indulásakor el kell távolítani.

A döntési szabály rövid. Ha az auditrekord az AppArmort nevezi meg, adjon egy képességszabályt a csatolt profilhoz. Ha a hatékony halmaz üres, javítsa az unit felső korlátját és a jogosultságejtés sorrendjét. Ha a profil nem az, amelyet szerkesztett, hagyja abba a szerkesztést, és találja meg az igazit.