Běžná linuxová aplikace používá VPN, aniž by se dotkla TUN

Prohlížeč, který používá již navázanou VPN v Linuxu, neotevírá /dev/net/tun. Otevře socket a jádro rozhodne, kterým rozhraním pakety tohoto socketu odcházejí. Proces, který tunel vytvořil, dělá jinou práci než proces, jehož provoz přenáší. Oddržení těchto dvou rolí odpovídá na většinu otázek o oprávněních dřív, než se položí.

Sledujte jeden paket od socketu k tunelu

Běžná aplikace zavolá connect nebo send a jádro vyhledá trasu k cíli. Pokud zvolená trasa ukazuje na rozhraní tunelu, paket se zařadí do fronty zařízení, které démon VPN čte. Démon ho zašifruje a odešle fyzickým rozhraním. Každá šipka v tomto popisu je místo, kde lze odpovědět na otázku o oprávněních.

Nic na této cestě nevyžaduje, aby aplikace o zařízení věděla. Démon drží popisovač souboru a provádí operace s rozhraním, zatímco aplikace vidí jen běžné síťové API.

Nakreslete obě poloviny jednou a otázky o oprávněních se snáze zařadí. Horní polovina je svět aplikací a spodní patří démonovi.

Určete, kdo zařízení potřebuje a kdo ne

Vytvoření rozhraní TUN nebo připojení k němu vyžaduje přístup k zařízení a navíc oprávnění ho nakonfigurovat, proto podporovaná služba VPN začíná s pravomocí správy sítě nebo používá privilegovaného pomocníka. Tento požadavek patří démonovi. Nic neříká o prohlížeči, klientu databáze ani nástroji pro přenos souborů. Služba, která oprávnění potřebuje, ho potřebuje pro svůj vlastní krok nastavení, ne pro své klienty.

Jakmile jsou trasa a zásada na místě, běžný proces použije výslednou cestu svými obvyklými voláními socketu. Nepotřebuje uzel zařízení a nepotřebuje root.

Změna oprávnění zařízení není způsob, jak dát aplikaci přístup k cíli. Jen přesouvá hranici zařízení jinam.

Ověřte, ve kterém jmenném prostoru aplikace skutečně běží

Kontejner nebo druhý síťový jmenný prostor dává svým procesům samostatnou sadu rozhraní a tabulku tras. Tunel na hostiteli se tam automaticky neobjeví a žádná změna oprávnění zařízení to nezmění. Aplikace prostě povede provoz tím, co tento prostor poskytuje. Proto kontejnerový obraz nemůže omylem zdědit tunel hostitele.

Ověřte to pomocí ip netns list a ip -n NAME route nebo prozkoumáním odkazu jmenného prostoru procesu. Odpověď je obvykle vidět v jednom příkazu.

Dvěma uživatelům na stejném hostiteli lze zásadou přidělit i různé cesty. To je síťové rozhodnutí, ne důkaz o vlastnictví zařízení.

Oddělte oprávnění od síťové zásady

Některé nástroje potřebují víc než socket. Zachytávání paketů potřebuje surový socket a změna tras vyžaduje správcovskou pravomoc. Jsou to samostatné operace se samostatnými uděleními a udělení jedné se nemá číst jako plošný požadavek pro používání VPN.

Program, který si implementuje vlastní tunel, je třetí případ. Opravdu otevírá TUN, protože přebírá roli démona, a proto potřebuje démonova oprávnění.

Pojmenujte operaci dřív, než pojmenujete oprávnění. Obvykle je snazší je oddělit, než se zdá.

Ověřte rozdělení dvěma účty

Připojte tunel jako služba, potom spusťte aplikaci jako běžný uživatel a potvrďte, že dosáhne na soukromý prostředek. Ověřte ip route get pro cíl z shellu tohoto uživatele a podívejte se, které rozhraní bylo zvoleno. Pokud je trasa správná a spojení přesto selhává, problém je v zásadě, ne v oprávnění.

Výsledný návrh je nejmenší oprávnění s jasnou hranicí: jedna komponenta vlastní nastavení a prostředky tunelu, úlohy si drží své běžné účty a síťová zásada rozhoduje, co smí projít. Spouštění všeho jako root tyto role slévá, aniž by cokoli vysvětlilo.