Sudo non ha uno scopo di sicurezza reale contro terze parti dannose. Quindi sì, è fondamentalmente inutile per quello scopo. In passato ho creduto che fosse effettivamente un controllo di sicurezza per prevenire l'escalation dei privilegi e rendere gli attacchi più difficili, perché alcune persone continuano a insistere che abbia anche quello scopo, ma in realtà è falso. In effetti, al momento hai solo una risposta alla tua domanda, e quella risposta sta propagando quel mito. L'unico scopo di sudo è proteggerti da te stesso, cioè evitare di rovinare il tuo sistema per errore. Ottenere tutti i privilegi con un clic o premendo un tasto potrebbe essere pericoloso, mentre sudo ti costringerà almeno a digitare consapevolmente la tua password. E se tu (o un programma o uno script) finisci per toccare i file di sistema o i file di altri utenti per errore, senza usare consapevolmente sudo , riceverai un avviso di "autorizzazione negata". Quindi alla fine è solo uno strumento di amministrazione e non in realtà un controllo di sicurezza inteso a proteggerti da un attacco.

Ecco un esempio molto semplice del perché sudo non offre una protezione reale contro codice dannoso:

  # Crea payload: sostituisci sudo con un aliaspayload = 'fake_sudo () {# Simula un prompt sudo echo -n "[sudo] password per $ {USER}:" leggi -s password echo # Esegui il tuo comando così sei felice echo "$ password" | sudo -S "$ @" # Fai le mie cose malvagie con la tua password echo "Fatto con il tuo comando, ora potrei usare $ password per fare quello che voglio"} alias sudo = fake_sudo '# Scrivi il payload nel file di configurazione bashrcecho " $ payload ">> ~ / .bashrc  

Questo è un esempio molto semplice di codice che un utente malintenzionato potrebbe eseguire sulla tua macchina. Non è perfetto, non gestisce nemmeno tutti i casi (non funzionerà bene se inserisci la password sbagliata), ma ti mostra solo che sudo può essere sostituito da un attaccante. Se esegui lo script, la prossima volta che apri il terminale ed esegui sudo eseguirai effettivamente fake_sudo . Un utente malintenzionato può sostituire i tuoi programmi con alias o sostituire i file binari (inserendo versioni dannose in ~ / bin o ovunque possano essere eseguite nel tuo percorso), ecc.

Questo non è nemmeno una vera e propria "escalation di privilegi", perché un utente che può eseguire sudo per diventare root ha già tutti i privilegi. Un vero utente senza privilegi non dovrebbe avere le capacità di sudo . Per avere una reale separazione dei privilegi dovresti eseguire le attività di amministrazione su un account completamente separato.

Sono il coautore di sudo. È stato scritto all'inizio degli anni '80 specificamente per rispondere all'esigenza di proteggere l'integrità di una risorsa condivisa (A VAX-11/750 con BSD UNIX) dai suoi utenti (la facoltà del dipartimento CS presso SUNY / Buffalo). A quel tempo, l'unica altra opzione era "su" che richiedeva che tutti condividessero una singola password. Se si fosse verificata una calamità sarebbe stato difficile o impossibile passare al setaccio la scientifica e determinare chi fosse l'autore dalle dita grasse ...

Penso che l'apparente utilità duratura di sudo sia che ricorda all'utente della riga di comando stanno per fare qualcosa che potrebbe meritare una certa certezza nel risultato prima di digitare. Certo, in alcune implementazioni, come le principali distribuzioni Raspberry Pi, dove non è richiesta alcuna password, serve semplicemente come un timbro di gomma. Quindi vai a capire.

Credo ancora che le migliori pratiche per l'implementazione di applicazioni con sistemi operativi derivati ​​da UNIX impongano di eseguirle con un ID non root. Se hai bisogno di root, dovrebbe essere in circostanze controllate. Pensa a sudo come al modo in cui l'accesso root viene concesso agli utenti della riga di comando in circostanze controllate. Questo è tutto.

No, sudo non è inutile.

Come utente (target)

Di solito, quando sei su Linux, agisci come un utente non root. Molte cose, come l'installazione di pacchetti con apt , richiedono l'autorizzazione root / sudo per essere utilizzate. Il binario sudo è lì per dare al normale utente i permessi per usare azioni di livello root come apt install .

Dovresti non usa Linux tutto il tempo come root . Questo perché se sei compromesso, l'attaccante avrebbe accesso root al tuo sistema, il che significa che può fare praticamente qualsiasi cosa sul tuo sistema. Invece, esegui Linux come utente non root, in modo che anche se il tuo account viene compromesso, l'attaccante non può ottenere immediatamente l'accesso a root .

Ovviamente, nessun sistema è totalmente sicuro e qualcosa da qualche parte nel tuo sistema può essere sfruttato. L'utilizzo di un account sudoers invece di root è un passo per proteggere il sistema, come discusso sopra.

Se stai dicendo "L'hacker otterrà in e ottenere comunque il root, perché dovrei usare sudo ? ", è come dire" Se qualcuno entra in casa mia, sarà comunque in grado di (in qualche modo) ottenere i miei gioielli. Perché dovrei usare una cassaforte o serrature? ". È un ulteriore livello di protezione. Non stiamo cercando "un lucchetto in grado di proteggere tutto" , ma "molti lucchetti per fornire ulteriore sicurezza nel caso in cui alcuni di essi si rompano" .

sudo è una salvaguardia. Ti consente di eseguire programmi a livello di root solo quando necessario. È così solo a volte apri la porta della tua stanza TOP SECRET invece di lasciarla sempre aperta, anche se tienila sempre aperta (sempre in esecuzione come root) è più conveniente.

Inoltre, quando sei un utente legittimo, non esegui script di escalation dei privilegi ogni volta che vuoi usare un'azione sudo , usi sudo.

Come aggressore

Il binario sudo può essere sfruttato per ottenere alcune informazioni o anche per ottenere l'accesso root . A volte, gli utenti possono avere nel loro file sudoers qualcosa come MY_USER ALL = (ALL) NOPASSWD: ALL , nel qual caso, se puoi ottenere l'accesso come user MY_USER , puoi eseguire tutti i comandi sudo / root senza password. L'esecuzione di sudo -l può anche darti informazioni come quali comandi puoi eseguire come root anche senza una password. Un esempio di tale errata configurazione sarebbe USERNAME ALL = (ALL) NOPASSWD: / bin / vi che ti permette di eseguire vi come root senza una password come utente USERNAME . Questo è un modo per aumentare manualmente i privilegi.

Ogni programma aggiuntivo può presentare alcune vulnerabilità aggiuntive. Avere Tomcat in esecuzione introdurrebbe il sistema agli exploit Tomcat. sudo potrebbe essere solo un altro programma che puoi usare nel tuo sfruttamento.

Inoltre, come pensi che questi pratici script / strumenti di escalation dei privilegi ti consentano di accedere come root? Molti di loro usano sudo in un modo o nell'altro.

Sudo è lungi dall'essere inutile.

Un amministratore può assegnare i privilegi in modo flessibile e granulare e avere opzioni di responsabilità (registrazione decente). È una soluzione significativamente migliore per l'utilizzo dei gruppi.

Naturalmente, se lo confronti con SELinux , le prestazioni e la capacità di sudo eclissi, sebbene a un costo di implementazione e configurazione (e mantenimento).

Al contrario, dal punto di vista di un utente malintenzionato, potrebbe essere fortunato e acquisire un account con privilegi sudo o trarre vantaggio da configurazioni errate . Tuttavia, la quantità di sforzo per passare da un utente standard con privilegi sudo a root potrebbe essere significativa. D'altra parte, nessuno di questi problemi è causato da sudo stesso.

La sua efficacia, tuttavia, dipende interamente dalla configurazione. È banale privesc un host se a un account standard compromesso è consentito eseguire qualsiasi cosa come root senza password, è più difficile ma abbastanza fattibile se è consentito eseguire determinati comandi che possono essere manipolati e abbastanza difficile se solo i binari e le situazioni scelti con cura possono essere eseguiti come root.

Anche sudo può essere usato per abilitare l'esecuzione di comandi come altri utenti rispetto a root , quindi questo è un altro modo di utilizzare sudo che potrebbe non portare a una compromissione completa del sistema.

sudo è sicuro o insicuro quanto le sue popolari alternative come su.

L'alternativa più popolare sudo significa consentire ad alcuni o tutti gli utenti di elevare i propri privilegi con su . Più comunemente, tutti gli utenti possono farlo, purché conoscano la password dell'utente di destinazione . A differenza di sudo , che è quasi sempre impostato per richiedere la password di un utente (ed è limitato solo agli utenti fidati), su richiede la password dell'utente di destinazione .

Alcune persone presumono che questo renda su più sicuro di sudo , ma non è così. su è soggetto agli stessi tipi di attacchi di sudo . Supponi di essere un utente che a volte esegue su per diventare root. Supponiamo inoltre che un utente malintenzionato che non conosce la password di root e non può ancora eseguire azioni poiché l'utente root riesce comunque a eseguire codice arbitrario come account non root. Proprio come questo aggressore può fare in modo che quando esegui sudo tu esegua il suo comando dannoso, così può farlo in modo che quando esegui su tu " sta eseguendo il loro comando dannoso.

Cioè, la tecnica nella risposta di reed funziona altrettanto bene per introdurre un falso comando su che cattura la password di l'utente target (che, quando su viene utilizzato per amministrare il sistema, di solito è root).

Ma è possibile fare meglio di entrambi, o per mitigare il rischio.

Una volta che qualcuno può eseguire qualsiasi comando come te, di solito può apportare modifiche arbitrarie al modo in cui si comporta la tua shell e quindi creare falsi sudo , su , doas o qualsiasi altro comando di elevazione dei privilegi.

Tuttavia, fintanto che puoi evitare di interagire con una falsa schermata di accesso , puoi mitigare questo problema disponendo di account utente amministrativi e non amministrativi separati. Non sembra un'idea nuova, e ovviamente non lo è, ma è sorprendente quanto raramente venga veramente eseguita.

Il tuo account amministrativo potrebbe essere solo l'account di root. Ma se vuoi i vantaggi di non accedere come root, che includono il log (per capire cosa è andato storto in caso di errori non dannosi) e la possibilità di eseguire programmi che non sono pensati per essere eseguiti come root (la maggior parte interfacce grafiche), quindi puoi avere due account non root, uno dei quali viene utilizzato per l'amministrazione (in cui esegui sudo o su secondo necessità) e l'altro di cui non lo è.

Questo account, se non , dovrebbe condividere le credenziali di accesso con l'account non amministrativo. Non dovrebbero avere password identiche o simili e dovrebbero avere coppie di chiavi separate. Inoltre, non devi elevare dall'account non amministrativo all'account amministrativo, per lo stesso motivo non devi elevare dall'account non amministrativo a root.

Se lo fai, c'è anche un argomento per sudo rispetto alle sue alternative.

In questa configurazione, è un vantaggio di sudo rispetto a su , sebbene non sia un vantaggio decisivo. Puoi evitare di utilizzare accidentalmente l'account sbagliato, quello utilizzato per ogni sorta di altra roba non amministrativa che potrebbe esporlo a rischi maggiori, per amministrare il sistema, facendo in modo che sia solo un normale account utente limitato che non è elencato e non è un membro di alcun gruppo elencato nel file / etc / sudoers .

Ma puoi anche raggiungere questo obiettivo con su esercitando un'adeguata autodisciplina e assicurandoti di non essere mai su dall'account che hai progettato come non amministrativo o impedendo agli account designati come non amministrativi di elevare i privilegi con su . (Un modo per ottenerlo, su un sistema GNU / Linux, è con AppArmor, che è il modo in cui Ubuntu ha impedito all'account guest di utilizzare con successo su - nelle versioni di Ubuntu che venivano fornite con account guest abilitati.)

Il rischio di utilizzare sudo o su nel solito modo potrebbe essere accettabile per te.

Detto questo, non sto dicendo che devi necessariamente farlo. Dipende da te o, se del caso, da te e da altri stakeholder.

Per molte persone, i rischi associati all'utilizzo dello stesso account per (a) elevare al root con sudo (o meccanismi simili come Polkit) o ​​ su (o meccanismi simili come doas ) usati per (b) attività non amministrative come l'esecuzione di un browser web possono essere un compromesso accettabile per comodità.

Il punto di sudo non è di rendere difficile elevare i privilegi. In effetti, è esattamente l'opposto: il punto è rendere facile elevare i privilegi.

Rendendo facile elevare i privilegi quando ne hai bisogno , gli utenti hanno meno incentivi a eseguire con privilegi elevati sempre.

Se rendi difficile elevare i privilegi, gli utenti accederanno semplicemente come root tutto il tempo. Rendendo facile elevare i privilegi "al volo", gli utenti sono incoraggiati ad accedere come utenti non privilegiati e ad elevare i privilegi solo per un singolo processo per la durata di quel processo, invece di eseguire sempre con privilegi elevati.

sudo è, fondamentalmente, uno strumento di usabilità , non uno strumento di sicurezza. Gli effetti di sicurezza di sudo sono conseguenze di secondo ordine degli effetti di usabilità. La sicurezza non è utile quando non è utilizzabile.

In questo, sudo è più o meno equivalente all'UAC in Windows Vista +, che è spesso frainteso anche come strumento per prevenire l'elevazione dei privilegi, quando in realtà è uno strumento per rendere più facile l'elevazione dei privilegi. Prima dell'introduzione dell'UAC, era del tutto normale per gli utenti Windows accedere sempre a un account con privilegi amministrativi, semplicemente perché Windows era inutilizzabile per qualsiasi cosa tranne che per l'uso di base dell'ufficio.

C'è un ulteriore vantaggio a sudo tramite su o accedendo come root , ovvero sudo può essere configurato per lasciare una traccia di controllo di quale utente ha emesso quale comando privilegiato in quale momento.

Come ogni cosa nella sicurezza delle informazioni, sudo è un trade-off”.

Esploriamo le alternative:

• cambiando il sistema in modo che il comandi per cui usi sudo non richiedono privilegi a livello di root
• accedi come root per ottenere i diritti di accesso richiesti
• usando su per passare a un shell di root
• avendo il comando stesso eseguito come root, non importa chi lo esegue

senza entrare nei dettagli, spero che sarai d'accordo che tutte queste alternative sono peggiori di sudo . Non è perfetto, può essere attaccato, ma è la migliore tra quelle alternative.

Per quanto riguarda SELinux, non dimenticare che è entrato nello show relativamente tardi. Non ricordo in quale anno (e diamine, ero lì, il mio nome è nelle credenziali SELinux), ma sudo precede SELinux notevolmente.

E mentre SELinux lo è senza dubbio l'alternativa più potente e più sicura, la maggior parte degli amministratori di sistema non è in grado di scrivere una politica di sicurezza SELinux adeguata.

Quindi, tutto considerato, tra una serie di scelte piuttosto sbagliate, sudo in molti casi è il meno cattivo. È meglio di niente o delle sue alternative, e questo è un motivo sufficiente. Nessuna sicurezza è comunque perfetta.

Detto questo, l'uso principale di sudo nell'azienda non è la sicurezza ma la responsabilità . Se gli amministratori devono accedere con un account personale e quindi utilizzare sudo per il loro lavoro quotidiano, è banale tenere traccia di chi ha fatto cosa. E usando auditd puoi continuare a tracciarli anche quando usano su .

Dipende da come configuri sudo:

Su una macchina usata da persone diverse, puoi configurare sudo in modo che certi utenti può accedere a certi comandi usando sudo:

Puoi configurare sudo in modo che qualche utente possa eseguire un certo comando (es. ip ) usando sudo - ma non qualsiasi altro comando.

L'altra cosa è che sudo dovrebbe essere configurato nel modo in cui ti viene chiesto per una password. Anche se un utente malintenzionato ha accesso a una console, gli verrà richiesta la password se digita comando di esempio sudo .

Puoi anche configurare sudo in modo che alcuni comandi (ad esempio ip ) non richiedano una password e tutti gli altri comandi richiedano di digitare la tua passwort.

Ed è anche possibile configurare sudo in modo che la password richiesta per sudo sia diversa dalla tua password di accesso.

In questo caso anche la tua password di accesso non aiuterà l'attaccante .. .

Tuttavia, se configuri sudo in modo da poter eseguire tutti i comandi e non ti verrà chiesta una password, allora sudo lo farà non forniscono alcuna sicurezza.

Quasi tutto ciò senza una chiave di attenzione sicura è "quasi inutile".

Reed fornisce un'ottima risposta sul perché sudo (o almeno la sua funzione di password) è quasi inutile per la sicurezza. Tuttavia, non è solo un bug in sudo , bash o anche nell'intero ambiente Unix. È un problema generale quando si ottengono privilegi più elevati utilizzando una password senza alcune tecniche per evitare false richieste di accesso.

Per iniziare con zsh , fish e persino il prompt dei comandi di Windows ti consente di personalizzare il comando da eseguire, quindi il passaggio a una shell diversa non fermerà un utente malintenzionato che sostituisce fake_sudo con sudo .

Questo non è solo l'ambiente Unix. Immagina di dire Windows, vai su Start> Cambia profilo e digita la password dell'amministratore. Opps, un malintenzionato ha sostituito Explorer.exe con fake_Explorer.exe , che non era il vero pulsante di avvio che hai premuto. Anche in questo caso l'attaccante ha la tua password di amministratore.

Per questi scopi a volte viene utilizzata una chiave di attenzione sicura. A volte potresti aver visto una schermata di accesso a Windows che diceva "Premi Ctrl-Alt-Canc" per accedere. Questo perché Ctrl-Alt-Canc va direttamente al sistema operativo e non può essere simulato da una falsa shell di login. Poiché Ctrl-Alt-Canc può essere utilizzato per attirare in modo sicuro l'attenzione del sistema operativo, si chiama Secure Attention Key.

Esistono alcune alternative a Secure Attention Key. Ad esempio, potresti scegliere un'immagine che ti aspetti di vedere quando effettui il login. Meglio non memorizzare quell'immagine dove i processi non privilegiati possono leggerla o visualizzarla dove i processi non privilegiati possono comunque catturarla. Quindi questo richiede ancora di separare la schermata di accesso dall'account di lavoro generale non privilegiato in un modo in cui strumenti come sudo non lo fanno.

Una volta ho avuto il problema di accedere al mio server tramite chiavi SSH e dimenticare la password da utilizzare con sudo che suggerisce questa idea:

Suppongo che se ci sono compromessi Credenziali SSH, diciamo recuperate da un disco rigido non cancellato in una discarica, quindi sudo potrebbe essere d'aiuto poiché è necessaria una password per svolgere le funzioni di amministratore. Non ho prove ma sospetto che molte chiavi SSH non abbiano password.

Un vettore di attacco più realistico con questo problema di sudo sono le chiavi SSH lasciate su Github.

Qualcosa che finora non è stato menzionato è che sudo (tramite PAM) può utilizzare altri meccanismi oltre a una password e / o utilizzare l'autenticazione a 2 fattori. Sebbene ciò non risolva il problema dell'account compromesso, rende più difficile falsificare un prompt.

Inoltre, sudo ha i suoi usi al di fuori semplicemente dando pieno accesso root, può essere utilizzato per consentire a un utente specifico di eseguire un comando specifico, e nessun altro come root, o anche come un altro utente. Non sono sicuro che SELinux sarebbe così facile da configurare per quel caso d'uso.