En general, debe no reenviar la visualización de X11 desde entornos no confiables a su entorno local. X11 es una tecnología antigua que no fue concebida teniendo en cuenta la seguridad desde el principio, al contrario, fue diseñada para permitir que cada aplicación se comunique entre sí.
¿Significa " comunicarse "? Como dijiste, podría agarrarte las pulsaciones de teclado. También podría tomar capturas de pantalla. Podría interactuar con otras ventanas, inyectar pulsaciones de teclas, movimientos del mouse, etc., etc., etc. Bueno, supongo que lo consiguió: permitir que un sistema no confiable para exportar la pantalla X11 a su servidor local es un poco como pasar su pantalla. Teclado y mouse para este sistema no confiable. Tiene razón en el sentido de que es posible que no pueda acceder directamente a sus archivos locales, pero será casi equivalente.
Sin embargo, se ha realizado cierto trabajo para mitigar el riesgo. De hecho, X11 incluye una distinción entre clientes confiables y no confiables. Un cliente no confiable debe estar confinado en un subconjunto de acciones diseñadas para prevenir la mayoría de las acciones infames descritas anteriormente.
SSH integra este modo, incluso si alguna distribución de Linux lo deshabilita y considera que todos los clientes X11 son confiables para la conveniencia del usuario final (!). Es posible que desee verificar los parámetros ForwardX11 y ForwardX11Trusted en sus archivos de configuración de cliente SSH:
-
ForwardX11 dice si X11 está habilitado de forma predeterminada cuando establece una conexión SSH (debe usar el parámetro de línea de comando -x (minúscula 'x') para deshabilitarlo a petición),
-
ForwardX11Trusted dice si, cuando habilita el reenvío X11, el cliente se considerará automáticamente como confiable. Le recomiendo encarecidamente que ponga este a no .
Cuando ForwardX11Trusted se establece en no , el comando ssh le ofrecerá seleccionar el nivel de confianza para su sesión:
- El parámetro de línea de comando
-X considerará al cliente como no seguro, esta es la forma recomendada de hacerlo.
- El parámetro de línea de comando
-Y considerará al cliente como seguro, esto solo es necesario para casos de uso muy específicos y se debe usar con cuidado, ya que debe considerar que las aplicaciones remotas tendrán acceso completo a su sistema. .
Sin embargo, como mencioné anteriormente, no debe confiar en la sensación de seguridad que proporciona el modo "seguro" -X para exportar la visualización desde un entorno no confiable a su servidor X local. Pero esto debería ser lo suficientemente sensato si considera este entorno Docker como un entorno confiable.
El aislamiento de la aplicación GUI es un dominio que se está estudiando en la actualidad. Si bien todos los demás sistemas Linux han pasado por grandes medidas de endurecimiento hasta ahora, tengo la impresión de que X casi siempre se dejó en suspenso, demasiado grande y complejo para evolucionar realmente y adaptarse a las necesidades actuales, pero dejando ahora una debilidad desagradable. / p>
Las plataformas seguras como Qubes OS , que se basa precisamente en un conjunto de Xen VM aislado, exportan X a un dominio Dom0 a través del dolor de desarrollar su propio protocolo X "proxy inverso" entre los clientes X y el servidor para garantizar la seguridad del servidor. No conozco ningún equivalente independiente de dicha tecnología, pero puede encontrar ideas interesantes aquí: El mejor método para sandbox X aplicaciones en Ubuntu . El servidor X está abandonando sus últimos tiempos y debería ser reemplazado por una alternativa más moderna y segura tan pronto como tales alternativas estén listas (consulte Wayland y Mir por ejemplo), pero hasta entonces, al menos, consulte a quién ¡Confía tu escritorio!