Android chroot VPN: kwa nini handaki inafanya kazi na programu zinaipuuza
Chroot hubadilisha utafutaji wa njia pekee, si kernel, nafasi ya majina ya mtandao au usajili wa VPN wa Android. Kutokana na hilo kuna matokeo mawili, na yote mawili huwashangaza watu.
Unapata usambazaji wa Linux unaoendesha chini ya chroot kwenye simu, unainstall mteja wa VPN ndani yake, na shell inatangaza kwamba handaki imekamilika. Kisha unahamia kwenye kivinjari na trafiki inatoka kupitia data ya simu kana kwamba hakuna kilichotokea. Au kinyume chake: kila programu kwenye simu inapoteza muunganisho kwa sababu mteja aliweka njia ya chaguo-msingi katika nafasi ya majina ambayo Android inatumia kwa kweli. Dalili hizi mbili zinatoka kwenye kipande kimoja kinachokosekana, na hakuna moja ambayo ni hitilafu katika mteja wa VPN.
Shell inasema imeunganishwa, programu hazikubali
Tokeo la kwanza ni lile la kawaida. Handaki ya nafasi ya mtumiaji iliyofunguliwa kutoka chroot inaweza kukamilisha kupeana mkono, kuchapisha takwimu zake na kubeba trafiki inayotengenezwa na shell hiyo hiyo, wakati programu za Android zinaendelea kutumia mtandao wa chaguo-msingi wa simu. Hakuna kinachozizuia, kwa sababu hakuna kilichomwambia Android kwamba VPN ipo.
Tokeo la pili ni lile la hatari. Ikiwa chroot inashiriki nafasi ya majina ya mtandao ya Android, ambayo hufanya kwa chaguo-msingi, mchakato wenye uwezo wa kutosha unaweza kuongeza njia na kiolesura cha TUN vinavyoathiri simu yote. Wakati huo handaki inafanya kazi kwa kila programu, ikiwa ni pamoja na zile ambazo hukukusudia kuzipitisha, na muunganisho wa simu sasa unategemea daemon isiyo na usimamizi wa mzunguko wa maisha, isiyo na kiashiria cha muunganisho na isiyo na sera ya kuwaka kila wakati.
Ni ipi kati ya hizo mbili uliyopata inaweza kujibiwa kwa amri moja. Linganisha ip route ndani ya chroot na amri hiyo hiyo kutoka shell ya Android nje yake. Matokeo yanayofanana yanamaanisha chroot iko katika nafasi ya majina ya mwenyeji: mabadiliko yoyote ya mtandao inayofanya yanahusu simu yote. Matokeo tofauti yanamaanisha kianzishi kiliunda nafasi ya majina kwa ajili yake, na handaki yake haionekani kwa Android kwa muundo wake.
Chroot ilibadilisha nini na haikubadilisha nini
| 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 |
Wito wa mfumo wa chroot hufanya jambo moja: hubadilisha saraka inayotumika kutatua majina ya njia. Ukurasa wa man unasema wazi kwamba si mpaka wa usalama, na hausemi chochote kuhusu violesura, njia au hali ya VPN. Kila kitu ambacho watu wanatarajia kutoka kwa kontena ya Linux — stack ya mtandao ya kibinafsi, mfumo wa faili uliochujwa, mipaka ya rasilimali — hutoka kwa mifumo mingine ambayo kianzishi kinaweza kuwa kilitumia au la.
Ndiyo sababu madai kwamba chroot hutenga VPN kwa kawaida hujibu swali lisilo sahihi. Swali linalofaa ni mchakato unaendesha katika nafasi gani ya majina na umezuiwa katika kikoa gani cha SELinux, na zote mbili ni sifa za jinsi ulivyoanzishwa, si za neno chroot.
TUN inahitaji vitu vitatu, na fundo la kifaa ni kimoja tu
Handaki ya jadi ya nafasi ya mtumiaji inahitaji kifaa cha TUN inachoweza kufungua, msaada wa kernel kwa kifaa hicho, na ruhusa ya kusanidi kiolesura na njia. Hizi ni mahitaji tofauti, na kuunda jina la njia chini ya /dev hakiwezi kukidhi hata moja kwa vyake:
ls -l /dev/net/tun
ip tuntap add dev tun0 mode tun
Kwenye Android kernel huwa na msaada wa TUN uliokusanywa, kwa sababu huduma ya VPN ya jukwaa yenyewe inautumia, lakini hiyo haimaanishi kwamba mchakato wako unaweza kuutumia. Usanidi wa kiolesura unahitaji uwezo wa usimamizi wa mtandao, na SELinux huamua kama mchakato unaweza kufikia fundo la kifaa kabisa. Kukataliwa kunaonekana kama hitilafu ya ruhusa isiyo na sababu dhahiri, na jibu liko kwenye rekodi ya ukaguzi:
dmesg | grep avc
logcat -d | grep "avc: denied"
Root haitatui hii. SELinux huzuia michakato inayoendesha kama uid 0 sawa na mingine, kwa hiyo chroot iliyoanzishwa kutoka shell ya root bado inaweza kunyimwa kifaa inachokiona. Kuzima utekelezaji ili kisakinishi cha zamani kifanye kazi ni uamuzi wa simu yote wenye matokeo mbali zaidi ya handaki, na si suluhisho la faili la binary lililopitwa na wakati.
Kwa nini programu za Android zinapuuza handaki yako
Mfano unaotumika wa Android ni programu ya VPN inayojisajili kupitia huduma ya VPN ya jukwaa, kuomba idhini ya mtumiaji mara moja na kupokea kielekezi cha faili kwa handaki yake. Jukwaa kisha huelekeza trafiki kwenye kielekezi hicho na kutekeleza wigo wa programu uliochaguliwa na mtumiaji au msimamizi, ndiyo sababu utaratibu huo huo unaweza kuwa kwa kila programu, kwa kila wasifu na kuunganishwa na mipangilio ya kuwaka kila wakati na kuzuia bila VPN. Mwongozo wa ukuzaji wa VPN wa Android unaeleza kupeana mkono huko, na jambo la muhimu ni kwamba ni usajili, si hila ya uelekezaji.
Daemon ndani ya chroot haijisajili kamwe. Hakuna mazungumzo ya idhini, hakuna aikoni ya ufunguzi kwenye upau wa hali, hakuna orodha ya kujumuisha au kuondoa kwa kila programu, na hakuna ushiriki katika sera ya kuwaka kila wakati. Kwa hiyo programu zinaendelea kutumia mtandao wa chaguo-msingi, na handaki inabeba tu kile shell yenyewe inatuma.
Kwenda upande mwingine pia hakusaidii. Kusukuma njia kwenye nafasi ya majina ya mwenyeji kunakamata kila kitu, ikiwa ni pamoja na trafiki ambayo jukwaa lilitarajia ibaki ya ndani, na hufanya hivyo bila udhibiti kwa kila programu na bila njia ya mtumiaji kuiona au kuibatilisha. Hakuna mpangilio wa kati ambapo daemon ya chroot inaelekeza trafiki kwa programu moja pekee.
Utangamano wa binary ni ukuta tofauti
Hata wakati upande wa mtandao unavutia, faili inayotekelezeka ina mahitaji yake: usanifu wa CPU, kipakiaji kinachobadilika, maktaba ya C, na vifaa vya kernel inavyotarajia. Android hutumia bionic badala ya glibc, na binary ya zamani iliyoundwa kwa usambazaji wa kompyuta ya mezani inaweza kuhitaji maktaba ambazo hazipo tena kwenye kifaa.
Kuunganisha jina la faili la maktaba kwa kiungo cha mfano na toleo jipya hakuundi utangamano wa ABI, na maktaba ya kriptografia iliyohifadhiwa kutoka kifurushi cha miaka kumi iliyopita si sehemu inayodumishwa. Ikiwa mpango unategemea hilo, mpango ni kuendesha msimbo usiodumishwa wenye mapendeleo ya mtandao kwenye simu.
Thibitisha katika muktadha wa Android na usafishe baada ya
Jaribu kile unachojali kwa kweli, kutoka upande unaohesabiwa: fungua programu mahususi, fikia lengo la kibinafsi mahususi, thibitisha ni kisuluhishi kipi kilijibu, kisha tenganisha handaki na uthibitishe tabia iliyoandikwa. Matokeo kutoka terminal ndani ya chroot ni ushahidi kuhusu muktadha wa utekelezaji wa terminal hiyo na si zaidi.
Ikiwa ulibadilisha njia za mwenyeji wakati wa majaribio, zirudishe na uandike ulibadilisha nini. Kisha angalia kama simu ina VPN ya kuwaka kila wakati iliyosanidiwa, kwa sababu jaribio la zamani lililoacha kanuni linaweza kuonekana kama hitilafu ya jukwaa miezi kadhaa baadaye.
Kwa hitaji halisi la ufikiaji wa mbali, tumia mteja unaotumika wa huduma au muundo wa lango ulioidhinishwa. Swali linalofaa kuulizwa si kama kisakinishi cha root kinaweza kufanywa kifanye kazi, bali kama utekelezaji unaotumika unavuka mipaka uliyokusudia na programu unazohitaji, bila kuacha mabadiliko ya mapendeleo yasiyo na mmiliki kwenye kifaa.