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

Ricorda che Linux Il modello di sicurezza è progettato pensando a un server SSH o solo terminale multiutente. Windows è progettato pensando alla workstation dell'utente finale (ma ho sentito dire che la recente generazione di Windows è più adatta ai terminali). In particolare, la convenzione Linux fa un lavoro migliore di sandboxing delle app negli utenti, mentre in Windows tutto ciò che è importante viene eseguito come Sistema, mentre la GUI di Linux (X Server) fa schifo in termini di sicurezza e la GUI di Windows ha cose fantasiose come l'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 Il sistema operativo "(cioè il kernel) è interessato, hai 7 console tty e un numero qualsiasi di connessioni SSH (note anche come" sessioni di accesso ") - succede solo che Ubuntu viene fornito con script per avviare automaticamente la GUI su tty7 , ma per il kernel è solo un'altra applicazione.

Le sessioni di accesso e gli account utente sono separati in modalità sandbox l'uno dall'altro, ma Linux prende una mentalità di sicurezza che non serve per proteggere un utente da se stessi. In questo modello di sicurezza, se il tuo account viene compromesso da malware è una causa persa, ma vogliamo comunque isolarlo dagli 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 viene eseguito come quando non è necessario eseguire operazioni di root. Se un utente malintenzionato riesce a prendere il controllo di un processo apache in esecuzione, può rovinare altri processi apache , ma avrà problemi a passare ai processi ftp .

Nota che Windows adotta un approccio fondamentalmente diverso qui, in gran parte attraverso la convenzione che tutte le cose importanti vengono eseguite sempre come Sistema. Un servizio dannoso in Linux ha meno possibilità di fare cose cattive rispetto a un processo dannoso eseguito come Sistema, quindi ha bisogno di compiere ulteriori sforzi 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 il bus tastiera / mouse sono isolati dal resto dell'ambiente desktop. Può farlo perché la GUI è integrata nel sistema operativo. In Linux, la GUI (X server) è 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ò fare le cose stravaganti UAC come bloccare la tastiera perché quelli devono essere già root o richiedono una riprogettazione totale del server X (vedi Wayland sotto). Un problema che in questo caso è uno svantaggio di separare la 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 sandbox tra le richieste di password e altri processi in esecuzione come l'utente nella stessa sessione della GUI , potremmo dover riscrivere molte cose. Per lo meno, il kernel dovrebbe diventare consapevole della GUI in modo che sia in grado di creare prompt (non vero oggi). L'altro esempio è che tutti i processi in una sessione della GUI condividono un bus della tastiera.

Guardami mentre scrivo un keylogger e poi premo alcuni tasti in una finestra diversa :

  ➜ ~ xinput list
⎡ ID puntatore core virtuale = 2 [puntatore master (3)] ⎜ ↳ ID puntatore XTEST nucleo virtuale = 4 [puntatore slave (2)] ⎜ ↳ ID Logitech K400 Plus = 9 [puntatore slave (2)] ⎜ ↳ ETPS / 2 Elantech Touchpad id = 13 [puntatore slave (2)] ➜ ~ test xinput 9 rilascio tasti 36 pressione tasti 44 h rilascio tasti 44 pressione tasti 40 rilascio tasti 40 pressione tasti 33 rilascio tasti 33 pressione tasti 33 pressione tasti 39 rilascio tasti 33 rilascio tasti 39 tasti premi il tasto 66 premi 31  

Qualsiasi processo in esecuzione poiché puoi annusare la password nel prompt o terminale di un altro processo e quindi chiamare sudo su se stesso (questo segue direttamente dal "non c'è bisogno di proteggerti da te "mentalità), quindi aumentare la sicurezza delle richieste di password è inutile a meno che non cambiamo radicalmente il modello di sicurezza e non facciamo una riscrittura massiccia di tutti i tipi di cose.

(vale la pena notare che Gnome sembra almeno sandbox il bus della tastiera nella schermata di blocco e nella nuova sessione attraverso "Cambia utente" poiché le cose digitate lì non vengono visualizzate nel bus della tastiera della mia sessione)

Wayland

Wayland è un nuovo protocollo che mira sostituire X11. Blocca le applicazioni client in modo che non possano rubare informazioni o influenzare qualcosa al di fuori della loro finestra. L'unico modo in cui i clienti possono comunicare tra loro al di fuori dell'IPC esterno è passare attraverso il compositore che li controlla tutti. Tuttavia, questo non risolve il problema sottostante e sposta semplicemente la necessità di fiducia sul compositore.

Virtualizzazione e contenitori

Se lavori con le tecnologie cloud, " probabilmente stai saltando su e giù dicendo "Docker è la risposta !!". In effetti, punti brownie per te. Sebbene Docker stesso non sia realmente inteso a migliorare la sicurezza (grazie @SvenSlootweg), punta a utilizzare la containerizzazione e / o la virtualizzazione come un forward compatibile con l'attuale architettura Linux.

Due importanti distribuzioni Linux create pensando all'isolamento tra processi:

Sistema operativo Qubes che esegue app a livello utente all'interno di più VM separate in "domini di sicurezza" come come lavoro, operazioni bancarie, navigazione web.

Android che installa ed esegue ogni app come un utente separato con privilegi ridotti, ottenendo così l'isolamento a livello di processo e l'isolamento del file system (ogni app è limitata alla propria directory home) tra le app.

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 questo modo. La semplice modifica dell'implementazione delle richieste di password non comporterà 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 significativa riprogettazione del sistema operativo, quindi è improbabile che accada, ma cose come Docker potrebbero fornire una via da seguire in un ambiente più Linux- 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 importante che in Windows la GUI faccia parte del sistema operativo, mentre in Linux la GUI sia solo un'altra applicazione a livello di utente.

Esiste un meccanismo di sicurezza in Linux in generale o in Ubuntu in particolare che impedisce a qualsiasi applicazione di visualizzare una finestra di dialogo che sembra identica a quella del sistema, chiedendomi la password?

Risposta rapida: No.

Dal punto di vista dell'utente, non vi è alcuna garanzia che il prompt provenga dal sistema operativo; potrebbe essere qualsiasi programma dannoso che aveva solo un'autorizzazione limitata a mostrare una finestra e, richiedendo la mia password, otterrà accesso illimitato all'intera macchina.

Se un programma dannoso è attivo il 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 è un programma legittimo, il programma dannoso può "guardare" la finestra e quello che stai digitando lì, in ambienti server X (il terminale è migliore).

Soluzione?

Se hai motivo di credere che qualche programma non sia affidabile, sandboxing (VM o cose minori).

Altrimenti, non chiedere password . Quella finestra di dialogo è comoda per gli utenti non tecnici. Se sei preoccupato per la sicurezza, o per un amministratore di organizzazioni o simili, non è assolutamente necessario visualizzare una query della password della GUI. Configurare correttamente i permessi degli account utente non root (sì o no, ma senza chiedere) e non utilizzare un desktop come root (per questo motivo e perché si è tentati di utilizzare root più spesso del necessario).

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

Come descritto, non chiedere loro. In qualità di amministratore, si suppone che i "tuoi" utenti abbiano autorizzazioni chiaramente definite.

E, riguardo agli aggiornamenti automatici come amministratore dell'organizzazione: Sei pazzo :) Seriamente, non lasciare che molti client Ubuntu aggiornino le cose in momenti casuali. Che ne dici di immagini centrali che vengono mantenute e testate da te e poi implementate; o nell'altra direzione cose come Ansible?
Completamente indipendenti dalla sicurezza, gli aggiornamenti possono rompere le cose. Ecco perché.

Sì. Questo non è sicuro!

Io personalmente annullo sempre quella finestra di dialogo. Non perché potrebbe essere falso, ma perché potrebbe essere reale.

Dovrei dare privilegi intensificati a "un'applicazione" solo perché 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.

Contrariamente a quanto si sente, i modi (moderni) di Windows e Ubuntu di gestire i livelli di privilegio e l'elevazione dei privilegi sono abbastanza simili. La ragione è sicuramente che i sistemi operativi sono entrambi sistemi multiutente con casi d'uso simili che affrontano problemi simili.

Entrambi i sistemi operativi limitano ciò che un utente ordinario può fare (eseguendo programmi, ovviamente). Un utente può distruggere i propri dati ma idealmente non gli altri (a meno che non li condividano) e idealmente non può compromettere o danneggiare il sistema. Per poter leggere e scrivere i dati di sistema, un programma necessita dei privilegi di amministratore (root) su entrambi i sistemi operativi, che normalmente solo i programmi avviati da admin / root hanno.

Per renderlo semplice, entrambi i sistemi operativi forniscono all'utente predefinito la possibilità di eseguire singoli programmi con "privilegi elevati" tramite sudo rispettivamente UAC. Entrambe le GUI del sistema operativo attivano una finestra di dialogo per dare all'utente la possibilità di impedire l'esecuzione dei programmi come amministratore / root. Entrambi i sistemi hanno anche la nozione di utenti che non sono autorizzati a eseguire programmi privilegiati.

La finestra di dialogo di Ubuntu richiede una password; la finestra di dialogo Controllo dell'account utente di Windows no. (Sembra che tu pensi che un programma abbia bisogno di permessi speciali per mostrare quella finestra di dialogo; non è così. Il programma sta chiedendo per loro con la finestra di dialogo. Se qualcuno falsifica la finestra di dialogo, ottiene il tuo (utente) password che non è un vantaggio per un programma in esecuzione già come tale utente.)

La conclusione di tutto questo è che un programma dannoso può fingere di aver bisogno di privilegi elevati per qualcosa di utile e attivare la finestra di dialogo, ma una volta ottenuti, formatta il disco rigido. ¹ Questo vale per entrambi i sistemi operativi. Poiché in Windows in genere viene installato più software di terze parti, la possibilità di utilizzare un programma del genere è probabilmente maggiore rispetto a Ubuntu.

Dici che in Windows la finestra di dialogo UAC di solito è il risultato di un'azione dell'utente, ad esempio l'installazione di un programma, mentre Ubuntu attiva la finestra di dialogo senza motivo apparente. Un motivo a cui riesco a pensare è che gli aggiornamenti del software Windows vengono avviati dal sistema operativo in modo che abbiano già privilegi elevati. Forse Ubuntu chiede prima di installare.

Sarebbe davvero bello avere più informazioni oltre a "Ho bisogno del tuo passaporto, dei tuoi stivali e della tua giacca". Non ho un sistema Ubuntu a portata di mano qui, ma vedo una didascalia "Dettagli" sul lato sinistro della finestra di dialogo. Hai guardato cosa dice? (Ovviamente un programma dannoso potrebbe falsificare qualsiasi testo presente, ma potresti essere in grado di verificare se il presunto programma è effettivamente in esecuzione.)

Il modo più sicuro per assicurarti che la tua password non sia stata snoopata è usare la sequenza SAK: alt-sysrq-k . Questo ucciderà tutti i programmi sull'attuale VT (incluso X11) e init ti darà un nuovo prompt di login. Gli unici attacchi di cui sono a conoscenza riguardano la modifica della keymap del kernel o la compromissione di init stesso, entrambi richiedono già un accesso root o migliore.

Esistono vari modi leggermente meno completi (XTerm ha modo per accedere all'opzione "input esclusivo" di X11), a seconda di quanto del tuo sistema ti fidi, ma ... perché non dovresti essere in grado di fidarti del tuo sistema?

La principale differenza tra Linux e il modello di sicurezza di Windows è che sotto Linux non scarichi semplicemente eseguibili casuali da Internet e li esegui. (Ci sono alcuni tentativi per impacchettare applicazioni Linux non affidabili in una sandbox di pacchetti simile ad Android, ma nessuno le usa.)

Orribile, orribile mancanza di sicurezza. Quando ho visto il design di sudo grafico ho morso il proiettile e ho fatto sudo passwd root seguito da apt-get remove sudo , quindi ho davvero infastidito gli IRC di Ubuntu sostenendo la disinstallazione sudo.

Eppure la comprensione è ancora del tutto insicura. Era un po 'ok sul terminale (tanto più quando le shell erano più deboli era relativamente sconosciuto e gli attacchi contro di essa non si erano realmente sviluppati) ma ora è un evidente punto debole.

Avvio piuttosto una seconda istanza X come root ora per meno di una volta all'anno devo dare un programma grafico come root. (Lo faccio avviando X: 1 direttamente non eseguendo startx, quindi nient'altro che l'applicazione di destinazione è in esecuzione nell'istanza X di root). Se hai bisogno di root più spesso ti consiglio apt-get install ssh e ssh -X root @ localhost .