Просматривал тут новости и зацепился за стенания LOS по поводу eBPF и того что он конкретно так осложняет поддержку устаревших девайсов.

Хрен с ней с поддержкой. Придвигаемся ближе, мои параноидальные друзья. Я расскажу вам кое-что про eBPF, и спать после этого вы будете еще хуже.

Что это вообще? Это очень сложная тема, но я постараюсь объяснить максимально просто, почему Google и вендоры на колу вертели все ваши файерволы.
eBPF (extended Berkeley Packet Filter) в Android — это встроенный механизм ядра Linux, позволяющий выполнять небольшие программы прямо внутри ядра без его модификации. Из всех возможностей расскажу только об одной - контроль трафика.

Основные моменты:

prog (eBPF program) — выполняемый код, программа в ядре

map (eBPF map) — ключ-значение в ядре, доступное eBPF-программам и userspace. Хранит политики: uid_owner_map, uid_permission_map и тд.

Как это работает?

Приложение вызывает connect (хочет выйти в сеть) =>
ядро создаёт сокет, определяется UID процесса
=>
prog читает uid_owner_map / uid_permission_map по ключу = UID и смотрит флаги значения (value): allow, deny, bypass, vpn_bypass, data_saver_allowed и т.п., которые в этих картах прописаны
=>
Если значение в картах говорит ALLOW_BYPASS / VPN_BYPASS, prog может:
немедленно вернуть разрешение (BPF_OK / allow) и не передавать пакет дальше в netfilter.

Чем грозит?

Невидимый трафик: скрытые телеметрические каналы от системных UID, незаметные в iptables, утечка конфиденциальных данных через приложения с UID имеющие разрешающий флаг в картах. Это уже не телеметрия, это все до чего такие приложения могут дотянуться, используя привилегии и разрешения.
Privileged abuse: vendor/корневые сервисы могут записывать UID в карты и обходить пользовательские политики.

Другими словами, если в этих самых картах Google для своих сервисов (а китайский вендор для любого своего пакета) прописали разрешения на обход, prog такие разрешения выдаст, а вашего файервола это не касается.

Решение prog + содержимое maps определяют, дойдёт ли пакет до iptables вообще. И вы можете хоть сто раз что угодно запрещать в правилах (iptables, root) или блокировать безрутовым (на основе vpn) методом, но если BPF prog уже дал ALLOW - все это не имеет значения.

Ну и раз сам поднял тему, сам частично и закрою на предстоящем курсе. Частично - потому что, как и сказал, это очень сложная тема.
Пример, с которым можно бороться из userspace (не влезая в ядро):

1. Vendor пишет init script, скрипт использует connectivity ... true com.vendor.analytics
2. netd, в результате исполнения скрипта выставляет в uid_owner_map запись для UID этого пакета с флагом 0x08.
3. Любые попытки пользователя поставить iptables DROP для UID не помогут — трафик пойдёт в обход. А вы, весь такой рутованный и в себе уверенный, машете ушами вслед уходящим с устройства данным.

В общем, настроим второй слой блокировки трафика для системных и предустановленных приложений, чтобы минимизировать риски утечек. Если знакомы с фирменным файерволом Datura от проекта Calyx - это будет примерно оно, но круче и для любого устройства.