No es un "defecto de seguridad" en el sentido de que algo está roto o que los parpadeos indican un error o un ataque. Más bien, es un problema con la pila de gráficos subyacentes de Linux y la falta de semántica para los clientes de escritorio con privilegios.
Para evitar que esto suceda, lo más probable es que el parpadeo se deba a una mala interacción entre los controladores de GPU y el Shell de GNOME o cualquier otro compositor de Wayland incorporado en GDM. No tiene ninguna relación con la seguridad.
Ahora veamos por qué ves tu escritorio debajo de la pantalla de bloqueo ...
Situación histórica
X11, el protocolo y el servidor de pila de gráficos utilizados en todos los sistemas Linux, no fue diseñado con la capacidad de aislar ventanas entre sí de manera efectiva, y tanto el protocolo X11 original como una serie de extensiones lo hacen posible y fácil aplicaciones para falsificar los diálogos de la IU de autenticación y robar información de otros clientes.
Tradicionalmente, por lo tanto, las pantallas de bloqueo son simplemente programas que:
- generar pantalla completa, encima de todas las demás ventanas (mediante el uso de opciones específicas de WM en su ventana
- tome todas las entradas (en la práctica, pueden ir tan lejos como vinculando cada combinación de teclas en su teclado para asegurarse de que todos los eventos de entrada se envíen a ellos primero)
En esta etapa, podría abrir un TTY y matar el proceso de la zona de usuario que toma la entrada y cubre la pantalla, y probablemente podría intentar abrir otra ventana (pero no pudo recibir los eventos del teclado). También tenga en cuenta que en el teclado X11 los eventos no se distribuyen correctamente cuando hay un menú abierto. Por lo tanto, si puede generar una aplicación y hacer que abra un menú, es posible que pueda evitar que la pantalla de bloqueo reciba información. Hasta ahora todo bien.
El defecto de seguridad más obvio que viene a la mente es que los servidores / compositores de pila de gráficos no tienen forma de identificar si una ventana específica es una pantalla de bloqueo, y si una ventana específica pretende ser una pantalla de bloqueo pero no lo es. Esto también es un problema en OSX y Windows 8, y Lo he discutido antes en XDC . La única protección adecuada contra las falsificaciones de la pantalla de bloqueo es utilizar la autenticación de 2 factores.
Las formas de protección menos aceptables son secuencias de atención seguras (Ctrl + Alt + Supr) de Windows o capacidades especiales solo para la pantalla de bloqueo que son difíciles de falsificar y fáciles de identificar (indicador visible pero fuera de la pantalla, pantalla completa solo para la pantalla de bloqueo, etc. ). En otras palabras, necesita una ruta de confianza entre el usuario y el sistema operativo que activa la pantalla de bloqueo, y también necesita la pantalla de bloqueo para autenticarse ante el usuario.
¿GNOME-Wayland cambió algo?
Lamentablemente no tanto como debería. Ahora tiene garantías mucho más sólidas, gracias al protocolo de Wayland para el envío de entradas) de que a su pantalla de bloqueo legítima no se le robará la entrada. Pero no tiene manera de determinar si es su pantalla de bloqueo real lo que está frente a usted.
¿Por qué? Hubo un fuerte incentivo para que GNOME sea el primero en "implementar" Wayland, por lo que simplemente copian / pegan algunos de los protocolos X11 pobres e inseguros (en particular, selecciones, métodos para acceder a hardware especial, para vincular accesos directos globales y acceder a pantalla completa). Las pantallas de bloqueo son fáciles de falsificar sin los requisitos que he configurado anteriormente, y los desarrolladores de Shell de GNOME no han implementado contramedidas. He discutido este tema en privado con uno de ellos y he llegado a la conclusión de que no están interesados en analizar las defensas de escritorio cruzado a las vulnerabilidades de seguridad de la pila gráfica. Me dijeron que resolverán todos los problemas de seguridad subyacentes con métodos personalizados que serán algo mejores, en algún momento en el futuro.
No hay una agenda establecida para tal trabajo y no hay evidencia de que se llevará a cabo. Los ingenieros de seguridad de Red Hat están ocupados trabajando en la zona de pruebas de arena y aplicaciones relacionadas con Docker, es poco probable que tengan mano de obra para abordar los problemas de seguridad del escritorio en el corto plazo, y ahora que el código se implementa y se utiliza de forma salvaje, es incluso menos probable que alguien querrá cambiar las API de Wayland. Peor aún, es posible que otras DE deseen seguir a GNOME y dejar algunas API sin asegurar por el simple hecho de no modificar los kits de herramientas o las aplicaciones de escritorio nuevamente.
La última vez que hablé con ellos, la gente de KDE estaba interesada en la creación de 2FA, por lo que podría haber una pantalla de bloqueo menos insegura y funcional para los escritorios de Linux dentro de unos años.