Un gestor de pantalla con separación de privilegios.

• Una frontera de privilegios que un error de la sesión no pueda atravesar hacia atrás
• Credenciales que no sobrevivan al momento en que se usan
• Ningún camino por el que una interfaz comprometida pueda iniciar una sesión
• Recuperación tras un fallo que no dependa de que la pantalla siga funcionando

Presentadas como decisiones y no como funcionalidades, porque cada una costó algo real. Esto es hacia qué lado se inclinó esta y lo que permitió.

1. 01

   Tres procesos, no uno

   Un demonio root inicia un proceso de trabajo por cada inicio de sesión, que es dueño de todo el ciclo de vida de la autenticación, y ese proceso crea con fork al hijo de sesión, que renuncia de forma irreversible a los privilegios antes de ejecutar nada del usuario. El proceso que tiene el descriptor de autenticación nunca se convierte en el usuario, y el proceso que se convierte en el usuario nunca lo tiene. Un diseño de un solo proceso es mucho más simple y hace que cualquier error en él sea un error de root.

2. 02

   La interfaz no tiene privilegios y es reemplazable

   La interfaz de bienvenida se ejecuta con su propia cuenta sin privilegios y habla con el demonio mediante un protocolo versionado sobre un socket unix, con una trama prefijada por su longitud, un tamaño máximo y una negociación de versión. No puede iniciar una sesión sin autenticar ni pasar un comando libre a través de la frontera: solo puede nombrar una sesión que el propio sistema haya descubierto. Publicar ese protocolo con una licencia permisiva es lo que permite a otra persona escribir una interfaz distinta sin heredar la licencia del demonio.

3. 03

   Un solo hilo y bloqueante, a propósito

   Sin entorno de ejecución asíncrono, sin grupo de hilos. Un proceso que hace fork no debe tener otros hilos activos cuando lo hace, y todo el modelo depende de hacer el fork correctamente en el momento exacto en que cambian los privilegios. Renunciar aquí a la concurrencia compra la única garantía de la que el modelo de seguridad no puede prescindir.

4. 04

   Una pantalla negra se trata como un defecto, no como un accidente

   El estado del terminal se restaura desde manejadores de señales, usando solo llamadas que es seguro hacer desde uno, en lugar de desde el código de limpieza habitual que un fallo brusco nunca alcanza, con un gancho de servicio y una comprobación en el siguiente arranque como respaldo. Las consolas de texto siguen disponibles como camino de vuelta. Es la vía de recuperación para el caso en que lo que ha fallado es justo lo que habrías usado para diagnosticarlo.

La alternativa

Un solo proceso, ejecutándose como root, que hace las tres cosas. Es la forma de la herramienta a la que este sustituye y es realmente más simple: ningún protocolo que definir, ninguna negociación de versión, ninguna serialización, ningún fallo parcial entre componentes y un ciclo de vida de sesión que se puede leer de arriba abajo en un solo archivo.

Lo que costó

Una gran cantidad de complejidad, de forma permanente, para un programa cuyo único trabajo es mostrar un cuadro de contraseña. Un formato de transmisión con negociación de versión, un socket cuyo interlocutor hay que verificar, forks en los momentos exactos y un conjunto de modos de fallo que solo existen porque las piezas están separadas. Todo ello es código que puede estar mal, en un programa en el que equivocarse sale caro.

Por qué la contrapartida se sostiene

En un solo proceso, un error en la parte que analiza el teclado es un error en la parte que tiene root, porque son el mismo espacio de direcciones. No es un perfil de riesgo hipotético, es una identidad. La separación convierte el peor caso de un compromiso total de la máquina en una interfaz caída que de todos modos no habría podido iniciar una sesión. La complejidad es un precio que se puede pagar una vez y revisar; el diseño de un solo proceso cobra su precio una sola vez y nunca lo devuelve.

• ArtículoCómo elegir un sistema de init, y por qué 0dyssey usa runitEl sistema para el que se construye este: qué arranca una máquina, cómo juzgar un sistema de init frente a otro y por qué el servicio que supervisa un inicio de sesión tiene la forma que tiene.
• ArtículoModelos de paquetes, y la deuda que aplazas al congelarCómo llega el software a una máquina y pasa de un estado conocido a otro, que es por donde tiene que instalarse y actualizarse un gestor de pantalla sin dejar a nadie ante una pantalla negra.
• Producto0dyssey, el sistema operativoEl sistema operativo del que este es la capa de inicio de sesión: la composición nombrada, las decisiones tomadas y lo que todavía no existe.