VPN chrooti all Androidis: miks tunnel töötab ja rakendused seda eiravad

Paigaldad telefoni chrooti alla Linuxi distributsiooni, paned sinna VPN-kliendi ja shell teatab, et tunnel on valmis. Siis lähed brauserisse ja liiklus väljub mobiilse andmeside kaudu, nagu poleks midagi juhtunud. Või vastupidi: kõik rakendused kaotavad ühenduse, sest klient lisas vaikimisi marsruudi nimeruumi, mida Android tegelikult kasutab. Mõlemad sümptomid tulevad samast puuduvast tükist ja kumbki pole VPN-kliendi viga.

Shell ütleb ühendatud, rakendused ei nõustu

Esimene tulemus on tavaline. chrootist avatud kasutajaruumi tunnel võib oma käepigistuse lõpetada, statistika välja printida ja kanda liiklust, mille loob sama shell, samal ajal kui Androidi rakendused kasutavad edasi telefoni vaikevõrku. Miski ei püüa neid kinni, sest miski ei öelnud Androidile, et VPN on olemas.

Teine tulemus on ohtlik. Kui chroot jagab Androidi võrgu nimeruumi, mida ta vaikimisi teeb, saab piisavate õigustega protsess lisada marsruute ja TUN-liidese, mis mõjutavad kogu telefoni. Siis töötab tunnel iga rakenduse jaoks, ka nende jaoks, mida sa ei kavatsenud suunata, ja telefoni ühenduvus sõltub nüüd deemonist, kellel pole elutsükli haldust, ühenduse indikaatorit ega alati-sees poliitikat.

Kumma kahest said, saab vastata ühe käsuga. Võrdle ip route chrooti sees sama käsuga Androidi shellist väljaspool. Identne väljund tähendab, et chroot on hosti nimeruumis: iga võrgumuudatus kehtib kogu telefonile. Erinev väljund tähendab, et käivitaja lõi selle jaoks nimeruumi ja selle tunnel on Androidile konstruktsiooni järgi nähtamatu.

Mida chroot muutis ja mida mitte

Süsteemikõne chroot teeb ühte: muudab kataloogi, mida kasutatakse teede tõlgendamiseks. Man-leht ütleb selgesõnaliselt, et see pole turvapiir, ja ei ütle midagi liideste, marsruutide ega VPN-i oleku kohta. Kõik, mida inimesed Linuxi konteinerilt ootavad — privaatne võrgupinu, filtreeritud failisüsteem, ressursipiirid — tuleb teistest mehhanismidest, mida käivitaja võis või ei pruukinud kasutada.

Seepärast vastavad väited, et chroot isoleerib VPN-i, tavaliselt vale küsimusele. Oluline küsimus on, millises nimeruumis protsess töötab ja millisesse SELinuxi domeeni see on piiratud, ning mõlemad on selle omadused, kuidas see käivitati, mitte sõna chroot omadused.

TUN vajab kolme asja ja seadme sõlm on neist ainult üks

Traditsiooniline kasutajaruumi tunnel vajab TUN-seadet, mille ta saab avada, tuuma tuge sellele seadmele ja õigust liidest ning marsruute seadistada. Need on eraldi nõuded ja raja nime loomine /dev all ei täida ühtegi neist iseenesest:

ls -l /dev/net/tun
ip tuntap add dev tun0 mode tun

Androidis on TUN-i tugi tavaliselt tuuma sisse kompileeritud, sest platvormi enda VPN-teenus kasutab seda, kuid see ei tähenda, et sinu protsess tohib seda kasutada. Liidese seadistamine nõuab võrgu administreerimise võimet ja SELinux otsustab, kas protsess pääseb seadme sõlmele üldse ligi. Keeldumine näeb välja nagu õiguste viga ilma ilmse põhjuseta ja vastus on auditijäljes:

dmesg | grep avc
logcat -d | grep "avc: denied"

Root ei lahenda seda. SELinux piirab uid 0 all töötavaid protsesse samamoodi nagu teisi, seega root-shellist käivitatud chroot võib ikkagi saada keeldumise seadmele, mida ta näeb. Jõustamise väljalülitamine, et vana paigaldaja töötaks, on kogu telefoni otsus tagajärgedega tunnelist palju kaugemale ja see pole aegunud binaarfaili parandus.

Miks Androidi rakendused sinu tunnelit eiravad

Androidi toetatud mudel on VPN-rakendus, mis registreerub platvormi VPN-teenuses, küsib kasutajalt ühe korra nõusolekut ja saab oma tunneli jaoks failideskriptori. Seejärel suunab platvorm liikluse sellesse deskriptorisse ja rakendab rakenduste ulatust, mille kasutaja või administraator valis, seepärast saab sama mehhanism olla rakendusepõhine, profiilipõhine ning kombineeritud alati-sees ja ilma VPN-ita blokeerimise seadetega. Androidi VPN-i arendusjuhend kirjeldab seda käepigistust ja põhipunkt on, et see on registreerimine, mitte marsruutimise nipp.

Deemon chrooti sees ei registreeru kunagi. Puudub nõusolekudialoog, võtmeikoon olekuribal, rakendusepõhine kaasamis- või väljajätmisnimekiri ja osalemine alati-sees poliitikas. Seepärast kasutavad rakendused edasi vaikevõrku ja tunnel kannab ainult seda, mida shell ise saadab.

Ka vastassuund ei aita. Marsruutide lükkamine hosti nimeruumi püüab kõik kinni, ka liikluse, mille platvorm lootis jätta kohalikuks, ja teeb seda ilma rakendusepõhise kontrollita ning ilma, et kasutaja saaks seda näha või tühistada. Pole vahepealset seadet, kus chrooti deemon suunab liiklust ainult ühe rakenduse jaoks.

Binaarne ühilduvus on eraldi sein

Isegi kui võrgu pool on huvitav, on käivitataval failil omad nõuded: CPU arhitektuur, dünaamiline laadur, C-teek ja tuuma võimalused, mida see eeldab. Android kasutab glibc asemel bionicut ja töölaua distributsiooni jaoks ehitatud vana binaarfail võib vajada teeke, mida seadmes enam pole.

Teegi failinime sidumine uuema versiooniga ei loo ABI-ühilduvust ja kümme aastat vana paketi arhiveeritud krüptoteek pole hooldatud komponent. Kui plaan sellest sõltub, on plaan käitada hooldamata koodi võrguõigustega telefonis.

Tõesta seda Androidi kontekstis ja korista pärast

Testi seda, mis sulle tegelikult oluline on, sellelt poolelt, mis loeb: ava konkreetne rakendus, jõua konkreetsesse privaatsesse sihtkohta, kinnita, milline resolver vastas, seejärel lahuta tunnel ja kinnita dokumenteeritud käitumine. Tulemus chrooti sees olevast terminalist on tõend selle terminali täitmiskonteksti kohta ja ei midagi enamat.

Kui muutsid katse ajal hosti marsruute, taasta need ja kirjuta üles, mida muutsid. Seejärel kontrolli, kas telefonil on seadistatud alati-sees VPN, sest vana katse, mis jättis reegli maha, võib kuude pärast näida platvormi rikkena.

Tõelise kaugjuurdepääsu vajaduse korral kasuta teenuse toetatud klienti või kinnitatud lüüsi lahendust. Küsimus, mida tasub küsida, pole see, kas root-paigaldaja tööle saab, vaid kas toetatud teostus viib vajalikud rakendused üle kavatsetud piiri, jätmata seadmesse omanikuta privileegseid muudatusi.