A través de G+ me he enterado del trabajo de Hans Goede para hacer que el servidor X Window/X.Org se pueda ejecutar sin privilegios de root. La importancia de este paso deriva de que cualquier programa que se ejecuta con estos privilegios es un caramelo para los posibles atacantes; ya que aprovechando algún agujero de seguridad del programa podrían ser capaces de ejecutar código propio como root, ganando así privilegios en el sistema.
Arquitectura de X.Org
El sistema X Window es —desde sus orígenes en 1984— un sistema con arquitectura cliente/servidor. Es decir, las aplicaciones con interfaz gráfica son clientes que solicitan operaciones al servidor X, el único que realmente tiene acceso a los recursos del hardware. La cuestión es que para que el sistema operativo le proporcione acceso a los dispositivos correspondientes, el servidor X tiene que ejecutarse como root. Eso significa que los desarrolladores deben tener especial cuidado en la interacción con los clientes, ya que alguno podría ser un atacante que de forma intencionada esté buscando algún bug en el servidor que permita ejecutar código de forma arbitraria.
La nueva gestión de sesiones
Por fortuna, el arranque del sistema y la gestión de sesiones está cambiando muy rápidamente gracias al desarrollo de Systemd impulsado por Red Hat. Este programa está llamado a convertirse en el sustituto de SysVinit —un init que toma las características del init original de los sistemas Unix System V— que hasta hace bien poco seguían utilizando la mayor parte de las distribuciones de Linux. El nuevo Systemd se encarga tanto de realizar de forma ordenada el inicio de sistema como de centralizar las tareas relativas a la gestión de las sesiones. Para ello ha ido asumiendo funcionalidades que hasta el momento estaban dispersas en diferentes demonios. Incluso se ha iniciado un camino que llevará a que el núcleo delegue en él ciertas funcionalidades actuales, lo que ha provocado encendidos debates en la comunidad.
Por ejemplo, Systemd ha introducido el concepto de puesto (seat) como un objeto virtual que describe una interfaz interactiva física del sistema. Por lo general, estamos hablando de una combinación de monitor, teclado y ratón, aunque también es posible incorporar otros dispositivos. En cualquier caso, la clave de este concepto es que los usuarios interactúan con el sistema a través de uno de esos puestos. Además, en un mismo puesto se puedan iniciar múltiples sesiones, permitiendo que el usuario se autentique varias veces para tener diferentes sesiones abiertas al mismo tiempo, aunque en cada instante solo una de dichas sesiones sea la activa. Esta distinción es importante porque únicamente los procesos en la sesión activa tendrán acceso a los dispositivos que configuran el puesto. Es decir, que solo ellos recibirán la entrada del usuario —por ejemplo, a través del teclado o el ratón— y podrán mostrarle una salida —por ejemplo, por medio del monitor —.
El demonio Systemd-logind
La mayor parte de toda esta magia la hace systemd-logind, uno de los múltiples demonios que componen Systemd. Básicamente, gestiona los puestos, estableciendo a cuál pertenece cada dispositivo y controlando el acceso a los mismos, ya que cada uno de estos dispositivos solo puede pertenecer a un puesto. De igual manera permite gestionar las sesiones de los usuarios, siguiendo la pista de la sesión activa y controlando el acceso a los dispositivos por parte de los procesos en las distintas sesiones.
Para hacer todo esto posible, realmente systemd-logind es el único proceso con acceso a los dispositivos. Cuando el controlador de sesión quiere ganar acceso a alguno de los dispositivos del puesto, debe solicitarlo a systemd-logind, que simplemente le proporcionará un descriptor de archivos para ese dispositivo concreto. Lo interesante es que como es systemd-logind el encargado de abrir el dispositivo, el controlador de sesión no tiene que pertenecer a ningún usuario o grupo en especial. Es así como un servidor X en un sistema con Systemd puede ganar acceso a los dispositivos de E/S sin necesidad de ejecutarse con privilegios de root.
Además, a través de la interfaz cgroups del núcleo, systemd-logind puede seguir la pista de los procesos y sus hijos para saber a qué sesión pertenece cada uno. Esta interfaz también permite priorizar y establecer límites en los recursos que utilizan los diferentes procesos del sistema —CPU, memoria, E/S, etc.—. Así que systemd-logind la utiliza para enmudecer los dispositivos de un puesto de cara a los procesos de una sesión cuándo esta deja de ser la sesión activa; incluso aunque parezca que tienen acceso a dichos dispositivos a través de los descriptores de archivo correspondientes.
Más detalles
Todo este asunto de las nuevas posibilidades que ofrece Systemd resulta apasionante, pero no es sencillo encontrar artículos donde las cosas estén bien explicadas. En ese sentido, hay reconocer la labor de David Herrmann, que cuenta perfectamente lo relacionado con la nueva gestión de sesiones en tres artículos muy interesantes:
