Non è un "difetto di sicurezza" nel senso che qualcosa è rotto o che i flicker indicano un bug o un attacco. Piuttosto, è un problema con lo stack grafico sottostante di Linux e la mancanza di semantica per i client desktop privilegiati.
Solo per toglierlo di mezzo, lo sfarfallio è probabilmente causato da una scarsa interazione tra i driver della GPU e la shell GNOME o qualsiasi altro compositore integrato di Wayland presente in GDM. È completamente estraneo alla sicurezza.
Ora sul perché vedi il tuo desktop sotto la schermata di blocco ...
Situazione storica
X11, il protocollo e il server di stack grafico utilizzati su tutti i sistemi Linux, non è stato progettato con la possibilità di isolare efficacemente le finestre l'un l'altro, e sia il protocollo X11 originale che un numero di estensioni lo rendono possibile e facile app per spoofare le finestre di dialogo di autenticazione dell'interfaccia utente e rubare input da altri client.
Tradizionalmente, le schermate di blocco sono solo programmi che:
- spawn a schermo intero, in cima a tutte le altre finestre (usando specifiche opzioni WM sulla loro finestra
- acquisisci tutti gli input (in pratica, possono arrivare fino al binding di ogni singola combinazione di tasti sulla tastiera per garantire che tutti gli eventi di input vengano inviati prima a loro)
A questo punto puoi aprire un TTY e uccidere il processo userland che cattura l'input e copre lo schermo, e potresti probabilmente provare a far apparire qualche altra finestra su di esso (ma non potrebbe ricevere eventi da tastiera). Si noti inoltre che in X11 gli eventi della tastiera non vengono inviati correttamente quando c'è un menu aperto. Pertanto, se puoi generare un'app e aprirla, potresti essere in grado di impedire l'immissione della schermata di blocco. Fin qui tutto bene.
Il difetto di sicurezza più ovvio che viene in mente è che i server / compositori di stack grafici non hanno modo di identificare se una finestra specifica è una schermata di blocco e se una finestra specifica afferma di essere una schermata di blocco ma non lo è. Questo è anche un problema su OSX e Windows 8 e Ne ho discusso prima a XDC . L'unica protezione adeguata contro spoofs lockscreen è di utilizzare l'autenticazione a 2 fattori.
Le forme di protezione meno accettabili sono sequenze di attenzione sicure (Ctrl + Alt + Canc di Windows) o funzionalità speciali di lock-lock difficili da individuare e facili da identificare (indicatore a schermo spento ma visibile, schermo intero solo per lockscreen, ecc. ). In altre parole, hai bisogno di un percorso fidato tra l'utente e il sistema operativo che attiva la schermata di blocco e hai anche bisogno della schermata di blocco per autenticare l'utente.
GNOME-Wayland ha cambiato qualcosa?
Purtroppo non tanto quanto dovrebbe. Ora hai garanzie molto più forti, grazie al protocollo di Wayland per l'invio di input) che il tuo lockscreen legittimo non avrà il suo input rubato da esso. Ma non hai modo di stabilire se è la tua vera schermata di blocco che hai di fronte.
Perché? C'era un strong incentivo per GNOME ad essere il primo a "implementare" Wayland, e quindi hanno semplicemente copiato / incollato alcuni dei protocolli X11 scadenti e insicuri (in particolare, selezioni, metodi per accedere a hardware speciale, per collegamenti globali vincolanti e accesso a schermo intero). I lockscreens sono facili da spoofing senza i requisiti che ho impostato sopra e gli sviluppatori di GNOME Shell non hanno implementato contromisure. Ho discusso questo argomento privatamente con uno di questi e sono giunto alla conclusione che non sono interessati a discutere di eventuali difese cross-desktop alle vulnerabilità della sicurezza dello stack grafico. Mi è stato detto che risolveranno tutti i problemi di sicurezza alla base di metodi personalizzati che saranno un po 'migliori, ad un certo punto nel futuro.
Non è stato fissato un programma per questo tipo di lavoro e nessuna prova che verrà eseguita. Gli ingegneri della sicurezza di Red Hat sono impegnati a lavorare su sandboxing app e roba relativa a Docker, è improbabile che abbiano qualsiasi forza lavoro per affrontare i problemi di sicurezza del desktop in qualunque momento presto, e ora che il codice è implementato e utilizzato in natura, è ancora meno probabile che qualcuno vorrà cambiare le API di Wayland. Peggio ancora, altri DE potrebbero voler seguire GNOME e lasciare alcune API non protette per non modificare di nuovo i toolkit o le app desktop.
L'ultima volta che ho parlato con loro, la gente di KDE era interessata a creare 2FA, quindi ci potrebbe essere un lockscreen fattibile, meno insicuro per i desktop Linux tra qualche anno.