Tu comando VPN se ejecuta sin privilegios; el servicio no

El comando VPN se ejecuta como tu usuario, no aparece ninguna contraseña y el túnel se levanta. Esa secuencia parece una operación sin privilegios, y normalmente no lo es. Un servicio aparte realiza los cambios de red, y la pregunta interesante es qué hará ese servicio por un llamante que no ha verificado. Contar peticiones de contraseña no te dice nada sobre esa frontera.

La interfaz, el mecanismo y la comprobación

La interfaz acepta peticiones: conectar, desconectar, elegir un perfil. El mecanismo posee las operaciones de red: crear interfaces, cambiar rutas, aplicar filtros. La comprobación de autorización decide si este llamante puede pedir esta acción. Esos tres pueden repartirse entre un binario, un auxiliar y un servicio del sistema, y el usuario solo ve el primero.

Los papeles pueden vivir en un solo binario, en dos procesos o en un cliente y un servicio del sistema, y el comando que ve el usuario rara vez revela cuál. Un icono en la bandeja y un demonio del sistema pueden parecer una sola aplicación mientras se ejecutan con una autoridad muy distinta. El privilegio en el momento de instalar y el privilegio en el momento de la petición también son cosas distintas. Un instalador que se ejecutó como root puede dejar un servicio escuchando peticiones posteriores, mucho después de que el gestor de paquetes haya terminado. Ese servicio, no el comando que escribiste, es el que tiene la autoridad.

Delegar es el diseño normal

Delegar el trabajo de red con privilegios en un servicio es la arquitectura razonable. Mantiene las aplicaciones corrientes sin privilegios y centraliza las operaciones que necesitan cuidado. El diseño solo compensa cuando el servicio también comprueba quién pregunta y para qué. Sin esa comprobación solo es una puerta más ancha.

NetworkManager es el ejemplo concreto en Linux. Su guía de configuración explica cómo PolicyKit autoriza las peticiones que no son de root en la configuración predeterminada. Eso muestra autorización delegada en un producto real. No demuestra que todos los clientes comerciales usen NetworkManager, ni describe la ruta del socket ni la política de ningún proveedor concreto.

El patrón es delegación con una política detrás. El ejemplo es una implementación de ese patrón, no una universal.

Lee la frontera, no la petición

Busca el servicio, el dueño de su configuración y la interfaz local que usa el frontal. Luego pregunta qué usuarios pueden pedir qué operaciones. Poder subir y bajar un perfil guardado no es el mismo permiso que cargar una configuración que el operador nunca revisó. La diferencia es toda la cuestión de seguridad.

Empieza por el gestor de servicios y por la visión que el cliente tiene de sus propios permisos. Los comandos de abajo muestran si el demonio se ejecuta, qué puede pedirle el llamante y qué expone el demonio bajo su directorio de ejecución.

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

Pregunta también a qué afecta la operación. Un elemento de menú que parece personal puede cambiar las rutas y el DNS de toda la máquina, lo que significa que puede perturbar las sesiones de otros usuarios. El radio de impacto pertenece a la misma revisión que el permiso, y normalmente decide si el servicio necesita un papel más estrecho.

Corrige los permisos de la forma admitida

Hacer que un socket de control protegido sea escribible por todos, o añadir una cuenta a un grupo administrativo amplio, elimina un error de permiso y crea uno mayor. El error era lo único que te decía que esa frontera existía. Usa el proceso documentado de pertenencia o autorización, incluida la renovación de sesión que exige. La pertenencia a un grupo a menudo solo se aplica a sesiones de inicio nuevas, y por eso un cambio puede parecer que no hace nada hasta el siguiente inicio de sesión.

Si el producto expone un papel más estrecho para la operación, prefíerelo a una concesión general. Escribe el papel elegido y su dueño junto al nombre del servicio.

Cómo se ve una buena separación

Las aplicaciones corrientes se quedan sin privilegios, el servicio solo hace la preparación para la que fue diseñado, y cada llamante se comprueba contra una política que alguien posee. Eso es un diseño defendible. También es auditable, porque la política tiene un nombre asociado. Cualquier cosa mayor merece una excepción escrita en lugar de un cambio silencioso de permisos.

El modo de fallo es un servicio que ejecuta cualquier petición de cualquier usuario local porque la interfaz es cómoda. Desde el lado del usuario parece idéntico, y lleva una autoridad mucho mayor. Prueba una petición rechazada, no solo la exitosa. Un rechazo que viene de la política es la prueba de que la política existe.