Básicamente, cualquier proceso que pueda conectarse con éxito a un servidor X11 tiene acceso completo a lo que ocurre en ese servidor. El modelo de seguridad X11 asume que los atacantes son rechazados en el momento de la conexión. El sistema de seguridad habitual es que los clientes deben enviar una "cookie mágica" específica como parte de su primer mensaje, la cookie es un blob aleatorio que se crea cuando se inicia el servidor o como parte del procedimiento de inicio de sesión; la cookie también se copia en una ubicación a la que solo pueden acceder las aplicaciones "permitidas". En sistemas similares a Unix, la cookie está tradicionalmente en el archivo $HOME/.Xauthority , pero puede estar en otra parte (en mi sistema Linux reciente, parece estar en algún lugar en un subdirectorio de /var/run/gdm/ ), el punto es que el archivo Es legible solo para un solo usuario de Unix. Al reenviar las conexiones X11, SSH usa el comando xauth para transportar de manera transparente la cookie actual desde el cliente al servidor (para que las aplicaciones iniciadas en el host remoto puedan enviar la cookie cuando se conecten).
Por lo tanto, hay aislamiento con X11, pero es entre usuarios (según lo controla el sistema operativo), no entre aplicaciones ejecutadas en nombre del mismo usuario.
En épocas anteriores, las cookies mágicas no eran muy comunes, por lo que algunas aplicaciones (notablemente xterm) incluían contramedidas como rechazar eventos sintéticos (es decir, eventos resultantes de un XSendEvent() llamado, en oposición a eventos provenientes del hardware). Tales medidas fueron antes de muchas de las extensiones que han crecido en el protocolo X11 a lo largo de los años, como XTest, que las hace en su mayoría obsoletas e inútiles.
Qubes es un sistema operativo que se basa en Xen para aislar algunas aplicaciones entre sí, cada VM tiene su propio Pantalla exclusiva, sin interacciones posibles con los servidores X11 de otras máquinas virtuales. Tengo problemas para leer "Beta 1" y "seguro" en la misma oración, aunque ...
Para la parte X11, el mismo tipo de aislamiento ha existido durante muchos años como Xnest (con un sucesor actualizado llamado Xephyr ): ejecuta la aplicación potencialmente errónea con un ID de usuario específico y aislado, y deja que se conecte solo a una instancia de Xephyr que a su vez se conecta al servidor X11 principal como si fuera una aplicación simple. Para evadir ese aislamiento, la aplicación debe secuestrar Xephyr (por ejemplo, a través de un desbordamiento de búfer). La solución de Qubes es más completa porque reemplaza el aislamiento básico de Unix ("ID de usuario distinto") con una capa de VM mucho más masiva.
Wayland no parece anunciar nada sobre el aislamiento, por lo que es una apuesta segura que no hace nada al respecto. Además, Wayland intenta dar acceso de hardware casi directo a las aplicaciones cuando es posible, por lo que cualquier modelo de seguridad en esa situación sería relativo a cómo el hardware 3D no documentado y el controlador de código cerrado colaboran para evitar una transferencia DMA mal colocada para obtener derechos adicionales. Esto no parece ser la mejor manera de construir seguridad.