Aggiornato radicalmente dopo 69 voti positivi, consulta la cronologia delle risposte per la risposta originale. Grazie a @JimmyJames per la discussione.
Per prima cosa, parliamo del modello di minaccia:cosa stai cercando di impedire al potenziale aggressore di fare?
Modello di minaccia:furto di identità/ransomeware su un sistema a utente singolo
Generalmente per i sistemi degli utenti finali il de facto il modello di minaccia è il furto di identità/ransomware. Se l'attaccante ha accesso ai tuoi documenti e/o può eseguire i comandi della shell come te, il gioco è finito. Da quel punto di vista, l'accesso root non guadagna nulla per l'attaccante; possono ottenere ciò che vogliono senza di essa.
Se il furto di identità/malware è l'unica cosa di cui sei preoccupato, allora non sembra importare molto se il tuo utente ha sudo powers o se il browser è in esecuzione come root.
(Vorrei anche sottolineare che il malware/la connessione a una botnet può avvenire senza l'accesso root poiché gli script di accesso/la pianificazione di un cron job non richiedono root).
Randall Munroe di XKCD sembra essere d'accordo con questo punto di vista:
Infine, aggiungerò questa dichiarazione di non responsabilità:sì, sono consapevole che ciò va contro l'opinione pubblica generale secondo cui "più sicurezza è sempre meglio". Non è vero. A volte una maggiore sicurezza è peggio, come criteri di password eccessivamente complessi che finiscono per costringere le persone a scrivere le proprie password. Devi sempre esaminare i rischi e decidere quanta sicurezza è effettivamente appropriata. In questo caso non c'è niente di male nel bloccare l'accesso root, ma ti stai complicando la vita e non è chiaro se ne stai guadagnando qualcosa.
Modello di minaccia:accesso root o sistema multiutente
Se hai un modello di minaccia in cui l'attaccante vuole qualcosa a cui solo root ha accesso, o c'è più di un account utente sulla macchina, allora la risposta dipende in realtà da quale * nix stai parlando. Questo sta rapidamente allontanandosi dai casi di personal computer e nei casi di server, ma ne discuterò comunque. Per Linux, a causa di un bug (*ahem feature*) nel sistema a finestre di Xorg, il tuo account quotidiano probabilmente non dovrebbe avere sudo poteri. Per i sistemi operativi che non usano X, probabilmente va bene.
Linux (con sistema a finestre X.org)
Ecco un ottimo articolo che mostra come registrare tutte le sequenze di tasti su una macchina gui linux usando un semplice comando shell user-land (non root). In sintesi:
$ xinput list mostra tutti i dispositivi di input umani collegati
$ xinput test <id> avvia l'eco di tutte le sequenze di tasti sul dispositivo selezionato.
Ho testato e ottengo i log della password che digito in sudo in un'altra finestra di terminale. Se blocco il computer, quando accedo di nuovo, vedo i registri della password che ho digitato nella schermata di blocco. Apparentemente questo non è un bug in X, è una caratteristica. Bene, ora vado a nascondermi sotto il letto.
Quindi sì, questo supporta l'idea che qualsiasi utente con cui accedi alla GUI non dovrebbe avere sudo poteri perché è banale registrare la propria password e quindi diventare root. Suppongo che dovresti avere un account dedicato per sudo ing e passare a un terminale TTY (ctrl+alt+# ) quando vuoi usare sudo . Se valga la pena o meno preoccuparsene dipende da te:personalmente, tutti i dati che mi interessano sono già presenti nel mio account utente, ma probabilmente cambierò la configurazione del mio laptop perché sono un fanatico della sicurezza.
Nota che nei miei test non sono stato in grado di eseguire il keylog tra gli utenti. Facendo "Cambia account" nella GUI, o startx in un nuovo terminale tty sembra lanciare un'istanza isolata di X.
Grazie a @MichaelKjörling per questa osservazione:
Questa è una delle cose che Wayland [sistema di finestre progettato per sostituire X] cerca effettivamente di risolvere (vedi il punto elenco sulla sicurezza). Ricorda che X11 ha avuto origine in un momento in cui il modello di minaccia era enormemente diverso da quello che è oggi.
Per amministratori di sistema :questo rafforza l'abitudine di interagire solo con le tue macchine Linux su ssh, non usare mai la GUI.
MacOSX
Non sono un esperto di OSX, ma so che non utilizza il server Xorg, quindi presumo che la GUI di Apple lo gestisca correttamente, ma mi piacerebbe che qualcuno più esperto di me intervenisse.
Finestre
Nemmeno io sono un esperto di Windows, ma credo che la funzionalità UAC (User Account Control) introdotta in Windows 7 abbia risolto questo problema facendo visualizzare i prompt dell'amministratore in un desktop sicuro i cui bus di input sono isolati dal normale desktop.
Nella maggior parte delle situazioni, richiedere una password con sudo è una protezione sufficiente.
La differenza principale tra su ing a un altro account e sudo ing per ottenere i privilegi è che con sudo inserisci la stessa password che hai usato per accedere. ti proteggerà da.
Ho scoperto che avere due account sui miei sistemi unix è essenziale per il seguente motivo:
Se mai dovessi rovinare il mio .bashrc o altri file di login / configurazione del terminale, posso entrare in una situazione in cui non riesco nemmeno ad accedere. Quindi sono totalmente annoiato. Questa è la peggiore situazione immaginabile in quanto non puoi fare molto se non riesci ad accedere.
L'unico modo in cui sono stato in grado di risolvere questo problema su un paio di computer è stato avere l'altro accesso che mi consente di accedere e utilizzare sudo, correggere i file di avvio per il mio account principale. Quindi esco dal mio account'2' e ritorno al mio account normale.
A volte potrei essere in grado di utilizzare l'opzione di avvio da USB ma ad essere onesti trovo che sia in grado di accedere a un altro account, utilizzare sudo e correggere il mio .bashrc, quindi disconnettersi e tornare all'altro account può essere fatto in pochi secondi con il secondo accesso e molto meno spaventoso / sconosciuto dell'avvio USB per correggere l'opzione per me. Ovviamente YMMV (Your Mileage May Very)