Una aplicació Linux corrent fa servir la VPN sense tocar TUN

Un navegador que fa servir una VPN de Linux ja establerta no obre /dev/net/tun. Obre un socket, i el nucli decideix per quina interfície surten els paquets d’aquest socket. El procés que ha creat el túnel fa una feina diferent de la del procés el trànsit del qual transporta. Mantenir aquests dos papers separats respon la majoria de preguntes sobre permisos abans que es facin.

Seguiu un paquet des del socket fins al túnel

Una aplicació corrent crida connect o send, i el nucli busca una ruta per a la destinació. Si la ruta triada apunta a la interfície del túnel, el paquet es posa a la cua del dispositiu que llegeix el dimoni de la VPN. El dimoni el xifra i l’envia per la interfície física. Cada fletxa d’aquesta descripció és un lloc on es pot respondre una pregunta sobre permisos.

Res d’aquest camí no exigeix que l’aplicació sàpiga res del dispositiu. El dimoni té el descriptor de fitxer i fa les operacions d’interfície, mentre que l’aplicació només veu una API de xarxa normal.

Dibuixeu les dues meitats un cop, i les preguntes sobre permisos es col·loquen més fàcilment. La meitat superior és el món de les aplicacions, i la inferior pertany al dimoni.

Decidiu qui necessita el dispositiu i qui no

Crear una interfície TUN o connectar-s’hi requereix accés al dispositiu més el permís per configurar-lo, i per això un servei VPN admès comença amb autoritat d’administració de xarxa o fa servir un ajudant privilegiat. Aquest requisit pertany al dimoni. No diu res sobre el navegador, el client de base de dades o l’eina de transferència de fitxers. Un servei que necessita el permís el necessita per al seu propi pas de configuració, no per als seus clients.

Un cop la ruta i la política són al lloc, un procés corrent fa servir el camí resultant amb les seves crides de socket habituals. No necessita el node del dispositiu, ni necessita root.

Canviar els permisos del dispositiu no és una manera de concedir accés a una destinació a una aplicació. Només mou la frontera del dispositiu a un altre lloc.

Comproveu en quin espai de noms s’executa realment l’aplicació

Un contenidor, o un segon espai de noms de xarxa, dona als seus processos un conjunt d’interfícies i una taula de rutes a part. Un túnel a l’amfitrió no hi apareix automàticament, i cap canvi de permisos del dispositiu ho altera. L’aplicació simplement encaminarà a través del que ofereixi aquell espai. Per això una imatge de contenidor no pot heretar un túnel de l’amfitrió per accident.

Comproveu-ho amb ip netns list i ip -n NAME route, o inspeccionant l’enllaç de l’espai de noms del procés. La resposta normalment es veu en una sola ordre.

Dos usuaris al mateix amfitrió també poden rebre camins diferents per política. És una decisió de xarxa, no una prova de propietat del dispositiu.

Separeu les capacitats de la política de xarxa

Algunes eines necessiten més que un socket. Capturar paquets necessita un socket cru, i canviar rutes necessita autoritat d’administració. Són operacions separades amb concessions separades, i concedir-ne una no s’ha de llegir com un requisit general per fer servir la VPN.

Un programa que implementa el seu propi túnel és un tercer cas. Obre TUN de debò perquè assumeix el paper del dimoni, i per això necessita els privilegis del dimoni.

Anomeneu l’operació abans d’anomenar el privilegi. Normalment és més fàcil separar-los del que sembla.

Verifiqueu la separació amb dos comptes

Connecteu el túnel com a servei, després executeu l’aplicació com a usuari corrent i confirmeu que arriba al recurs privat. Comproveu ip route get per a la destinació des de l’intèrpret d’ordres d’aquell usuari per veure quina interfície s’ha triat. Si la ruta és correcta i la connexió encara falla, el problema és de política, no de privilegi.

El disseny que en resulta és el mínim privilegi amb una frontera explícita: un component posseeix la configuració i els recursos del túnel, les càrregues de treball mantenen els seus comptes normals, i la política de xarxa decideix què pot passar. Executar-ho tot com a root col·lapsa aquests papers sense explicar res.