Máte zrušit chroot, nebo zkopírovat iproute2 do vězení?

Služba nastartuje, klient se přidruží a na straně serveru se nikdy neobjeví trasa. Nebo daemon odmítne nastartovat a uvede příkaz, který nemohl provést. Oba výsledky sledují stejné tři řádky, které se obvykle kopírují společně z průvodce zpevněním: přechod na neprivilegovaný účet, opuštění skupiny a změna kořene souborového systému. Jen jeden ze tří skrývá soubory a jen jeden z nich odebírá oprávnění měnit směrovací tabulku. Jejich rozdělení je způsob, jak zjistíte, který řádek vlastně chcete.

Co vězení odebírá a daemon to stále potřebuje

Změna kořene probíhá po startu, takže daemon si ponechá vše, co už otevřel, a ztratí vše, co by otevřel později. Jakýkoli pomocník, který spojení spustí po tomto okamžiku, musí existovat uvnitř nového kořene, spolu se sdílenými knihovnami, které načítá. Vězení postavené z konfiguračního souboru a certifikátu nemá ani jedno.

Přechod na neprivilegovaný účet je samostatné omezení. Proces, který se vzdal rootu, možná nedokáže měnit trasy ani zvednout rozhraní, i když je binárka přímo tam, takže obě selhání je třeba diagnostikovat odděleně.

Tři podmínky rozhodují, jakou opravu potřebujete

První podmínkou je, jak váš build instaluje trasy. Novější OpenVPN vydání konfigurují rozhraní a směrovací tabulku v procesu, zatímco starší balíčky a vlastní nastavení spoléhají na externí nástroje nebo na skripty up a down. Pokud log uvádí příkaz, je ve hře externí nástroj a vězení ho skrývá. Pokud log místo toho ukazuje chybu oprávnění, problémem je účet.

Druhou je údržba. Vězení se zkopírovanými binárkami je třeba obnovovat při každé aktualizaci balíčku, který je poskytuje, jinak první aktualizace zanechá za sebou rozbitý tunel. Třetí je, zda konkrétní kontrola skutečně vyžaduje chroot; pokud jde požadavek ve skutečnosti o oddělení oprávnění, může samotná změna účtu stačit.

Co musí funkční vězení obsahovat

Vězení, které spouští příkazy, potřebuje binárku, každou knihovnu, proti které se linkuje, a každý uzel zařízení, který daemon otevírá pozdě. Zkopírujte části a otestujte je bez VPN ve hře:

ldd /usr/sbin/ip
chroot /etc/openvpn/jail /sbin/ip route show
chroot /etc/openvpn/jail /sbin/ip link set tun0 up

První příkaz vypisuje závislosti a je to ten, který lidé přeskakují. Zkopírovaná binárka, která nenajde knihovnu, selže jinou zprávou než chybějící binárka, a obojí vypadá jako závada OpenVPN při čtení z klientské strany. Ruční spuštění příkazu ve vězení zopakuje selhání bez restartu služby.

Zkopírujte do vězení i konfiguraci, certifikáty a případný CRL, protože soubor, který daemon chce po startu znovu přečíst, nebude nalezen, jakmile se kořen změní. Zapište si, co jste zkopírovali, protože další aktualizace síťového balíčku nahradí originály a ponechá vězení na staré kopii.

Místo toho zmenšete zpevnění

Pokud vězení existuje jen proto, že to říkal průvodce, odstranění onoho jediného řádku při zachování omezení účtu je obhajitelný výsledek. Daemon si ponechá pohled na souborový systém a zbaví se problému a snížení oprávnění stále odebírá root dlouhověkému procesu.

Zapište, co zůstává, a proč. Konfigurace, která tiše ztratila kontrolu bez poznámky, je způsob, jakým zpevnění driftuje, a příští audit se zeptá, proč řádek zmizel.

Rozdělte tři řádky, než se rozhodnete

Zkopírujte konfiguraci, zakažte všechny tři direktivy a potvrďte, že se klient připojí a objeví se očekávané trasy. Potom znovu povolte jen řádky účtu a nakonec samotný chroot. Krok, kde se tunel zlomí, určuje hranici, a vyhnete se přestavbě vězení, které nikdy nebylo příčinou.

Když znovu směruje, spusťte jedno klientské sezení s vyšší podrobností a přečtěte řádek, který uvádí příkaz nebo oprávnění, které selhalo. Ten řádek má větší cenu než časový limit, který klient nakonec hlásí.