Android chroot VPN: kāpēc tunelis strādā, bet lietotnes to ignorē

Jūs iegūstat Linux distribūciju, kas telefonā darbojas zem chroot, instalējat tajā VPN klientu, un čaula paziņo, ka tunelis ir pabeigts. Tad pārslēdzaties uz pārlūku, un plūsma iziet caur mobilajiem datiem tā, it kā nekas nebūtu noticis. Vai otrādi: katra lietotne telefonā zaudē savienojumu, jo klients instalēja noklusējuma maršrutu vārdtelpā, kuru Android faktiski izmanto. Abi šie simptomi nāk no viena un tā paša trūkstošā elementa, un neviens no tiem nav VPN klienta kļūda.

Čaula saka, ka ir savienots, lietotnes nepiekrīt

Pirmais iznākums ir ierastais. No chroot atvērts lietotāja telpas tunelis var pabeigt savu rokasspiedienu, izdrukāt statistiku un pārvadāt plūsmu, ko ģenerē pati šī čaula, kamēr Android lietotnes turpina izmantot telefona noklusējuma tīklu. Nekas tās nepārtver, jo nekas nepateica Android, ka VPN eksistē.

Otrais iznākums ir bīstamais. Ja chroot dala Android tīkla vārdtelpu, ko tas dara pēc noklusējuma, process ar pietiekamām privilēģijām var pievienot maršrutus un TUN saskarni, kas ietekmē visu telefonu. Tad tunelis strādā katrai lietotnei, tostarp tām, kuras jūs neplānojāt maršrutēt, un telefona savienojamība tagad ir atkarīga no dēmona, kuram nav dzīves cikla pārvaldības, savienojuma indikatora un pastāvīgās pieslēgšanās politikas.

Kuru variantu ieguvāt, var noskaidrot ar vienu komandu. Salīdziniet ip route chroot iekšienē ar to pašu komandu Android čaulā ārpus tās. Identiska izvade nozīmē, ka chroot ir saimnieka vārdtelpā: jebkura tīkla izmaiņa, ko tas veic, attiecas uz visu telefonu. Atšķirīga izvade nozīmē, ka palaidējs tam izveidoja vārdtelpu, un tā tunelis Android ir neredzams jau pēc uzbūves.

Ko chroot mainīja un ko nemainīja

Chroot sistēmas izsaukums dara vienu lietu: tas maina direktoriju, ko izmanto ceļu nosaukumu izšķiršanai. Rokasgrāmatas lapa skaidri norāda, ka tā nav drošības robeža, un nekas nav teikts par saskarnēm, maršrutiem vai VPN stāvokli. Viss, ko cilvēki sagaida no Linux konteinera — privāts tīkla steks, filtrēta failu sistēma, resursu ierobežojumi — nāk no citiem mehānismiem, ko palaidējs varēja izmantot vai neizmantot.

Tāpēc apgalvojumi, ka chroot izolē VPN, parasti atbild uz nepareizu jautājumu. Būtiskais jautājums ir, kurā vārdtelpā process darbojas un kurā SELinux domēnā tas ir ierobežots, un abi ir tā palaišanas īpašības, nevis vārda chroot īpašības.

TUN vajag trīs lietas, un ierīces mezgls ir tikai viena

Tradicionālam lietotāja telpas tunelim vajag TUN ierīci, ko tas var atvērt, kodola atbalstu šai ierīcei un atļauju konfigurēt saskarni un maršrutus. Tās ir atsevišķas prasības, un ceļa nosaukuma izveide zem /dev pati par sevi neapmierina nevienu no tām:

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

Android kodolā parasti ir iekompilēts TUN atbalsts, jo to izmanto pašas platformas VPN pakalpojums, taču tas nenozīmē, ka jūsu process to drīkst izmantot. Saskarnes konfigurēšanai vajadzīga tīkla administrēšanas spēja, un SELinux izlemj, vai process vispār drīkst piekļūt ierīces mezglam. Noraidījums izskatās kā atļauju kļūda bez acīmredzama iemesla, un atbilde ir audita žurnālā:

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

Root to neatrisina. SELinux ierobežo procesus, kas darbojas kā uid 0, tieši tāpat kā citus, tāpēc chroot, kas palaists no root čaulas, joprojām var nesaņemt ierīci, kuru tas redz. Piespiešanas izslēgšana, lai strādātu vecs instalētājs, ir visam telefonam pieņemts lēmums ar sekām daudz tālāk par tuneli, un tas nav veca binārā faila labojums.

Kāpēc Android lietotnes ignorē jūsu tuneli

Android atbalstītais modelis ir VPN lietotne, kas reģistrējas platformas VPN pakalpojumā, vienu reizi lūdz lietotāja piekrišanu un saņem faila deskriptoru savam tunelim. Pēc tam platforma novirza plūsmu uz šo deskriptoru un īsteno lietotāja vai administratora izvēlēto lietotņu apjomu, tāpēc viens un tas pats mehānisms var būt atsevišķi katrai lietotnei, katram profilam un apvienots ar pastāvīgās pieslēgšanās un bloķēšanas bez VPN iestatījumiem. Android VPN izstrādes rokasgrāmata apraksta šo rokasspiedienu, un galvenais ir tas, ka tā ir reģistrācija, nevis maršrutēšanas triks.

Dēmons chroot iekšienē nekad nereģistrējas. Nav piekrišanas dialoga, nav atslēgas ikonas statusjoslā, nav lietotņu iekļaušanas vai izslēgšanas saraksta un nav dalības pastāvīgās pieslēgšanās politikā. Tāpēc lietotnes turpina izmantot noklusējuma tīklu, un tunelis pārvada tikai to, ko sūta pati čaula.

Iet pretējā virzienā arī nepalīdz. Maršrutu grūšana uz saimnieka vārdtelpu pārtver visu, tostarp plūsmu, ko platforma cerēja saglabāt lokālu, un tas notiek bez lietotņu līmeņa kontroles un bez iespējas lietotājam to redzēt vai atsaukt. Nav vidēja iestatījuma, kur chroot dēmons maršrutē plūsmu tikai vienai lietotnei.

Binārā saderība ir atsevišķa siena

Pat ja tīkla puse ir interesanta, izpildāmajam failam ir savas prasības: CPU arhitektūra, dinamiskais ielādētājs, C bibliotēka un kodola iespējas, ko tas gaida. Android izmanto bionic, nevis glibc, un vecs binārais fails, kas būvēts darbvirsmas distribūcijai, var prasīt bibliotēkas, kuru ierīcē vairs nav.

Bibliotēkas faila nosaukuma sasaiste ar jaunāku versiju nerada ABI saderību, un arhivēta kriptogrāfijas bibliotēka no pirms desmitgades veidotas pakotnes nav uzturēta komponente. Ja plāns ir atkarīgs no tā, plāns ir telefonā ar tīkla privilēģijām darbināt neuzturētu kodu.

Pierādiet to Android kontekstā un pēc tam sakārtojiet

Pārbaudiet to, kas jums patiešām svarīgs, no puses, kurai ir nozīme: atveriet konkrēto lietotni, sasniedziet konkrēto privāto galamērķi, pārliecinieties, kurš risinātājs atbildēja, pēc tam atvienojiet tuneli un pārbaudiet dokumentēto uzvedību. Rezultāts no termināļa chroot iekšienē ir pierādījums tikai par šī termināļa izpildes kontekstu un nekas vairāk.

Ja eksperimentējot mainījāt saimnieka maršrutus, atgrieziet tos un pierakstiet, ko mainījāt. Pēc tam pārbaudiet, vai telefonā ir konfigurēts pastāvīgais VPN, jo vecāks eksperiments, kas atstāja kādu noteikumu, pēc mēnešiem var izskatīties kā platformas kļūda.

Īstai attālinātās piekļuves vajadzībai izmantojiet pakalpojuma atbalstīto klientu vai apstiprinātu vārtejas dizainu. Jautājums, ko ir vērts uzdot, nav par to, vai roototu instalētāju var piespiest darboties, bet gan par to, vai atbalstīta ieviešana pārnes vajadzīgās lietotnes pāri paredzētajai robežai, neatstājot ierīcē bezīpašnieka privilēģētas izmaiņas.