O teu comando VPN execútase sen privilexios; o servizo non

O comando VPN execútase como o teu usuario, non aparece ningún contrasinal e o túnel érguese. Esa secuencia parece unha operación sen privilexios, e normalmente non o é. Un servizo aparte realiza os cambios de rede, e a pregunta interesante é que fará ese servizo por un chamante que non verificou. Contar peticións de contrasinal non che di nada sobre esa fronteira.

A interface, o mecanismo e a comprobación

A interface acepta peticións: conectar, desconectar, escoller un perfil. O mecanismo posúe as operacións de rede: crear interfaces, cambiar rutas, aplicar filtros. A comprobación de autorización decide se este chamante pode pedir esta acción. Eses tres poden repartirse entre un binario, un axudante e un servizo do sistema, e o usuario só ve o primeiro.

Os papeis poden vivir nun só binario, en dous procesos ou nun cliente e un servizo do sistema, e o comando que ve o usuario raramente revela cal. Unha icona na bandexa e un demonio do sistema poden parecer unha soa aplicación mentres se executan cunha autoridade moi distinta. O privilexio no momento de instalar e o privilexio no momento da petición tamén son cousas distintas. Un instalador que se executou como root pode deixar un servizo escoitando peticións posteriores, moito despois de que o xestor de paquetes rematase. Ese servizo, non o comando que escribiches, é o que ten a autoridade.

Delegar é o deseño normal

Delegar o traballo de rede con privilexios nun servizo é a arquitectura razoable. Mantén as aplicacións correntes sen privilexios e centraliza as operacións que necesitan coidado. O deseño só compensa cando o servizo tamén comproba quen pregunta e para que. Sen esa comprobación só é unha porta máis ancha.

NetworkManager é o exemplo concreto en Linux. A súa guía de configuración explica como PolicyKit autoriza as peticións que non son de root na configuración predeterminada. Iso mostra autorización delegada nun produto real. Non demostra que todos os clientes comerciais usen NetworkManager, nin describe a ruta do socket nin a política de ningún provedor concreto.

O patrón é delegación cunha política detrás. O exemplo é unha implementación dese patrón, non unha universal.

Le a fronteira, non a petición

Busca o servizo, o dono da súa configuración e a interface local que usa o frontal. Despois pregunta que usuarios poden pedir que operacións. Poder subir e baixar un perfil gardado non é o mesmo permiso que cargar unha configuración que o operador nunca revisou. A diferenza é toda a cuestión de seguridade.

Comeza polo xestor de servizos e pola visión que o cliente ten dos seus propios permisos. Os comandos de abaixo mostran se o demonio se executa, que pode pedirlle o chamante e que expón o demonio baixo o seu directorio de execución.

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

Pregunta tamén a que afecta a operación. Un elemento de menú que parece persoal pode cambiar as rutas e o DNS de toda a máquina, o que significa que pode perturbar as sesións doutros usuarios. O radio de impacto pertence á mesma revisión que o permiso, e normalmente decide se o servizo precisa un papel máis estreito.

Corrixe os permisos da forma admitida

Facer que un socket de control protexido sexa escribible por todos, ou engadir unha conta a un grupo administrativo amplo, elimina un erro de permiso e crea un maior. O erro era o único que che dicía que esa fronteira existía. Usa o proceso documentado de pertenza ou autorización, incluída a renovación de sesión que require. A pertenza a un grupo a miúdo só se aplica a sesións de inicio novas, e por iso un cambio pode parecer que non fai nada ata o seguinte inicio de sesión.

Se o produto expón un papel máis estreito para a operación, prefíreo a unha concesión xeral. Escribe o papel escollido e o seu dono xunto ao nome do servizo.

Como se ve unha boa separación

As aplicacións correntes quedan sen privilexios, o servizo só fai a preparación para a que foi deseñado, e cada chamante compróbase contra unha política que alguén posúe. Eso é un deseño defendible. Tamén é auditable, porque a política ten un nome asociado. Calquera cousa maior merece unha excepción escrita en lugar dun cambio silencioso de permisos.

O modo de fallo é un servizo que executa calquera petición de calquera usuario local porque a interface é cómoda. Desde o lado do usuario parece idéntico, e leva unha autoridade moito maior. Proba unha petición rexeitada, non só a exitosa. Un rexeitamento que vén da política é a proba de que a política existe.