Jo krije in Linux-distribúsje oan it draaien ûnder in chroot op ’e telefoan, sette dêr in VPN-klant yn, en de shell meldt in foltôge tunnel. Dan gean jo nei in browser en it ferkear giet oer mobile data nei bûten as wie der neat bard. Of it tsjinstelde: elke app op ’e telefoan ferliest ferbining om’t de klant in standertrûte set hat yn ’e nammeromte dy’t Android echt brûkt. Dy twa symptomen komme fan itselde ûntbrekkende stik, en gjinien is in bug yn ’e VPN-klant.

De shell seit ferbûn, de apps binne it net iens

De earste útkomst is de gewoane. In tunnel yn ’e brûkersromte iepene fanút in chroot kin syn handshake ôfmeitsje, syn statistiken printsje en ferkear drage dat deselde shell makket, wylst de apps fan Android de standertnetwurk fan ’e telefoan bliuwe brûken. Neat ûnderskept se, om’t neat Android ferteld hat dat der in VPN is.

De twadde útkomst is de gefaarlike. As de chroot de netwurknammeromte fan Android dielt, wat standert it gefal is, kin in proses mei genôch foech rûtes en in TUN-ynterface tafoegje dy’t de hiele telefoan beynfloedzje. Dan wurket de tunnel foar elke app, ek foar dy’t jo net routearje woene, en de ferbining fan ’e telefoan hinget no fan in daemon ôf sûnder libbenssyklusbehear, sûnder ferbiningsyndikator en sûnder altyd-om-polityk.

Hokker fan ’e twa jo krigen hawwe is mei ien opdracht te beantwurdzjen. Fergelykje ip route yn ’e chroot mei deselde opdracht fan in Android-shell bûten. Deselde útfier betsjut dat de chroot yn ’e nammeromte fan ’e host sit: elke netwurkferoaring dy’t er makket jildt foar de hiele telefoan. Oare útfier betsjut dat de lansearder in nammeromte foar him makke hat, en syn tunnel is foar Android neffens it ûntwerp ûnsichtber.

Wat chroot feroare en wat net

ObjectEffect of a chroot
Pathname resolutionChanged: lookups start at the new root
Kernel and driversUnchanged: the phone's kernel, its TUN driver, its limits
Network namespaceUnchanged unless the launcher creates one
Android VPN registrationUnchanged: no app consented, no VPN is selected

De systeemoprop chroot docht ien ding: hy feroaret de map dy’t brûkt wurdt foar paadoplossing. De man-side seit dúdlik dat it gjin feiligensgrins is, en seit neat oer ynterfaces, rûtes of VPN-steat. Alles wat minsken fan in Linux-kontener ferwachtsje — in privee netwurkstapel, in filtere bestânssysteem, boarnepigingen — komt fan oare meganismen dy’t de lansearder brûkt hawwe kin of net.

Dêrom beantwurdzje bewearings dat in chroot in VPN isolearret meastentiids de ferkearde fraach. De relevante fraach is yn hokker nammeromte it proses draait en yn hokker SELinux-domein it beheind is, en beide binne eigenskippen fan hoe’t it start is, net fan it wurd chroot.

TUN hat trije dingen nedich, en in apparaatknooppunt is mar ien

In tradisjonele tunnel yn ’e brûkersromte hat in TUN-apparaat nedich dat er iepenje kin, kernelstipe foar dat apparaat, en tastimming om de ynterface en de rûtes te konfigurearjen. Dat binne aparte easken, en it meitsjen fan in paadnamme ûnder /dev foldocht sels oan gjinien fan har:

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

Op Android is TUN-stipe meastentiids yn ’e kernel kompilearre, om’t de eigen VPN-tsjinst fan it platform him brûkt, mar dat betsjut net dat jo proses him brûke mei. It konfigurearjen fan ’e ynterface easket netwurkbehearfermogen, en SELinux beslút oft it proses it apparaatknooppunt ynhim berikke mei. In wegering liket op in tastimmingsflater sûnder dúdlike oarsaak, en it antwurd sit yn it auditpaad:

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

Root lost dit net op. SELinux beheint prosessen ûnder uid 0 krekt as oaren, dat in chroot start fan in root-shell kin noch altyd in apparaat wegere wurde dat er sjocht. It útsetten fan ’e hanthavening om in âlde installer wurkje te litten is in beslút foar de hiele telefoan mei gefolgen fier foarby de tunnel, en it is gjin repaaraasje foar in ferâldere binary.

Wêrom’t Android-apps jo tunnel negearje

It stipe model fan Android is in VPN-app dy’t him registrearret by de VPN-tsjinst fan it platform, de brûker ien kear om tastimming freget en in bestânsbeskriuwer foar syn tunnel krijt. Dan liedt it platform it ferkear yn dy beskriuwer en hanthavet it app-berik dat de brûker of behearder keas, dêrom kin itselde meganisme per app, per profyl en kombinearre mei altyd-om en blokkearje sûnder VPN wêze. De Android VPN-ûntwikkelegids beskriuwt dy handshake, en it kearnpunt is dat it in registraasje is, gjin routingtrick.

In daemon yn in chroot registrearret him nea. Der is gjin tastimmingsdialooch, gjin kaai-ikoan yn ’e steatbalke, gjin list om apps yn of út te sluten, en gjin dielname oan ’e altyd-om-polityk. Dêrom bliuwe apps it standertnetwurk brûken, en de tunnel draacht allinnich wat de shell sels stjoert.

De oare kant helpt ek net. Rûtes yn ’e nammeromte fan ’e host triuwe fangt alles, ek ferkear dat it platform lokaal hâlde woe, en docht dat sûnder behear per app en sûnder dat de brûker it sjen of weromlûke kin. Der is gjin tuskenynstelling wêryn in chroot-daemon ferkear foar mar ien app liedt.

Binêre kompatibiliteit is in aparte muorre

Sels as de netwurkkant nijsgjirrich is, hat it útfierbere bestân syn eigen easken: CPU-arsjitektuer, de dynamyske lader, de C-bibleteek en de kernelmooglikheden dy’t it ferwachtet. Android brûkt bionic yn stee fan glibc, en in âlde binary boud foar in buroblêd-distribúsje kin bibleteken nedich hawwe dy’t net mear op it apparaat steane.

In bibleteekbestânsnamme oan in nijere ferzje keppelje makket gjin ABI-kompatibiliteit, en in argivearre kryptobibleteek út in pakket fan tsien jier âld is gjin ûnderholden komponint. As it plan dêrfan ôfhinget, is it plan om ûnûnderholden koade mei netwurkfoech op in telefoan te draaien.

Bewiis it yn ’e Android-kontekst en romje dêrnei op

Test wat jo echt wichtich fine, fan ’e kant dy’t wichtich is: iepenje de konkrete app, berik de konkrete priveebestimming, befêstigje hokker resolver antwurde, knippe dan de tunnel ôf en befêstigje it dokumintearre gedrach. In resultaat fan in terminal yn ’e chroot is bewiis oer de útfieringskontekst fan dy terminal en net mear.

As jo ûnder it eksperimint hostrûtes feroare hawwe, set se dan werom en skriuw op wat jo feroare hawwe. Kontrolearje dan oft de telefoan in altyd-om VPN konfigurearre hat, om’t in âld eksperimint dat in regel efterliet moannen letter op in platformflater lykje kin.

Foar in echte needsaak oan tagong op ôfstân brûk de stipe klant fan ’e tsjinst of in goedkard poartûntwerp. De fraach dy’t it wurdich is om te stellen is net oft in root-installer oan it wurk te krijen is, mar oft in stipe ymplemintaasje de apps dy’t jo nedich hawwe oer de grins drage dy’t jo bedoelden, sûnder ûneigene foechferoarings op it apparaat efter te litten.

Relatearre artikelen