Android chroot VPN: pse tuneli funksionon dhe aplikacionet e injorojnë

Merrni një shpërndarje Linux që punon nën chroot në telefon, instaloni një klient VPN brenda saj, dhe shell-i njofton se tuneli është gati. Pastaj kaloni te shfletuesi dhe trafiku del përmes të dhënave mobile sikur të mos kishte ndodhur asgjë. Ose e kundërta: çdo aplikacion në telefon humbet lidhjen sepse klienti vendosi një rrugë të paracaktuar në hapësirën e emrave që Android përdor në të vërtetë. Të dy simptomat vijnë nga i njëjti element që mungon, dhe asnjëri nuk është defekt i klientit VPN.

Shell-i thotë i lidhur, aplikacionet nuk pajtohen

Rezultati i parë është ai i zakonshmi. Një tunel në hapësirën e përdoruesit i hapur nga chroot mund të përfundojë shtrëngimin e duarve, të shtypë statistikat dhe të transportojë trafikun që prodhon i njëjti shell, ndërsa aplikacionet e Android vazhdojnë të përdorin rrjetin e paracaktuar të telefonit. Asgjë nuk i intercepton, sepse asgjë nuk i tha Android-it se ekziston një VPN.

Rezultati i dytë është ai i rrezikshmi. Nëse chroot ndan hapësirën e emrave të rrjetit të Android, gjë që e bën si parazgjedhje, një proces me privilegje të mjaftueshme mund të shtojë rrugë dhe një ndërfaqe TUN që ndikojnë në të gjithë telefonin. Atëherë tuneli funksionon për çdo aplikacion, përfshirë ata që nuk kishit ndërmend t'i rrugëtoni, dhe lidhja e telefonit tani varet nga një demon pa menaxhim të ciklit të jetës, pa tregues lidhjeje dhe pa politikë gjithmonë aktive.

Cilin nga të dy keni marrë mund të përcaktohet me një komandë. Krahasoni ip route brenda chroot me të njëjtën komandë nga një shell Android jashtë. Dalje identike do të thotë që chroot është në hapësirën e emrave të hostit: çdo ndryshim rrjeti që bën vlen për të gjithë telefonin. Dalje e ndryshme do të thotë që nisësi krijoi një hapësirë emrash për të, dhe tuneli i tij është i padukshëm për Android nga vetë ndërtimi.

Çfarë ndryshoi chroot dhe çfarë nuk ndryshoi

Thirrja e sistemit chroot bën një gjë: ndryshon drejtorinë e përdorur për zgjidhjen e emrave të shtigjeve. Faqja man thotë shprehimisht se nuk është kufi sigurie, dhe nuk thotë asgjë për ndërfaqet, rrugët ose gjendjen e VPN. Gjithçka që njerëzit presin nga një kontejner Linux — stack rrjeti privat, sistem skedarësh i filtruar, kufizime burimesh — vjen nga mekanizma të tjerë që nisësi mund t'i ketë përdorur ose jo.

Kjo është arsyeja pse pretendimet se chroot izolon një VPN zakonisht përgjigjen pyetjes së gabuar. Pyetja përkatëse është në cilën hapësirë emrash punon procesi dhe në cilën domen SELinux është i kufizuar, dhe të dyja janë veti të mënyrës sesi u nis, jo të fjalës chroot.

TUN kërkon tri gjëra, dhe nyja e pajisjes është vetëm një

Një tunel tradicional në hapësirën e përdoruesit kërkon një pajisje TUN që mund ta hapë, mbështetje të kernelit për atë pajisje, dhe leje për të konfiguruar ndërfaqen dhe rrugët. Këto janë kërkesa të ndara, dhe krijimi i një emri shtegu nën /dev nuk plotëson vetë asnjërën prej tyre:

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

Në Android kernel-i zakonisht ka mbështetje TUN të kompiluar, sepse shërbimi VPN i vetë platformës e përdor, por kjo nuk do të thotë që procesi juaj mund ta përdorë. Konfigurimi i ndërfaqes kërkon aftësinë e administrimit të rrjetit, dhe SELinux vendos nëse procesi mund të arrijë fare nyjen e pajisjes. Një refuzim duket si gabim leje pa shkak të dukshëm, dhe përgjigja është në gjurmën e auditimit:

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

Root nuk e zgjidh këtë. SELinux kufizon proceset që punojnë si uid 0 njësoj si të tjerët, kështu që një chroot i nisur nga një shell root prapë mund të refuzohet për një pajisje që e sheh. Fikja e zbatimit që një instalues i vjetër të punojë është vendim për të gjithë telefonin me pasoja shumë përtej tunelit, dhe nuk është rregullim për një binar të vjetruar.

Pse aplikacionet e Android e injorojnë tunelin tuaj

Modeli i mbështetur i Android është një aplikacion VPN që regjistrohet përmes shërbimit VPN të platformës, kërkon një herë pëlqimin e përdoruesit dhe merr një përshkrues skedari për tunelin e tij. Platforma më pas drejton trafikun në atë përshkrues dhe zbaton shtrirjen e aplikacioneve që zgjodhi përdoruesi ose administratori, prandaj i njëjti mekanizëm mund të jetë për çdo aplikacion, për çdo profil dhe i kombinuar me cilësimet gjithmonë aktiv dhe bllokim pa VPN. Udhëzuesi i zhvillimit të VPN për Android përshkruan atë shtrëngim duarsh, dhe pika kryesore është se është regjistrim, jo mashtrim rrugëtimi.

Një demon brenda chroot nuk regjistrohet kurrë. Nuk ka dialog pëlqimi, nuk ka ikonë çelësi në shiritin e statusit, nuk ka listë përfshirjeje ose përjashtimi për çdo aplikacion, dhe nuk ka pjesëmarrje në politikën gjithmonë aktiv. Prandaj aplikacionet vazhdojnë të përdorin rrjetin e paracaktuar, dhe tuneli transporton vetëm atë që dërgon vetë shell-i.

As shkuarja në drejtimin tjetër nuk ndihmon. Shtyrja e rrugëve në hapësirën e emrave të hostit kap gjithçka, përfshirë trafikun që platforma priste ta mbante lokal, dhe e bën këtë pa kontroll për çdo aplikacion dhe pa mënyrë që përdoruesi ta shohë ose ta anulojë. Nuk ka cilësim të mesëm ku një demon chroot rrugëton trafik vetëm për një aplikacion.

Përputhshmëria binare është mur më vete

Edhe kur ana e rrjetit është interesante, skedari i ekzekutueshëm ka kërkesat e veta: arkitekturën e CPU-së, ngarkuesin dinamik, bibliotekën C dhe lehtësitë e kernelit që pret. Android përdor bionic në vend të glibc, dhe një binar i vjetër i ndërtuar për një shpërndarje desktop mund të ketë nevojë për biblioteka që nuk ekzistojnë më në pajisje.

Lidhja simbolike e emrit të një skedari biblioteke me një version më të ri nuk krijon përputhshmëri ABI, dhe një bibliotekë kriptografike e arkivuar nga një paketë dhjetë vjeçare nuk është komponent i mirëmbajtur. Nëse plani varet nga kjo, plani është të ekzekutosh kod të pambajtur me privilegje rrjeti në një telefon.

Provoje në kontekstin e Android dhe pastaj pastro

Testo atë që të intereson vërtet, nga ana që ka rëndësi: hap aplikacionin konkret, arri destinacionin privat konkret, konfirmo cili zgjidhës u përgjigj, pastaj shkëput tunelin dhe konfirmo sjelljen e dokumentuar. Një rezultat nga një terminal brenda chroot është provë vetëm për kontekstin e ekzekutimit të atij terminali dhe asgjë më shumë.

Nëse ndryshove rrugë të hostit gjatë eksperimenteve, ktheji dhe shkruaj çfarë ndryshove. Pastaj kontrollo nëse telefoni ka një VPN gjithmonë aktiv të konfiguruar, sepse një eksperiment i vjetër që la pas një rregull mund të duket si defekt i platformës pas muajsh.

Për një nevojë reale të aksesit në distancë, përdor klientin e mbështetur të shërbimit ose një dizajn gateway të miratuar. Pyetja që ia vlen të bëhet nuk është nëse një instalues me root mund të vihet në punë, por nëse një implementim i mbështetur i çon aplikacionet që të duhen përtej kufirit që kishit ndërmend, pa lënë në pajisje ndryshime të privilegjuara pa pronar.