I tuoi punti sono tutti validi e hai ragione, ma prima di indignarci dobbiamo ricordarci come funziona il modello di sicurezza di Linux e cosa è progettato per proteggere.
Ricorda che il modello di sicurezza Linux è progettato pensando a un solo terminale multiutente o un server SSH. Windows è progettato pensando a una workstation dell'utente finale (ma ho sentito dire che la recente generazione di Windows è più adatta ai terminali). In particolare, la convenzione Linux svolge un lavoro migliore nel sandboxing delle app negli utenti, mentre in Windows qualsiasi cosa importante viene eseguita come sistema, mentre la GUI di Linux (X Server) fa schifo alla sicurezza e la GUI di Windows ha cose fantasiose come UAC integrato. Fondamentalmente, Linux è (ed è sempre stato) prima un server e poi una workstation, mentre Windows è il contrario.
Modelli di sicurezza
Per quanto riguarda "il sistema operativo" (ovvero il kernel), hai 7 console tty e un numero qualsiasi di connessioni SSH (ovvero "sessioni di accesso") - si dà il caso che Ubuntu venga fornito con script per avviare automaticamente la GUI su il tty7 session, ma per il kernel è solo un'altra applicazione.
Le sessioni di accesso e gli account utente sono in modalità sandbox abbastanza bene l'uno dall'altro, ma Linux adotta una mentalità di sicurezza che non è necessaria per proteggere un utente da se stesso. In questo modello di sicurezza, se il tuo account viene compromesso da malware, allora è una causa persa, ma vogliamo comunque isolarlo da altri account per proteggere il sistema nel suo insieme.
Ad esempio, le app Linux tendono a creare un utente con privilegi limitati come apache o ftp che corrono come quando non hanno bisogno di fare cose radicali. Se un utente malintenzionato riesce a prendere il controllo di un apache in esecuzione processo, può rovinare altri apache processi, ma avrà problemi a passare a ftp processi.
Si noti che Windows adotta un approccio fondamentalmente diverso qui, in gran parte attraverso la convenzione secondo cui tutte le cose importanti vengono sempre eseguite come sistema. Un servizio dannoso in Linux ha meno spazio per fare cose cattive rispetto a un processo dannoso eseguito come Sistema, quindi Windows ha bisogno fare sforzi extra per proteggere qualcuno con diritti di amministratore da "se stesso".
Gli ambienti GUI e un server X che non è stato progettato per la sicurezza gettano una chiave inglese in questo modello di sicurezza.
Gnome gksudo vs Windows UAC e keylogger
In Windows, quando un processo utente richiede l'escalation dei privilegi, il kernel lancia uno speciale prompt protetto la cui memoria e bus tastiera/mouse sono isolati dal resto del resto dell'ambiente desktop. Può farlo perché la GUI è integrata nel sistema operativo. In Linux, la GUI (server X) è solo un'altra applicazione, e quindi le richieste di password appartengono al processo che le ha invocate, in esecuzione come te, condividendo i permessi di memoria e un bus di input con ogni altra finestra e processo in esecuzione come te.
Il prompt di root non può eseguire le fantasiose cose UAC come bloccare la tastiera perché devono essere già root o richiedono una riprogettazione totale del server X (vedi Wayland di seguito). Un problema 22 che in questo caso è uno svantaggio della separazione della GUI dal kernel. Ma almeno è in linea con il modello di sicurezza di Linux.
Se dovessimo rivedere il modello di sicurezza per reprimere questo problema aggiungendo il sandboxing tra le richieste di password e altri processi in esecuzione come utente nella stessa sessione della GUI, potremmo dover riscrivere molte cose. Per lo meno, il kernel dovrebbe diventare consapevole della GUI in modo tale da essere in grado di creare prompt (non vero oggi). L'altro esempio è che tutti i processi in una sessione GUI condividono un bus della tastiera.
Guardami mentre scrivo un keylogger e poi premo alcuni tasti in un'altra finestra :
➜ ~ xinput list
⎡ Virtual core pointer id=2 [master pointer (3)]
⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
⎜ ↳ Logitech K400 Plus id=9 [slave pointer (2)]
⎜ ↳ ETPS/2 Elantech Touchpad id=13 [slave pointer (2)]
➜ ~ xinput test 9
key release 36
key press 44
hkey release 44
key press 40
ekey release 40
key press 33
lkey release 33
key press 33
lkey press 39
okey release 33
key release 39
key press 66
key press 31
Qualsiasi processo in esecuzione come puoi annusare la password nel prompt o nel terminale di un altro processo e quindi chiamare sudo su se stesso (questo segue direttamente dalla mentalità "non c'è bisogno di proteggerti da te"), quindi aumentare la sicurezza dei prompt della password è inutile a meno che cambiamo radicalmente il modello di sicurezza e facciamo una massiccia riscrittura di ogni genere di cose.
(vale la pena notare che Gnome sembra eseguire almeno il sandbox del bus della tastiera sulla schermata di blocco e le nuove sessioni tramite "Cambia utente" poiché le cose digitate lì non vengono visualizzate nel bus della tastiera della mia sessione)
Terra di passaggio
Wayland è un nuovo protocollo che mira a sostituire X11. Blocca le applicazioni client in modo che non possano rubare informazioni o influenzare nulla al di fuori della loro finestra. L'unico modo in cui i client possono comunicare tra loro al di fuori dell'IPC esterno è passare attraverso il compositore che li controlla tutti. Ciò tuttavia non risolve il problema sottostante e sposta semplicemente la necessità di fiducia sul compositore.
Virtualizzazione e container
Se lavori con le tecnologie cloud, probabilmente stai saltando su e giù dicendo "Docker è la risposta!!". In effetti, punti brownie per te. Anche se Docker in sé non ha lo scopo di migliorare la sicurezza (grazie a @SvenSlootweg), indica l'utilizzo della containerizzazione e/o della virtualizzazione come soluzione compatibile con l'attuale architettura Linux.
Due notevoli distribuzioni Linux create tenendo presente l'isolamento tra processi:
sistema operativo Qubes che esegue app a livello di utente all'interno di più VM separate in "domini di sicurezza" come lavoro, banche, navigazione web.
Android che installa ed esegue ciascuna app come utente separato con privilegi limitati, ottenendo così l'isolamento a livello di processo e l'isolamento del file system (ogni app è confinata nella propria home directory) tra le app.
In conclusione: Dal punto di vista di un utente finale, non è irragionevole aspettarsi che Linux si comporti allo stesso modo di Windows, ma questo è uno di quei casi in cui è necessario capire un po' come funziona il sistema sottostante e perché è stato progettato in quel modo . La semplice modifica dell'implementazione delle richieste di password non porterà a nulla fintanto che è di proprietà di un processo di tua proprietà. Affinché Linux ottenga gli stessi comportamenti di sicurezza di Windows nel contesto di una workstation GUI per utente singolo richiederebbe una riprogettazione significativa del sistema operativo, quindi è improbabile che accada, ma cose come Docker potrebbero fornire una via da seguire in un ambiente più Linux- modo nativo.
In questo caso, la differenza importante è che Linux è progettato a basso livello per essere un server multiutente e prendono la decisione di non proteggere un utente da se stessi, mentre Windows è progettato per essere una workstation per utente singolo, quindi è necessario disporre di protezioni tra processi all'interno di una sessione di accesso. È anche rilevante che in Windows la GUI faccia parte del sistema operativo, mentre in Linux la GUI è solo un'altra applicazione a livello utente.
Esiste un meccanismo di sicurezza in Linux in generale o Ubuntu in particolare che impedisce a qualsiasi applicazione di visualizzare una finestra di dialogo identica a quella del sistema, chiedendomi la mia password?
Risposta rapida:No.
Dal punto di vista dell'utente, non vi è alcuna garanzia che il prompt provenga dal sistema operativo; potrebbe trattarsi di qualsiasi programma dannoso che dispone solo di un'autorizzazione limitata per mostrare una finestra e, richiedendo la mia password, otterrà un accesso illimitato all'intera macchina.
Se un programma dannoso è presente sul computer, non importa nemmeno quale programma sta mostrando la finestra di dialogo.
Se è il programma dannoso, beh, come descritto nella frase successiva, non ha nemmeno bisogno di mostrarti una finestra di dialogo. Se si tratta di un programma legittimo, il programma dannoso può "osservare" la finestra e ciò che stai digitando lì, negli ambienti del server X (il terminale è migliore).
Soluzione?
Se hai motivo di credere che alcuni programmi non siano affidabili, sandboxing (VM o cose minori).
Altrimenti, non chiedere password . Quella finestra di dialogo è utile per gli utenti non tecnici. Se sei preoccupato per la sicurezza, o un amministratore di un'organizzazione o simili, non è assolutamente necessario visualizzare una richiesta di password della GUI. Configura correttamente le autorizzazioni degli account utente non root (sì o no, ma non chiedere) e non utilizzare un desktop come root (per questo motivo e perché è una tentazione utilizzare root più spesso del necessario).
Richiedendo regolarmente all'utente la password, il sistema insegna all'utente che dare la sua password di sistema ogni volta che qualche applicazione lo richiede è una cosa perfettamente naturale da fare.
Come descritto, non chiedere loro. In qualità di amministratore, i "tuoi" utenti dovrebbero disporre di autorizzazioni chiaramente definite.
E, riguardo agli aggiornamenti automatici come amministratore dell'organizzazione:sei pazzo :) Seriamente, non lasciare che molti client Ubuntu aggiornino cose casuali in momenti casuali. Che ne dici di immagini centrali che vengono mantenute e testate da te e poi distribuite; o nell'altra direzione cose come Ansible?
Completamente indipendenti dalla sicurezza, gli aggiornamenti possono rompere le cose. Ecco perché.
Sì. Questo non è sicuro!
Personalmente annullo sempre quella finestra di dialogo. Non perché potrebbe essere falso, ma perché potrebbe essere vero.
Dovrei concedere privilegi intensificati a "un'applicazione" solo perché lo chiede? No, non credo.
Gli aggiornamenti di sistema vanno bene, li eseguo manualmente, ma mi dà fastidio che il sistema di segnalazione degli errori lo richieda. Cattivo design.