chroot VPN Androiden: zergatik funtzionatzen du tuneleak eta zergatik ez diete aplikazioek begiratzen
chroot-ek bideen ebazpena aldatzen du, ez kernela, sare-namespacea edo Androiden VPN erregistroa. Hortik bi emaitza datoz eta biek harritzen dute jendea.
Linux banaketa bat chroot batean jartzen duzu telefonoan, VPN bezero bat instalatzen duzu bertan, eta shell-ak tunelea osatuta dagoela iragartzen du. Gero nabigatzailera joaten zara eta trafikoa datu mugikorretik ateratzen da, ezer gertatu ez balitz bezala. Edo alderantziz: telefonoan dauden aplikazio guztiek konexioa galtzen dute, bezeroak Android-ek benetan erabiltzen duen namespacean defektuzko bide bat sartu duelako. Bi sintoma horiek pieza falta beretik datoz eta bat ere ez da VPN bezeroaren akatsa.
Shell-ak konektatuta dio, aplikazioek ez dute bat egiten
Lehen emaitza ohikoena da. chroot-etik irekitako erabiltzaile-espazioko tunele batek bere handshakea osa dezake, estatistikak inprimatu eta shell berak sortzen duen trafikoa eraman, Androiden aplikazioek telefonoaren defektuzko sarea erabiltzen jarraitzen duten bitartean. Ezerk ez ditu eteten, ezerk ez baitzioen Androidi VPN bat badagoela esan.
Bigarren emaitza arriskutsua da. chroot-ek Androiden sare-namespacea partekatzen badu, lehenespenez hori gertatzen da, pribilegio nahikoa duen prozesu batek telefono osoari eragiten dioten bideak eta TUN interfazea gehi ditzake. Orduan tuneleak aplikazio guztietarako funtzionatzen du, bideratu nahi ez zenituenen barne, eta telefonoaren konektibitatea bizitzaren zikloaren kudeaketarik, konexio-adierazlerik eta beti-piztuta politikarik gabeko demonio baten mende dago orain.
Bi emaitzetatik zein jaso duzun agindu bakar batekin erantzun daiteke. Konparatu ip route chroot barruan kanpoko Android shell bateko agindu berarekin. Irteera berbera bada, chroot host-aren namespacean dago: egiten duen sare-aldaketa oro telefono osorako da. Irteera desberdina bada, abiarazleak namespace bat sortu dio eta haren tunelea eraikuntzaz ikusezina da Androidentzat.
Zer aldatu zuen chroot-ek eta zer ez
| 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 |
chroot sistema-deiak gauza bat egiten du: bideen ebazpenerako erabiltzen den direktorioa aldatzen du. man orriak argi dio ez dela segurtasun-muga bat, eta ez du ezer esaten interfaze, bide edo VPN egoerari buruz. Jendeak Linux edukiontzi bati espero dion guztia — sare-pila pribatua, iragazitako fitxategi-sistema, baliabide-mugak — abiarazleak erabili zuen edo ez zuen beste mekanismo batzuetatik dator.
Horregatik chroot-ek VPN bat isolatzen duela dioenak galdera okerra erantzuten du normalean. Garrantzizko galdera da zein namespace-tan exekutatzen den prozesua eta zein SELinux domeinutan dagoen mugatuta, eta biak hasi zen moduaren ezaugarriak dira, ez chroot hitzarenak.
TUN-ek hiru gauza behar ditu eta gailu-nodo bat bakarra da
Erabiltzaile-espazioko tunele tradizional batek ireki dezakeen TUN gailua, gailu horretarako kernelaren sostengua eta interfazea eta bideak konfiguratzeko baimena behar ditu. Baldintza bereiziak dira eta /dev azpian bide-izen bat sortzeak ez du horietako bat ere betetzen bere horretan:
ls -l /dev/net/tun
ip tuntap add dev tun0 mode tunAndroiden kernelak TUN sostengua konpilatuta izan ohi du, plataformaren VPN zerbitzuak erabiltzen duelako, baina horrek ez du esan nahi zure prozesuak erabil dezakeenik. Interfazea konfiguratzeko sare-administrazio gaitasuna behar da eta SELinux-ek erabakitzen du prozesuak gailu-nodoa lor dezakeen. Ukapenak arrazoi argirik gabeko baimen-errore itxura du eta erantzuna auditoria-arrastoan dago:
dmesg | grep avc
logcat -d | grep "avc: denied"Root-ek ez du hau konpontzen. SELinux-ek uid 0 gisa exekutatzen diren prozesuak besteak bezala mugatzen ditu, beraz root shell batetik hasitako chroot bati ikusten duen gailu bat ukatu ahal zaio oraindik. Betearazpena desaktibatzea instalatzaile zahar batek funtziona dezan telefono osorako erabakia da, tunelearen askoz harago doazen ondorioekin, eta ez da binary zaharkitu baten konponbidea.
Zergatik ez diete Androiden aplikazioek zure tuneleari begiratzen
Androiden onartutako eredua plataformaren VPN zerbitzuan erregistratzen den, erabiltzaileari behin baimena eskatzen dion eta bere tunelearentzat fitxategi-deskriptore bat jasotzen duen VPN aplikazio bat da. Gero plataformak trafikoa deskriptore horretara bideratzen du eta erabiltzaileak edo administratzaileak hautatutako aplikazio-eremua betearazten du, horregatik mekanismo berak aplikazioka, profilka eta beti-piztuta eta VPN gabe blokeatzeko ezarpenekin konbina daiteke. Android VPN garapen gidak handshake hori deskribatzen du eta funtsezko puntua da erregistro bat dela, ez bideratze-trikimailu bat.
chroot barruko demonio bat ez da inoiz erregistratzen. Ez dago baimen-elkarrizketarik, ez gako-ikonorik egoera-barran, ez aplikazioka sartzeko edo baztertzeko zerrendarik, ez eta beti-piztuta politikan parte-hartzerik. Beraz aplikazioek defektuzko sarea erabiltzen jarraitzen dute eta tuneleak shell-ak berak bidaltzen duena baino ez du eramaten.
Aurkako norabideak ere ez du laguntzen. Bideak host-aren namespace-ra bultzatzeak dena harrapatzen du, plataformak lokal mantendu nahi zuen trafikoa barne, eta aplikazioko kontrolik gabe egiten du, erabiltzaileak ikusi edo baliogabetzeko modurik gabe. Ez dago ezarpen ertainik non chroot-eko demonio batek aplikazio bakarraren trafikoa bideratzen duen.
Bitar-konpatibilitatea horma bereizia da
Sare-aldea interesgarria izan arren, exekutagarriak bere baldintzak ditu: CPU arkitektura, kargatzaile dinamikoa, C liburutegia eta espero dituen kernel gaitasunak. Android-ek bionic erabiltzen du, glibc ez, eta mahaigaineko distribuzio baterako eraikitako binary zahar batek gailuan jada ez dauden liburutegiak behar ditzake.
Liburutegi baten fitxategi-izena bertsio berriago batekin lotzeak ez du ABI konpatibilitaterik sortzen, eta hamar urteko pakete batetik artxibatutako kriptografia-liburutegia ez da mantendutako osagaia. Plana horren mende badago, plana da mantendu gabeko kodea sare-pribilegioekin telefonoan exekutatzea.
Froga ezazu Androiden testuinguruan eta garbitu ondoren
Probatu benetan axola zaizuna, axola duen aldetik: ireki aplikazio zehatza, iritsi helburu pribatu zehatzera, egiaztatu zein resolverrek erantzun zuen, gero deskonektatu tunelea eta egiaztatu dokumentatutako portaera. chroot barruko terminal bateko emaitza terminal horren exekuzio-testuinguruaren froga da eta ez gehiago.
Esperimentuan zehar host bideak aldatu badituzu, itzuli itzazu eta idatzi zer aldatu duzun. Gero egiaztatu telefonoak beti-piztuta VPN bat konfiguratuta duen, arau bat utzi zuen esperimentu zahar bat hilabete batzuk geroago plataformaren akatsa dirudi eta.
Benetako urruneko sarbide behar baterako, erabili zerbitzuaren onartutako bezeroa edo onartutako atebide diseinua. Galdera merezi duena ez da root instalatzaile bat martxan jar daitekeen, baizik eta onartutako inplementazio batek behar dituzun aplikazioak nahi zenuen mugaz bestaldera eramaten dituen, gailuan jabe gabeko pribilegio-aldaketak utzi gabe.