Skip to content

Il prompt di sistema di Ubuntu per la mia password non può essere falsificato?

Vogliamo mostrarti la migliore risposta che abbiamo trovato online. Ci auguriamo che lo troviate utile e se potete contribuire con qualcosa che può aiutarci a migliorare, fatelo liberamente.

Soluzione:

I tuoi punti sono tutti validi e hai ragione, ma prima di indignarci per questo dobbiamo ricordarci come funziona il modello di sicurezza di Linux e cosa è stato progettato per proteggere.

Ricordate che il modello di sicurezza di Linux è stato progettato pensando a un server SSH o di solo terminale multiutente. Windows è stato progettato pensando a una workstation per l'utente finale (ma ho sentito dire che l'ultima generazione di Windows è più adatta ai terminali). In particolare, la convenzione di Linux fa un lavoro migliore di sandboxing delle applicazioni per gli utenti, mentre in Windows tutto ciò che è importante viene eseguito come Sistema, mentre l'interfaccia grafica di Linux (X Server) fa schifo in termini di sicurezza, mentre l'interfaccia grafica di Windows ha cose fantasiose come l'UAC incorporato. In sostanza, Linux è (ed è sempre stato) prima un server e poi una workstation, mentre Windows è il contrario.


Modelli di sicurezza

Per quanto riguarda il "sistema operativo" (cioè il kernel), ci sono 7 console tty e un numero qualsiasi di connessioni SSH (alias "sessioni di login"); si dà il caso che ubuntu venga fornito con script per l'avvio automatico dell'interfaccia grafica sul computer. tty7 ma per il kernel è solo un'altra applicazione.

Le sessioni di accesso e gli account utente sono ben separati l'uno dall'altro, ma Linux adotta un modello di sicurezza secondo il quale non è necessario proteggere un utente da se stesso. In questo modello di sicurezza, se l'account viene compromesso da un malware è una causa persa, ma vogliamo comunque isolarlo dagli altri account per proteggere il sistema nel suo complesso.

Ad esempio, le applicazioni Linux tendono a creare un utente a basso privilegio come apache o ftp con cui vengono eseguite quando non hanno bisogno di fare operazioni di root. Se un utente malintenzionato riesce a prendere il controllo di un utente in esecuzione apache in esecuzione, può rovinare gli altri processi apache ma avrà problemi a passare a ftp processi.

Si noti che Windows adotta un approccio fondamentalmente diverso, in gran parte per la convenzione che tutte le cose importanti vengono eseguite sempre come System. Un servizio dannoso in Linux ha meno possibilità di fare cose cattive rispetto a un processo dannoso eseguito come System, quindi Windows ha bisogno di di fare sforzi supplementari per proteggere qualcuno con diritti di amministratore da "se stesso".

Gli ambienti GUI e un X Server che non è stato progettato per la sicurezza, mettono a dura prova 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 il bus tastiera/mouse sono isolati dal resto dell'ambiente desktop. Ciò è possibile perché l'interfaccia grafica è integrata nel sistema operativo. In Linux, la GUI (X server) è solo un'altra applicazione e quindi i prompt delle password appartengono al processo che li ha invocati, in esecuzione come voi, condividendo i permessi di memoria e un bus di input con ogni altra finestra e processo in esecuzione come voi.

Il prompt di root non può fare le cose più fantasiose dell'UAC, come bloccare la tastiera, perché queste o devono essere già root, o richiedono una totale riprogettazione del server X (si veda Wayland più avanti). Un problema che in questo caso è un aspetto negativo della separazione dell'interfaccia grafica dal kernel. Ma almeno è in linea con il modello di sicurezza di Linux.

Se dovessimo rivedere il modello di sicurezza per limitare questo fenomeno, aggiungendo un sandboxing tra le richieste di password e gli altri processi in esecuzione come utente nella stessa sessione della GUI, potremmo dover riscrivere molte cose. Come minimo, il kernel dovrebbe diventare consapevole dell'interfaccia grafica in modo da essere in grado di creare richieste (oggi non è così). L'altro esempio da seguire è che tutti i processi in una sessione GUI condividono il bus della tastiera.

Guardate come scrivo un keylogger e poi premo alcuni tasti in una finestra diversa:

➜  ~ 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 voi può sniffare la password nel prompt o nel terminale di un altro processo e poi chiamare sudo su se stesso (questo segue direttamente dalla mentalità "non c'è bisogno di proteggervi da voi"), quindi aumentare la sicurezza dei prompt delle password è inutile a meno che non si cambi radicalmente il modello di sicurezza e si riscriva in modo massiccio ogni genere di cose.

(vale la pena di notare che Gnome sembra almeno fare un sandboxing del bus della tastiera nella schermata di blocco e nelle nuove sessioni attraverso "Cambia utente", dato che le cose digitate lì non vengono visualizzate nel bus della tastiera della mia sessione)


Wayland

Wayland è un nuovo protocollo che mira a sostituire X11. Blocca le applicazioni client in modo che non possano rubare informazioni o influenzare qualsiasi cosa al di fuori della loro finestra. L'unico modo in cui i client possono comunicare tra loro al di fuori dell'IPC esterno è attraverso il compositor che li controlla tutti. Questo però non risolve il problema di fondo e sposta semplicemente la necessità di fiducia sul compositore.


Virtualizzazione e contenitori

Se lavorate con le tecnologie cloud, probabilmente state saltando su e giù dicendo "Docker è la risposta!!!". In effetti, avete dei punti di merito. Sebbene Docker in sé non sia realmente destinato a migliorare la sicurezza (grazie @SvenSlootweg), punta all'utilizzo della containerizzazione e/o della virtualizzazione come soluzione compatibile con l'attuale architettura Linux.

Due distribuzioni Linux degne di nota che sono state costruite tenendo conto dell'isolamento tra i processi:

Qubes OS che esegue applicazioni a livello utente all'interno di più macchine virtuali separate in "domini di sicurezza", come lavoro, operazioni bancarie, navigazione web.

Android che installa ed esegue ogni app come utente separato a basso privilegio, ottenendo così un isolamento a livello di processo e di file system (ogni app è confinata nella propria home directory) tra le app.


In conclusione: Dal punto di vista dell'utente finale, non è irragionevole aspettarsi che Linux si comporti come 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 finché il processo è di proprietà dell'utente. Per Linux ottenere gli stessi comportamenti di sicurezza di Windows nel contesto di una workstation GUI a utente singolo richiederebbe una significativa riprogettazione del sistema operativo, quindi è improbabile che accada, ma cose come Docker potrebbero fornire una via d'uscita in un modo più nativo di Linux.

In questo caso, la differenza importante è che Linux è stato progettato a basso livello per essere un server multi-utente e ha deciso di non proteggere un utente da se stesso, mentre Windows è stato progettato per essere una workstation a singolo utente, quindi è necessario avere protezioni inter-processo all'interno di una sessione di login. È anche importante che in Windows la GUI sia parte del sistema operativo, mentre in Linux la GUI è solo un'altra applicazione a livello utente.

C'è qualche meccanismo di sicurezza in Linux in generale o in Ubuntu
che impedisca a un'applicazione di visualizzare una finestra di dialogo identica a quella del sistema.
che sembra identica a quella del sistema, chiedendomi la mia password?

Risposta rapida: No.

Dal punto di vista dell'utente, non c'è alcuna garanzia che il prompt provenga dal sistema operativo.
che il prompt provenga dal sistema operativo; potrebbe trattarsi di un qualsiasi programma maligno
programma maligno che ha solo un permesso limitato di mostrare una finestra e che, richiedendo la password, otterrà un accesso illimitato all'intero computer.
richiesta della password, otterrà un accesso illimitato all'intera macchina.
macchina.

Se sul computer è presente un programma dannoso, non importa nemmeno quale programma stia mostrando la finestra di dialogo.
Se si tratta di un programma dannoso, come descritto nella frase successiva, non ha nemmeno bisogno di mostrare una finestra di dialogo. Se si tratta di un programma legittimo, il programma maligno può "osservare" la finestra e ciò che vi si digita, in ambienti X server (il terminale è meglio).

Soluzione?

Se si ha motivo di credere che un programma non sia affidabile, si può ricorrere al sandboxing (VM o altro).

Altro, non chiedere le password. Questa finestra di dialogo è una comodità per gli utenti non tecnici. Se siete preoccupati per la sicurezza, o siete amministratori di un'organizzazione o simili, non c'è assolutamente bisogno di visualizzare una richiesta di password tramite interfaccia grafica. Configurate correttamente i permessi degli account utente non root (sì o no, ma non chiedetelo) e non usate un desktop come root (per questo motivo e perché è una tentazione usare root più spesso del necessario).

Chiedendo all'utente la password regolarmente, il sistema insegna all'utente che
che fornire la propria password di sistema ogni volta che un'applicazione la richiede
di sistema ogni volta che un'applicazione la richiede è una cosa perfettamente naturale da fare.

Come descritto, basta non chiedergliela. Come amministratore, si suppone che i "vostri" utenti abbiano permessi chiaramente definiti.

E, a proposito degli aggiornamenti automatici come amministratore dell'organizzazione: Siete pazzi 🙂 Seriamente, non lasciate che molti clienti di Ubuntu aggiornino cose a casaccio in momenti casuali. Che ne dite di immagini centrali che vengono mantenute e testate da voi e poi distribuite; oppure, nell'altra direzione, di cose come Ansible?
In modo del tutto indipendente dalla sicurezza, gli aggiornamenti possono rompere le cose. Ecco perché.

Sì. Questo è insicuro!

Personalmente cancello sempre quella finestra di dialogo. Non perché potrebbe essere falsa, ma perché potrebbe essere reale.

Dovrei dare privilegi escalation a "un'applicazione" solo perché me lo chiede? No, non credo.

Gli aggiornamenti del sistema vanno bene, li faccio manualmente, ma mi infastidisce che il sistema di segnalazione degli errori lo richieda. Pessima progettazione.

Qui puoi vedere i commenti e le valutazioni dei lettori

Puoi aggiungere valore alle nostre informazioni contribuendo con la tua esperienza nelle spiegazioni.



Utilizzate il nostro motore di ricerca

Ricerca
Generic filters

Lascia un commento

Il tuo indirizzo email non sarà pubblicato.