Android chroot VPN: prečo tunel funguje a aplikácie ho ignorujú
Chroot mení iba vyhľadávanie ciest, nie jadro, sieťový menný priestor ani registráciu VPN v Androide. Z toho vyplývajú dva výsledky a oba ľudí prekvapia.
Spustíte na telefóne distribúciu Linuxu pod chroot, nainštalujete do nej VPN klienta a shell ohlási, že tunel je hotový. Potom prepnete do prehliadača a prevádzka odchádza cez mobilné dáta, akoby sa nič nestalo. Alebo naopak: každá aplikácia v telefóne stratí pripojenie, pretože klient pridal predvolenú trasu v mennom priestore, ktorý Android skutočne používa. Oba príznaky pochádzajú z toho istého chýbajúceho dielu a ani jeden nie je chyba VPN klienta.
Shell hlási pripojené, aplikácie nesúhlasia
Prvý výsledok je bežný. Tunel v používateľskom priestore otvorený z chroot môže dokončiť handshake, vypísať štatistiky a prenášať prevádzku, ktorú vytvára ten istý shell, zatiaľ čo aplikácie Androidu ďalej používajú predvolenú sieť telefónu. Nič ich nezachytáva, pretože nič nepovedalo Androidu, že VPN existuje.
Druhý výsledok je nebezpečný. Ak chroot zdieľa sieťový menný priestor Androidu, čo robí predvolene, proces s dostatočnými právami môže pridať trasy a rozhranie TUN, ktoré ovplyvnia celý telefón. Potom tunel funguje pre každú aplikáciu, vrátane tých, ktoré ste nechceli smerovať, a pripojenie telefónu teraz závisí od démona bez správy životného cyklu, bez indikátora pripojenia a bez politiky vždy zapnuté.
Ktorý z dvoch prípadov máte, sa dá zistiť jedným príkazom. Porovnajte ip route vnútri chroot s tým istým príkazom z Android shellu zvonku. Rovnaký výstup znamená, že chroot je v mennom priestore hostiteľa: každá sieťová zmena, ktorú urobí, platí pre celý telefón. Odlišný výstup znamená, že spúšťač preň vytvoril menný priestor, a jeho tunel je pre Android neviditeľný už z podstaty.
Čo chroot zmenil a čo nie
| Object | Effect of a chroot |
|---|---|
| Pathname resolution | Changed: lookups start at the new root |
| Kernel and drivers | Unchanged: the phone's kernel, its TUN driver, its limits |
| Network namespace | Unchanged unless the launcher creates one |
| Android VPN registration | Unchanged: no app consented, no VPN is selected |
Systémové volanie chroot robí jednu vec: mení adresár používaný na rozlíšenie názvov ciest. Manuálová stránka výslovne hovorí, že to nie je bezpečnostná hranica, a nehovorí nič o rozhraniach, trasách ani stave VPN. Všetko, čo ľudia od kontajnera Linuxu očakávajú — súkromný sieťový zásobník, filtrovaný súborový systém, limity zdrojov — pochádza z iných mechanizmov, ktoré spúšťač mohol alebo nemusel použiť.
Preto tvrdenia, že chroot izoluje VPN, zvyčajne odpovedajú na nesprávnu otázku. Relevantná otázka je, v akom mennom priestore proces beží a do akej domény SELinux je obmedzený, a obe sú vlastnosti spôsobu spustenia, nie slova chroot.
TUN potrebuje tri veci a uzol zariadenia je iba jedna
Tradičný tunel v používateľskom priestore potrebuje zariadenie TUN, ktoré môže otvoriť, podporu jadra pre toto zariadenie a povolenie konfigurovať rozhranie a trasy. To sú oddelené požiadavky a vytvorenie názvu cesty pod /dev samo o sebe nesplní ani jednu z nich:
ls -l /dev/net/tun
ip tuntap add dev tun0 mode tunV Androide má jadro zvyčajne vkompilovanú podporu TUN, pretože ju používa vlastná VPN služba platformy, ale to neznamená, že váš proces ju môže používať. Konfigurácia rozhrania vyžaduje schopnosť správy siete a SELinux rozhoduje, či sa proces vôbec dostane k uzlu zariadenia. Odmietnutie vyzerá ako chyba oprávnenia bez zjavnej príčiny a odpoveď je v auditnom zázname:
dmesg | grep avc
logcat -d | grep "avc: denied"Root to nerieši. SELinux obmedzuje procesy bežiace ako uid 0 presne tak ako ostatné, takže chroot spustený z root shellu môže byť stále odmietnutý pri zariadení, ktoré vidí. Vypnutie vynucovania, aby fungoval starý inštalátor, je rozhodnutie pre celý telefón s dôsledkami ďaleko za tunelom a nie je opravou zastaraného binárneho súboru.
Prečo aplikácie Androidu ignorujú váš tunel
Podporovaný model Androidu je VPN aplikácia, ktorá sa zaregistruje cez VPN službu platformy, raz požiada používateľa o súhlas a dostane deskriptor súboru pre svoj tunel. Platforma potom smeruje prevádzku do tohto deskriptora a vynucuje rozsah aplikácií, ktorý zvolil používateľ alebo správca, a preto ten istý mechanizmus môže byť pre každú aplikáciu, pre každý profil a kombinovaný s nastaveniami vždy zapnuté a blokovania bez VPN. Sprievodca vývojom VPN pre Android opisuje tento handshake a kľúčové je, že ide o registráciu, nie o trik so smerovaním.
Démon vnútri chroot sa nikdy nezaregistruje. Neexistuje dialóg súhlasu, neexistuje ikona kľúča v stavovom riadku, neexistuje zoznam zahrnutia alebo vylúčenia pre aplikácie a žiadna účasť na politike vždy zapnuté. Aplikácie preto ďalej používajú predvolenú sieť a tunel prenáša iba to, čo posiela samotný shell.
Ani cesta opačným smerom nepomáha. Tlačenie trás do menného priestoru hostiteľa zachytí všetko, vrátane prevádzky, ktorú platforma očakávala ponechať lokálne, a robí to bez kontroly pre každú aplikáciu a bez možnosti používateľa vidieť to alebo odvolať. Neexistuje stredné nastavenie, kde démon chroot smeruje prevádzku iba jednej aplikácie.
Binárna kompatibilita je samostatná stena
Aj keď je sieťová stránka zaujímavá, spustiteľný súbor má vlastné požiadavky: architektúru CPU, dynamický zavádzač, knižnicu C a možnosti jadra, ktoré očakáva. Android používa bionic namiesto glibc a starý binárny súbor zostavený pre desktopovú distribúciu môže potrebovať knižnice, ktoré už v zariadení nie sú.
Symbolické prepojenie názvu knižnice na novšiu verziu nevytvára kompatibilitu ABI a archivovaná kryptografická knižnica z balíka starého desaťročie nie je udržiavaná komponenta. Ak plán na tom závisí, plán je spúšťať neudržiavaný kód so sieťovými právami v telefóne.
Dokážte to v kontexte Androidu a potom upracte
Testujte to, čo vám skutočne záleží, z tej strany, ktorá má význam: otvorte konkrétnu aplikáciu, dosiahnite konkrétny súkromný cieľ, overte, ktorý resolver odpovedal, potom odpojte tunel a overte dokumentované správanie. Výsledok z terminálu vnútri chroot je dôkaz iba o kontexte vykonávania tohto terminálu a nič viac.
Ak ste počas experimentov menili trasy hostiteľa, vráťte ich a zapíšte, čo ste zmenili. Potom skontrolujte, či má telefón nakonfigurovanú VPN vždy zapnuté, pretože starší experiment, ktorý zanechal pravidlo, môže o mesiace vyzerať ako porucha platformy.
Pre skutočnú potrebu vzdialeného prístupu použite podporovaného klienta služby alebo schválený návrh brány. Otázka, ktorú stojí za to položiť, nie je, či sa dá rozbehnúť inštalátor s rootom, ale či podporovaná implementácia prenesie potrebné aplikácie cez zamýšľanú hranicu bez toho, aby v zariadení zanechala privilegované zmeny bez vlastníka.