Po snížení oprávnění: které soubory OpenVPN ještě fungují?

Dlouhý běh dokazuje jen to, že start uspěl s oprávněními, která démon měl v tu chvíli. Selhání, na kterých zde záleží, přicházejí později: připojí se nový klient, vymění se seznam odvolání, pomocný skript musí zapsat soubor. Každé z nich je nové otevření provedené neprivilegovaným účtem, s vlastní otázkou oprávnění a vlastní chybovou zprávou. Tři rozhodnutí oddělují konfiguraci, která funguje dál, od té, která selže při další události.

Oddělte to, co se načetlo brzy, od toho, co se otevírá později

Deskriptor je úchyt na otevřený popis souboru a režim přístupu byl pevně dán při vytvoření tohoto popisu. Změna uživatele procesu později úchyt nezavře, proto klíčový soubor přečtený jako root funguje i po snížení. Ani režim se nemění: úchyt otevřený pro čtení se nestane zapisovatelným a zapisovatelný úchyt se neodebere jen proto, že účet ztratil práva k cestě. Tyto dvě skutečnosti vysvětlují většinu překvapivého chování v těchto zprávách.

Druhá polovina je paměť. Démon může certifikát rozparsovat, rozparsovaný materiál podržet a soubor zavřít; v použití zůstávají data, ne otevřený soubor. Proto trvající provoz nedokazuje ani že je deskriptor otevřený, ani že je cesta dosažitelná. Dokazuje jen, že materiál potřebný pro aktuální relaci byl získán dříve.

Pozdější otevření je jiná transakce. Běží pod aktuálními pověřeními, aktuálním bezpečnostním kontextem a aktuálním pohledem na připojení, takže cesta čitelná při startu může být při dalším připojení odmítnuta. Rotace přidává past: zápis nového souboru přes stejný název cesty nechá existující deskriptor připojený ke starému objektu, takže opětovné načtení může vypadat úspěšně, zatímco démon stále používá předchozí obsah. Porovnejte inode, který proces drží, s tím na disku, než rotaci uvěříte.

Pojmenujte tři běhová čtení a kdy se každé spouští

Tři zdroje se obvykle otevírají dlouho po inicializaci a selhávají v různých okamžicích. Konfigurační soubor konkrétního klienta se čte, když se tento klient připojí, takže se může rozbít pro jednoho uživatele, zatímco ostatní pokračují. Data odvolání se kontrolují při autentizaci protějšku a znovu při výměně souboru. Dočasný adresář se dotkne jen tehdy, když skript nebo plugin něco zapíše.

Žádný ze tří nepatří do startovní cesty, proto server zdravý týdny může selhat při dalším připojení. Kategorie také pojmenovává vlastníka opravy: první dva jsou práva čtení konfigurace pod účtem démona, třetí je zapisovatelné místo s úzkým účelem.

persist-key odpovídá na užší otázku, než většina lidí předpokládá. Udržuje klíčový soubor otevřený přes dokumentované resety SIGUSR1 a ping-restart, a nic nedělá pro soubory CCD, data odvolání, pomocné spustitelné soubory ani úplný restart procesu. Ty stále jdou svými cestami otevření, pod účtem, který právě běží.

Potvrďte účet a pohled, který skutečně má

Zeptejte se běžícího démona, který účet používá, místo abyste věřili unit souboru, a pak odpověď porovnejte s tím, co unit nastavuje. Nesoulad je první věc k řešení, protože každá další kontrola oprávnění běží jako ten, kým proces skutečně je. Potom projděte cestu komponentu po komponentě; průchod se vyhodnocuje na každé úrovni, takže čitelný soubor v neprocházeném adresáři zůstává nečitelný. Konečný režim souboru je poslední otázka, ne první.

Jmenné prostory a servisní sandboxy přidávají hranice, které vlastnictví a bity režimu nepopisují. Cesta viditelná ve vašem shellu může uvnitř chroot, jmenného prostoru připojení nebo unitu skrývajícího domovské adresáře chybět nebo být jen pro čtení. Bezpečnostní moduly přidávají další vrstvu, takže soubor, který vypadá čitelně, může být při otevření přesto odmítnut.

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

Úspěšné čtení v shellu správce neprotestuje žádnou z těchto kombinovaných podmínek. Spusťte kontrolu pod účtem démona, se stejným jmenným prostorem a sandboxem, nebo přijměte, že výsledek popisuje váš shell, nikoli server. Třetí příkaz je levná verze tohoto testu: vypíše režim každé komponenty a selže na první, kterou účet démona nedokáže projít.

Dejte běhovému zápisu vlastní adresář

Čtení je jen polovina inventáře. Pomocný skript může potřebovat vytvořit stavový soubor, plugin může potřebovat zapsat stav vedle své konfigurace, a tyto zápisy nejsou pokryty tím, že se strom konfigurace stane zapisovatelným. Dejte konkrétnímu adresáři oprávnění zápisu, které jeho funkce potřebuje, s vlastníkem a režimem, které umíte vysvětlit. Pro vše, co se jen čte, preferujte přístup pouze pro čtení.

Držte oprávnění soukromého klíče odděleně od souborů zásad. Klíč, který se musí po resetu znovu přečíst, má jiný požadavek než klientský soubor čtený při každém připojení, a jeden benevolentní režim pro oba dává více přístupu, než problém žádá. Vyhrazený účet démona s úzkým vlastnictvím se audituje snáze než široká skupina. Když má klíč přežít resety, persist-key odstraní opakované čtení místo rozšíření adresáře.

Rozhodujte podle události, kterou umíte zopakovat

Živý tunel dokazuje jednu cestu kódem. Událost, která soubor potřebuje, je jediný test, který pokrývá otevření, na kterém vám záleží, ať už je to nové klientské připojení, vyměněný soubor odvolání, povolený měkký reset nebo plánovaný restart. Vyberte událost, spusťte ji a podržte první chybu, ne poslední.

U měkkého resetu jeden signál a log unitu ukážou, zda byl klíč přečten znovu. Pošlete signál a pak přečtěte poslední řádky, které unit zapsal:

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

Nevyvozujte, že kompromitovaný démon už nemůže měnit soubory jen proto, že byla oprávnění snížena. Co ještě dokáže, závisí na zbývajících pověřeních, jeho schopnostech, adresářích, do kterých může psát, a každém dosud drženém zapisovatelném deskriptoru. Snížení oprávnění zužuje pravomoc a inventář běhových otevření ukazuje, jak daleko. Napište tuto hranici vedle konfigurace, aby ji příští člověk nemusel znovu objevovat.