Та телефон дээр chroot дор ажиллаж буй Linux түгээлтийг суулгаж, дотор нь VPN клиент суулгахад shell туннель бэлэн болсон гэж мэдэгдэнэ. Дараа нь хөтөч рүү шилжихэд урсгал юу ч болоогүй мэт мобайл өгөгдлөөр гарна. Эсвэл эсрэгээр: клиент Android-ын бодитоор ашиглаж буй namespace-д анхдагч маршрут суулгасан тул телефон дээрх бүх апп холболтоо алдана. Энэ хоёр шинж тэмдэг нь нэг дутуу хэсгээс үүдэлтэй бөгөөд аль нь ч VPN клиентийн алдаа биш.

Shell холбогдсон гэж хэлнэ, аппууд санал нийлэхгүй

Эхний үр дүн бол түгээмэл. chroot-оос нээсэн userspace туннель гараа барилцаагаа дуусгаж, статистикаа хэвлэж, мөн shell-ийн үүсгэсэн урсгалыг зөөж чадна, харин Android-ын аппууд утасны анхдагч сүлжээг ашигласар байна. Тэднийг юу ч саатуулахгүй, учир нь VPN байгааг Android-д хэлсэн зүйл байхгүй.

Хоёр дахь үр дүн бол аюултай. Хэрэв chroot нь Android-ын сүлжээний namespace-ийг хуваалцвал, анхдагчаар тийм байдаг, хангалттай эрхтэй процесс бүх утсанд нөлөөлөх маршрут болон TUN интерфейс нэмж чадна. Тэгвэл туннель бүх аппэд ажиллана, таны маршрутлахыг хүсээгүй аппууд ч орно, утасны холболт одоо амьдралын мөчлөгийн удирдлага, холболтын индикатор, always-on бодлого байхгүй демоноос хамаарна.

Аль нь тохиолдсоныг нэг командаар тогтоож болно. chroot доторх ip route-г гаднах Android shell-ийн ижил командын гаралттай харьцуул. Ижил гаралт гэдэг chroot нь хост namespace-д байна гэсэн үг: түүний хийх аливаа сүлжээний өөрчлөлт бүх утсанд хамаарна. Ялгаатай гаралт гэдэг лаунчер түүнд namespace үүсгэсэн гэсэн үг бөгөөд түүний туннель Android-д бүтцийн хувьд үл үзэгдэх юм.

chroot юу өөрчилж, юу өөрчлөөгүй

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

chroot системийн дуудалт нэг л зүйл хийнэ: замын нэрийг тодорхойлоход ашиглах директорийг өөрчилнө. Энэ нь аюулгүй байдлын хил биш гэдгийг man хуудас тодорхой хэлдэг бөгөөд интерфейс, маршрут, VPN төлөвийн талаар огт дурдаагүй. Хүмүүсийн Linux контейнер гэдгээс хүлээдэг бүх зүйл — хувийн сүлжээний стек, шүүсэн файлын систем, нөөцийн хязгаар — лаунчер ашигласан эсвэл ашиглаагүй байж болох бусад механизмаас гардаг.

Тиймээс chroot VPN-ийг тусгаарлана гэсэн мэдэгдэл ихэвчлэн буруу асуултад хариулдаг. Хамаарах асуулт нь процесс аль namespace-д ажиллаж, аль SELinux домэйнд хязгаарлагдаж байгаа бөгөөд хоёулаа түүнийг хэрхэн эхлүүлсний шинж чанар, chroot гэдэг үгийн шинж биш.

TUN-д гурван зүйл хэрэгтэй, төхөөрөмжийн зангилаа нь зөвхөн нэг нь

Уламжлалт userspace туннельд нээж болох TUN төхөөрөмж, тэр төхөөрөмжид цөмийн дэмжлэг, интерфейс ба маршрутыг тохируулах зөвшөөрөл хэрэгтэй. Эдгээр нь тусдаа шаардлага бөгөөд /dev дор замын нэр үүсгэх нь тэдгээрийн аль нэгийг ч өөрөө хангахгүй:

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

Android-д цөмд TUN дэмжлэг ихэвчлэн компиллагдсан байдаг, учир нь платформын өөрийн VPN үйлчилгээ үүнийг ашигладаг, гэхдээ энэ нь таны процесс үүнийг ашиглаж болно гэсэн үг биш. Интерфейсийн тохиргоонд сүлжээний удирдлагын чадвар хэрэгтэй бөгөөд процесс төхөөрөмжийн зангилаанд хүрч чадах эсэхийг SELinux шийднэ. Татгалзал нь тодорхой шалтгаангүй зөвшөөрлийн алдаа мэт харагдах бөгөөд хариулт нь аудитын мөрөнд байна:

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

Root үүнийг шийдэхгүй. SELinux нь uid 0-ээр ажиллаж буй процессийг бусадтай яг адил хязгаарладаг тул root shell-ээс эхэлсэн chroot ч өөрийн харж буй төхөөрөмжөөс татгалзаж болно. Хуучин суулгагчийг ажиллуулахын тулд хэрэгжилтийг унтраах нь туннелийн хязгаараас хамаагүй давсан үр дагавартай, бүх утсанд хамаарах шийдвэр бөгөөд хуучирсан бинарийн засвар биш.

Android аппууд яагаад таны туннелийг үл тоомсорлодог

Android-ын дэмжсэн загвар нь платформын VPN үйлчилгээгээр бүртгүүлж, хэрэглэгчээс нэг удаа зөвшөөрөл аваад, туннелийнхээ файлын дескрипторыг хүлээн авдаг VPN апп юм. Дараа нь платформ урсгалыг тэр дескриптор руу чиглүүлж, хэрэглэгч эсвэл администраторын сонгосон аппын хүрээг хэрэгжүүлдэг; тиймээс нэг механизм нь апп тус бүр, профайл тус бүр байж, always-on болон block-without-VPN тохиргоотой хослож болдог. Android VPN хөгжүүлэлтийн гарын авлага тэр гараа барилцааг тайлбарладаг бөгөөд гол зүйл нь энэ нь бүртгэл, маршрутлалтын заль биш.

chroot доторх демон хэзээ ч бүртгүүлдэггүй. Зөвшөөрлийн диалог байхгүй, статусын мөрөнд түлхүүрийн дүрс байхгүй, апп тус бүрийн оруулах эсвэл хасах жагсаалт байхгүй, always-on бодлогод оролцохгүй. Тиймээс аппууд анхдагч сүлжээг ашигласар байх бөгөөд туннель зөвхөн shell-ийн илгээснийг зөөнө.

Нөгөө чиглэлд явах нь ч тус болохгүй. Хост namespace руу маршрут түлхэх нь бүгдийг, платформ локал байлгана гэж хүлээсэн урсгалыг ч баривчлах бөгөөд үүнийг апп тус бүрийн хяналтгүйгээр, хэрэглэгч харж эсвэл цуцлах аргагүйгээр хийнэ. chroot демон зөвхөн нэг аппэд урсгал маршрутлах завсрын тохиргоо байхгүй.

Бинарийн нийцэл бол тусдаа хана

Сүлжээний тал сонирхолтой байсан ч гүйцэтгэгдэх файл өөрийн шаардлагатай: CPU архитектур, динамик ачалагч, C номын сан, түүний хүлээж буй цөмийн боломжууд. Android glibc биш bionic ашигладаг бөгөөд десктоп түгээлтэд зориулж бүтээсэн хуучин бинар төхөөрөмж дээр байхгүй номын сангуудыг шаардаж болно.

Номын сангийн файлын нэрийг шинэ хувилбар руу симболын холбоосоор холбох нь ABI нийцэл үүсгэхгүй бөгөөд арван жилийн өмнөх багцаас архивласан криптографын номын сан нь арчилгаатай бүрэлдэхүүн хэсэг биш. Төлөвлөгөө үүнээс хамаарч байвал тэр төлөвлөгөө нь утсан дээр сүлжээний эрхтэйгээр арчилгаагүй код ажиллуулах явдал юм.

Android-ын нөхцөлд баталж, дараа нь цэвэрлэ

Өөрт тань үнэхээр чухал зүйлийг, чухал талаас нь шалга: тодорхой аппыг нээ, тодорхой хувийн зорьсон газарт хүр, аль резолвер хариулсныг батал, дараа нь туннелийг салгаж, баримтжуулсан зан төлөвийг батал. chroot доторх терминалын үр дүн нь зөвхөн тэр терминалын гүйцэтгэлийн нөхцлийн нотолгоо, өөр юу ч биш.

Туршилтын үеэр хост маршрутыг өөрчилсөн бол буцааж, юу өөрчилснөө тэмдэглэ. Дараа нь утасанд always-on VPN тохируулсан эсэхийг шалга, учир нь дүрэм үлдээсэн хуучин туршилт хэдэн сарын дараа платформын гэмтэл мэт харагдаж болно.

Жинхэнэ алсын хандалтын шаардлагад үйлчилгээний дэмжсэн клиент эсвэл батлагдсан гарцын загварыг ашигла. Асуух ёстой асуулт нь root хийсэн суулгагчийг ажиллуулж болох эсэх биш, харин дэмжсэн хэрэгжүүлэлт таны хэрэгтэй аппуудыг зорьсон хилээр зөөж, төхөөрөмж дээр эзэнгүй эрхтэй өөрчлөлт үлдээхгүй эсэх юм.

Холбоотой нийтлэлүүд