VPN chrootban Androidon: miért működik az alagút, és miért hagyják figyelmen kívül az alkalmazások

Telepítesz egy Linux disztribúciót chroot alatt a telefonon, beteszed egy VPN klienset, és a shell bejelenti, hogy az alagút elkészült. Aztán átváltasz a böngészőre, és a forgalom a mobiladaton keresztül megy ki, mintha mi sem történt volna. Vagy fordítva: minden alkalmazás elveszíti a kapcsolatot, mert a kliens alapértelmezett útvonalat tett abba a névtérbe, amelyet az Android valóban használ. Mindkét tünet ugyanabból a hiányzó darabból ered, és egyik sem a VPN kliens hibája.

A shell azt mondja kapcsolódva, az alkalmazások nem értenek egyet

Az első következmény a szokásos. A chrootból megnyitott felhasználói téri alagút befejezheti a kézfogást, kinyomtathatja a statisztikáit, és szállíthatja azt a forgalmat, amelyet ugyanez a shell állít elő, miközben az Android alkalmazásai továbbra is a telefon alapértelmezett hálózatát használják. Semmi nem fogja el őket, mert semmi nem mondta meg az Androidnak, hogy létezik VPN.

A második következmény a veszélyes. Ha a chroot megosztja az Android hálózati névterét, ami alapértelmezés, egy elegendő jogosultságú folyamat útvonalakat és TUN interfészt adhat hozzá, amelyek az egész telefonra hatnak. Ekkor az alagút minden alkalmazás számára működik, azokkal együtt, amelyeket nem akartál átirányítani, és a telefon kapcsolata most egy olyan démontól függ, amelynek nincs életciklus-kezelése, kapcsolatjelzője és mindig bekapcsolt szabályzata.

Melyik következményt kaptad, egyetlen paranccsal eldönthető. Hasonlítsd össze a ip route parancsot a chrooton belül ugyanazzal a paranccsal egy kívüli Android shellből. Azonos kimenet azt jelenti, hogy a chroot a gazda névterében van: minden hálózati változtatása az egész telefonra érvényes. Eltérő kimenet azt jelenti, hogy az indító névteret hozott létre neki, és az alagútja felépítésénél fogva láthatatlan az Android számára.

Mit változtatott meg a chroot és mit nem

A chroot rendszerhívás egy dolgot tesz: megváltoztatja az útvonal-feloldáshoz használt könyvtárat. A man oldal kimondja, hogy ez nem biztonsági határ, és semmit nem mond az interfészekről, útvonalakról vagy a VPN állapotáról. Minden, amit az emberek egy Linux konténertől várnak — privát hálózati verem, szűrt fájlrendszer, erőforráskorlátok — más mechanizmusokból jön, amelyeket az indító használhatott vagy nem.

Ezért a chroot VPN-elkülönítéséről szóló állítások általában a rossz kérdésre válaszolnak. A lényeges kérdés az, melyik névtérben fut a folyamat, és melyik SELinux-tartományba van zárva, és mindkettő annak a tulajdonsága, hogyan indították, nem a chroot szóé.

A TUN-nak három dolog kell, és az eszközcsomópont csak egy

A hagyományos felhasználói téri alagútnak kell egy TUN eszköz, amelyet meg tud nyitni, kerneltámogatás ehhez az eszközhöz, és engedély az interfész és az útvonalak beállításához. Ezek külön követelmények, és egy útvonalnév létrehozása a /dev alatt önmagában egyiket sem teljesíti:

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

Androidon a TUN támogatás általában be van fordítva a kernelbe, mert a platform saját VPN szolgáltatása használja, de ez nem jelenti azt, hogy a te folyamatod használhatja. Az interfész beállításához hálózati adminisztrációs képesség kell, és a SELinux dönti el, hogy a folyamat egyáltalán elérheti-e az eszközcsomópontot. Az elutasítás nyilvánvaló ok nélküli engedélyhibának tűnik, és a válasz az auditnyomban van:

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

A root nem oldja meg ezt. A SELinux az uid 0 alatt futó folyamatokat ugyanúgy korlátozza, mint a többieket, ezért a root shellből indított chroot is kaphat elutasítást egy eszközre, amelyet lát. Az érvényesítés kikapcsolása egy régi telepítő működéséhez az egész telefonra szóló döntés, amelynek következményei messze túlmutatnak az alagúton, és nem megoldás egy elavult binárisra.

Miért hagyják figyelmen kívül az Android alkalmazásai az alagutadat

Az Android támogatott modellje egy VPN alkalmazás, amely a platform VPN szolgáltatásán keresztül regisztrál, egyszer kéri a felhasználó hozzájárulását, és fájlleírót kap az alagútjához. Ezután a platform a forgalmat abba a leíróba irányítja, és érvényesíti a felhasználó vagy az adminisztrátor által választott alkalmazáskört, ezért lehet ugyanaz a mechanizmus alkalmazásonként, profilonként, és kombinálható a mindig bekapcsolt és a VPN nélküli blokkolás beállításaival. Az Android VPN fejlesztői útmutatója leírja ezt a kézfogást, és a lényeg, hogy ez regisztráció, nem útvonalazási trükk.

A chrooton belüli démon soha nem regisztrál. Nincs hozzájárulási párbeszéd, nincs kulcsikon az állapotsorban, nincs alkalmazásonkénti belefoglalási vagy kizárási lista, és nincs részvétel a mindig bekapcsolt szabályzatban. Az alkalmazások ezért továbbra is az alapértelmezett hálózatot használják, és az alagút csak azt szállítja, amit maga a shell küld.

A másik irány sem segít. Az útvonalaknak a gazda névterébe tolása mindent elfog, beleértve a forgalmat, amelyet a platform helyben akart tartani, és ezt alkalmazásonkénti vezérlés nélkül teszi, és anélkül, hogy a felhasználó láthatná vagy visszavonhatná. Nincs köztes beállítás, ahol egy chrootos démon csak egy alkalmazás forgalmát irányítja.

A bináris kompatibilitás külön fal

Még ha a hálózati oldal érdekes is, a futtatható fájlnak megvannak a maga követelményei: CPU-architektúra, dinamikus betöltő, C könyvtár és a kernel azon képességei, amelyeket elvár. Az Android bionicot használ glibc helyett, és egy asztali disztribúcióhoz épített régi bináris olyan könyvtárakat igényelhet, amelyek már nincsenek az eszközön.

Egy könyvtárfájlnév hozzákapcsolása egy újabb verzióhoz nem teremt ABI-kompatibilitást, és egy tízéves csomagból archivált kriptográfiai könyvtár nem karbantartott komponens. Ha a terv ezen múlik, a terv az, hogy karbantartatlan kódot futtass hálózati jogosultságokkal egy telefonon.

Bizonyítsd az Android kontextusában, aztán takaríts

Azt teszteld, ami igazán számít neked, arról az oldalról, amelyik számít: nyisd meg az adott alkalmazást, érd el az adott privát célt, ellenőrizd, melyik feloldó válaszolt, aztán szakítsd meg az alagutat és igazold a dokumentált viselkedést. A chrooton belüli terminál eredménye csak az adott terminál végrehajtási környezetéről szóló bizonyíték, semmi több.

Ha a kísérlet során módosítottad a gazda útvonalait, állítsd vissza őket, és jegyezd fel, mit változtattál. Aztán ellenőrizd, van-e a telefonon mindig bekapcsolt VPN, mert egy régi kísérlet, amely szabályt hagyott maga után, hónapokkal később platformhibának tűnhet.

Valódi távoli hozzáférési igényhez használd a szolgáltatás támogatott kliensét vagy jóváhagyott átjárótervet. A kérdés, amit érdemes feltenni, nem az, hogy működésre bírható-e egy root telepítő, hanem hogy egy támogatott megvalósítás átviszi-e a szükséges alkalmazásokat a szándékolt határon, anélkül hogy gazdátlan jogosultságú változtatásokat hagyna az eszközön.