La vostra ordre VPN s’executa sense privilegis; el servei no

L’ordre VPN s’executa com el vostre usuari, no apareix cap contrasenya i el túnel s’aixeca. Aquesta seqüència sembla una operació sense privilegis, i normalment no ho és. Un servei separat fa els canvis de xarxa, i la pregunta interessant és què farà aquest servei per a un sol·licitant que no ha verificat. Comptar peticions de contrasenya no us diu res sobre aquesta frontera.

La interfície, el mecanisme i la comprovació

La interfície accepta peticions: connecta, desconnecta, tria un perfil. El mecanisme posseeix les operacions de xarxa: crear interfícies, canviar rutes, aplicar filtres. La comprovació d’autorització decideix si aquest sol·licitant pot demanar aquesta acció. Aquests tres poden repartir-se entre un binari, un auxiliar i un servei del sistema, i l’usuari només veu el primer.

Els papers poden viure en un sol binari, en dos processos o en un client i un servei del sistema, i l’ordre que veu l’usuari poques vegades revela quin és. Una icona de la safata i un dimoni del sistema poden semblar una sola aplicació mentre s’executen amb autoritat molt diferent. El privilegi en el moment d’instal·lar i el privilegi en el moment de la petició també són coses diferents. Un instal·lador que es va executar com a root pot deixar un servei escoltant peticions posteriors, molt després que el gestor de paquets hagi acabat. Aquest servei, no l’ordre que heu escrit, és qui té l’autoritat.

Delegar és el disseny normal

Delegar la feina de xarxa amb privilegis en un servei és l’arquitectura raonable. Manté les aplicacions corrents sense privilegis i centralitza les operacions que necessiten cura. El disseny només compensa quan el servei també comprova qui pregunta i per a què. Sense aquesta comprovació només és una porta més ampla.

NetworkManager és l’exemple concret a Linux. La seva guia de configuració explica com PolicyKit autoritza les peticions que no són de root en la configuració predeterminada. Això mostra autorització delegada en un producte real. No demostra que tots els clients comercials facin servir NetworkManager, ni descriu el camí del sòcol ni la política de cap proveïdor concret.

El patró és delegació amb una política al darrere. L’exemple és una implementació d’aquest patró, no una de universal.

Llegiu la frontera, no la petició

Cerqueu el servei, l’amo de la seva configuració i la interfície local que fa servir el frontal. Després pregunteu quins usuaris poden demanar quines operacions. Poder pujar i baixar un perfil desat no és el mateix permís que carregar una configuració que l’operador mai no ha revisat. La diferència és tota la qüestió de seguretat.

Comenceu pel gestor de serveis i per la visió que el client té dels seus permisos. Les ordres de sota mostren si el dimoni s’executa, què pot demanar-li el sol·licitant i què exposa el dimoni sota el seu directori d’execució.

systemctl status NetworkManager
nmcli general permissions
ls -l /run/NetworkManager

Pregunteu també a què afecta l’operació. Un element de menú que sembla personal pot canviar les rutes i el DNS de tota la màquina, cosa que vol dir que pot destorbar les sessions d’altres usuaris. El radi d’impacte pertany a la mateixa revisió que el permís, i normalment decideix si el servei necessita un paper més estret.

Repareu els permisos de la manera admesa

Fer que un sòcol de control protegit sigui escriptible per tothom, o afegir un compte a un grup administratiu ampli, elimina un error de permís i en crea un de més gran. L’error era l’única cosa que us deia que aquella frontera existia. Feu servir el procés documentat de pertinença o autorització, inclosa la renovació de sessió que requereix. La pertinença a un grup sovint només s’aplica a sessions d’inici noves, i per això un canvi pot semblar que no fa res fins al proper inici de sessió.

Si el producte exposa un paper més estret per a l’operació, preferiu-lo a una concessió general. Escriviu el paper triat i el seu amo al costat del nom del servei.

Com es veu una bona separació

Les aplicacions corrents es queden sense privilegis, el servei només fa la preparació per a la qual va ser dissenyat, i cada sol·licitant es comprova contra una política que algú posseeix. És un disseny defensable. També és auditable, perquè la política té un nom associat. Qualsevol cosa més gran mereix una excepció escrita en lloc d’un canvi silenciós de permisos.

El mode de fallada és un servei que executa qualsevol petició de qualsevol usuari local perquè la interfície és còmoda. Des del costat de l’usuari sembla idèntic, i porta una autoritat molt més gran. Proveu una petició rebutjada, no només la que té èxit. Un rebuig que ve de la política és la prova que la política existeix.