A jogosultságok csökkentése után: mely OpenVPN-fájlok működnek még?

A hosszú futásidő csak azt bizonyítja, hogy az indítás sikerült azokkal a jogosultságokkal, amelyekkel a daemon abban a pillanatban rendelkezett. Az itt számító hibák később jönnek: új kliens csatlakozik, visszavonási lista cserélődik, egy segédparancsfájlnak fájlt kell írnia. Mindegyik új megnyitás, amelyet a jogosultság nélküli fiók végez, saját engedélykérdéssel és saját hibaüzenettel. Három döntés választja el a tovább működő beállítást attól, amely a következő eseménynél elbukik.

Válassza külön a korán betöltöttet a később megnyitottól

A leíró egy nyitott fájlleírás fogantyúja, és a hozzáférési mód a leírás létrehozásakor rögzült. A folyamat felhasználójának későbbi módosítása nem zárja be a fogantyút, ezért a rootként olvasott kulcsfájl a csökkentés után is működik. A mód sem változik: a olvasásra nyitott fogantyú nem lesz írható, és az írható fogantyú nem vonódik vissza csak azért, mert a fiók elvesztette az útvonalra vonatkozó jogait. Ez a két tény magyarázza e jelentések meglepő viselkedésének nagy részét.

A másik fele a memória. A daemon feldolgozhat egy tanúsítványt, megtarthatja a feldolgozott anyagot és bezárhatja a fájlt; használatban adat marad, nem nyitott fájl. Ezért a folyamatos forgalom nem bizonyítja sem azt, hogy egy leíró nyitva van, sem azt, hogy az útvonalnév elérhető. Csak azt bizonyítja, hogy a jelenlegi munkamenethez szükséges anyag korábban beszerződött.

A későbbi megnyitás más tranzakció. A jelenlegi hitelesítő adatokkal, a jelenlegi biztonsági környezettel és a jelenlegi csatolási nézettel fut, ezért egy indításkor olvasható útvonal a következő kapcsolatnál elutasítható. A rotáció csapdát is hoz: ha új fájlt írunk ugyanarra az útvonalnévre, a meglévő leíró a régi objektumnál marad, ezért az újratöltés sikeresnek tűnhet, miközben a daemon még az előző tartalmat használja. Hasonlítsa össze a folyamat által tartott inode-ot a lemezen lévővel, mielőtt elhiszi, hogy a rotáció életbe lépett.

Nevezze meg a három futásidejű olvasást és mindegyik időpontját

Három erőforrás rendszerint jóval az inicializálás után nyílik meg, és különböző pillanatokban hibázik. Egy adott kliens konfigurációs fájlját akkor olvassuk, amikor az a kliens csatlakozik, ezért elromolhat egy felhasználónál, miközben a többi folytatja. A visszavonási adatokat a partner hitelesítése során és a fájl cseréjekor is megnézik. Egy ideiglenes könyvtárat csak akkor érintünk, amikor egy parancsfájl vagy bővítmény ír valamit.

Egyik sem tartozik az indítási útvonalhoz, ezért egy hetekig egészséges kiszolgáló a következő kapcsolatnál elbukhat. A kategória a javítás gazdáját is megnevezi: az első kettő a konfiguráció olvasási joga a daemon fiókja alatt, a harmadik pedig egy szűk célú írható hely.

persist-key szűkebb kérdésre válaszol, mint sokan feltételezik. Nyitva tartja a kulcsfájlt a dokumentált SIGUSR1 és ping-restart újraindítások alatt, és semmit nem tesz a CCD-fájlokért, a visszavonási adatokért, a segédprogramokért vagy a folyamat teljes újraindításáért. Ezek továbbra is a saját megnyitási útvonalaikat követik, éppen akkor futó fiók alatt.

Erősítse meg a fiókot és a tényleges nézetet

Kérdezze meg a futó daemont, melyik fiókot használja, ahelyett hogy a unit-fájlban bízna, majd hasonlítsa össze a választ azzal, amit a unit beállít. Az eltérés az első megoldandó dolog, mert minden későbbi engedélyellenőrzés azként fut, aki a folyamat valójában. Utána járja végig az útvonalat összetevőnként; az átjárhatóságot minden szinten értékelik, ezért egy nem átjárható könyvtárban lévő olvasható fájl olvashatatlan marad. A végső fájlmód az utolsó kérdés, nem az első.

A névterek és a szolgáltatási homokozók olyan határokat adnak, amelyeket a tulajdonjog és a módbit nem ír le. A héjában látható útvonal hiányozhat vagy csak olvasható lehet egy chrootban, csatolási névtérben vagy az otthoni könyvtárakat elrejtő unitban. A biztonsági modulok még egy réteget adnak, ezért egy olvashatónak tűnő fájl megnyitáskor mégis elutasítható.

ps -o user:12,pid,args -C openvpn
systemctl show -p User -p Group -p ProtectHome -p RootDirectory [email protected]
sudo -u openvpn namei -l /etc/openvpn/ccd/alice

Az adminisztrátor héjában végzett sikeres olvasás ezek közül egyetlen összetett feltételt sem vizsgál. Futtassa az ellenőrzést a daemon fiókjaként, ugyanazzal a névtérrel és homokozóval, vagy fogadja el, hogy az eredmény a héját írja le, nem a kiszolgálót. A harmadik parancs ennek a tesztnek az olcsó változata: kiírja minden összetevő módját, és az első olyannál hibázik, amelyen a daemon fiókja nem tud átjutni.

Adjon a futásidejű írásnak saját könyvtárat

Az olvasás a leltárnak csak a fele. Egy segédparancsfájlnak állapotfájlt kell létrehoznia, egy bővítménynek az állapotot a konfigurációja mellé kell írnia, és ezeket az írásokat nem fedi le az, hogy a konfigurációs fát írhatóvá tesszük. Adja meg a konkrét könyvtárnak a funkciója által igényelt írási engedélyt, olyan tulajdonossal és móddal, amelyet meg tud magyarázni. Mindenhez, ami csak olvasásra kerül, részesítse előnyben a csak olvasási hozzáférést.

Tartsa a titkos kulcs engedélyeit külön a szabályzatfájloktól. Az újraindítás után újraolvasandó kulcs követelménye más, mint a minden kapcsolatnál olvasott kliensfájlé, és egyetlen megengedő mód mindkettőre több hozzáférést ad, mint amit a probléma kér. A szűk tulajdonjogú, dedikált daemonfiók könnyebben auditálható, mint egy széles csoport. Amikor a kulcsnak túl kell élnie az újraindításokat, persist-key eltávolítja az újraolvasást a könyvtár szélesítése helyett.

A reprodukálható esemény alapján döntsön

Egy élő alagút egyetlen utat bizonyít a kódban. Az az esemény, amelynek a fájl kell, az egyetlen teszt, amely lefedi az önt érdeklő megnyitást, legyen az új klienskapcsolat, lecserélt visszavonási fájl, engedélyezett lágy újraindítás vagy tervezett újraindítás. Válassza ki az eseményt, futtassa, és az első hibát tartsa meg, ne az utolsót.

Lágy újraindításnál egy jelzés és a unit naplója megmutatja, újraolvasták-e a kulcsot. Küldje el a jelzést, majd olvassa el az unit által írt utolsó sorokat:

systemctl kill -s SIGUSR1 [email protected]
journalctl -u [email protected] -n 40 --no-pager

Ne következtessen arra, hogy egy kompromittált daemon már nem tud fájlokat módosítani, csak mert a jogosultságokat csökkentették. Hogy még mit tud, a megmaradt hitelesítő adataitól, képességeitől, az írható könyvtáraitól és minden még birtokolt írható leírótól függ. A jogosultságcsökkentés szűkíti a felhatalmazást, és a futásidejű megnyitások leltára mutatja meg, mennyire. Írja ezt a határt a konfiguráció mellé, hogy a következő embernek ne kelljen újra felfedeznie.